I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I apologize for submitting these comments a day after the IETF LC closed. Other commitments delayed my work. I hope these are still useful. Thanks, Steve ------ secdir review of draft-ietf-emu-chbind-14 This document defines channel bindings for EAP methods, providing a way to address the lying NAS and lying provider problems. Overall, I have no objections to this document. However, I do have some comments. I have divided these comments into substantive and non-substantive ones. Substantive Comments -------------------- In the Introduction, the second paragraph says that the problem "results when the same credentials are used to access multiple services that differ in some interesting property". Do you mean client or server credentials? I think you mean EAP server credentials. Please be more explicit to make this clearer, since many people will assume that you mean client (EAP peer) credentials. If I'm correct and you do mean EAP server credentials, I suggest that you say so in the first sentence of this paragraph and also in the last sentence. In the next paragraph, you give an example where a low security network is used to read email and a high security network is use to access valuable confidential information. A better example would be to use the low security network for web surfing. Reading email can require a lot of security. In the first paragraph of the Problem Statement, the second sentence says "However, when operating in pass-through mode, the EAP server can be far removed from the authenticator." While this is true, I think the more relevant statement here is that the EAP server can be far removed from the EAP peer. This paragraph is all about problems that can arise when parties between the EAP peer and the EAP server (including the authenticator) are malicious or compromised. So the important thing to point out at the start of the paragraph is the large number of parties that may come between the EAP server and the EAP peer. In the second bullet of section 3 (on page 7), the EAP GSS-API mechanism is a good example. However, I wonder if this attack might take a slightly different form. Could the IM server pretend to be the mail server? I think so. That's just one specific example of a relatively untrusted service pretending to be a relatively trusted service. I suggest that you add an example like that since the current language is quite abstract. Overall, I found the document too abstract for my taste. When I read an RFC that's defining a protocol to be implemented, I prefer to read a description of the problem to be solved and then a clear definition of the protocol. This document reads like a combination of an academic paper and a protocol definition. For example, section 4.1 describes two categories of approach to EAP channel bindings: exchanging the actual network information or encoding the network information into a blob that is used to derive EAP session keys. The rest of section 4.1 goes on to discuss the pros and cons of these approaches. Then section 4.2 defines a bunch of requirements for transporting channel bindings in a lower layer's secure association protocol. While that's interesting, the actual protocol defined in this document sends the actual network information in EAP. Why bother spending several pages talking about things that this protocol doesn't actually do? I see several downsides to including that text in this document. First, you're making it harder for the reader to understand what they actually need to do to implement this protocol. You've probably decreased by half the number of people who will actually read all of this document. Second, some people will use that digression to support arguments like ("My incompatible implementation is compliant with RFC XXXX because I encoded the network information into a blob and used that to generate EAP session keys"). IETF is an engineering organization. We should make our specs as clear and simple as possible and no simpler. This document includes lots of interesting theory that's not needed for its purpose. If you're interested in seeing this document widely implemented, I suggest that you remove as much of that as possible and focus the document on explaining the problem and defining a protocol that solves it. Or you can leave it as is. I'm sure some people will implement it. Just not as many. Friendly suggestion. Take it or leave it. In the first paragraph of section 5.1, you say that "the EAP server needs to be able to access information from the AAA server that is utilized during the EAP session and a local database". Which information? A parenthetical example (an e.g.) would help with understanding what you mean. In section 7.1, you explain that this document isn't useful without an accompanying document defining what information should be included in i1 for each lower layer. Are those documents being prepared for all or at least some of the lower layers? I couldn't find any in a quick search. I know we can't wait for everything to be ready but it would be nice to see at least one or two of those documents so that we can have confidence that this protocol can support all the things that those documents will need. In section 7.2, you define a new RADIUS attribute that identifies the EAP lower layer in use. But you say in the first sentence of that section that this attribute is defined to "carry the EAP lower layer". That sounds like all the lower layer traffic will be encapsulated in this attribute and carried in it. I think you should change the word "carry" in that text to "identify". Unless I misunderstood you. As I read section 8, I wonder whether include the User-Name attribute in i2 could open the system up to attacks where an authenticator or intermediate proxy could remove the anonymity of a user who's using a pseudonym for the username by changing the value of the User-Name attribute to the username of the user suspected of being responsible for this authentication. If the channel bindings checks fail, the authenticator will know they were wrong but if the channel bindings checks succeed, the authenticator will have confirmation of the user's identity. I didn't understand that sending i2 from the server to the peer is optional until I got to section 9.1. In section 5.3, you said that "For success, the server returns the attributes that were considered by the server in making the determination that channel bindings are successfully validated". Which of these is right? At the top of page 23, you say that "In many EAP deployments today attacks where one NAS can impersonate another are out of scope." Do you mean that these attacks are generally not considered but they are a potential problem? Or that they are not a problem? I think they are always a possible problem. Even when all the NASes are owned and managed by the same organization that runs the AAA server and no proxies are used, there's still the potential for a NAS to become compromised. So I think you should say these attacks are "not considered although a real concern" not that they are "out of scope". And then the following sentence says that "Channel bindings brings these attacks into scope". Again, I think those attacks are always a potential issue. Channel bindings provide a good way to address them, whereas there were few ways to do so before. Maybe it would be better to say that. In the next paragraph, you say that when cryptographic binding is used in a tunnel method, the MSK is disclosed to the NAS. I don't think that's right. The MSK that's disclosed to the NAS is the one generated by the outer method. The MSK that's used in cryptographic binding is the one that's generated by the inner method. I don't think there's a problem there. Later in that paragraph, you say that an attack where the NAS terminates an EAP tunnel method is not in scope for existing models for cryptographic binding. I think that's wrong also. EAP tunnel methods protect against just this sort of attack. The first step in these methods is for the EAP peer and the EAP server to build a TLS tunnel. This requires the EAP peer to authenticate the EAP server and decide whether it's trusted. If the NAS has credentials that will cause the EAP peer to trust it as an EAP server, a MITM attack is possible. Of course, that's true for any secure communications and it's a very bad situation. That's why the EAP peer must be very careful about who it trusts and how it authenticates them and the EAP server (and any CAs or other TTPs) must also be similarly careful. I don't see that any of this has much to do with channel bindings. Am I missing something here? If so, please explain it. And maybe you can clarify the text so that other folks get it also. In section 9.2, this paragraph appears: Dishonest peers can only manipulate the first message i1 of the channel binding protocol. In this scenario, a peer sends i1' to the server. If i1' is invalid, the channel binding validation will fail. On the other hand if i1' passes the validation, either the original i1 was wrong and i1' corrected the problem or both i1 and i1' constitute valid information. A peer could potentially gain an advantage in auditing or charging if both are valid and information from i1 is used for auditing or charging. Such peers can be detected by including the information in i2 and checking i1 against i2. In the penultimate sentence, I think you mean "information from i1' is used for auditing or charging." There's no problem if information from i1 is used for auditing. If that happens, the bad peer's information is being ignored. That paragraph does make me wonder about another attack that could be enabled by channel bindings. What if a malicious peer gets perfectly good i1 from a NAS but then sends bad i1' to the EAP server with a goal of damaging the reputation of the NAS? The EAP peer could be working for a competitor of the organization that runs the NAS or just be malicious. Is that a valid concern? If so, maybe you should cite it and suggest a countermeasure. In section 9.4, you refer to "the optional result message". I didn't know before this that the result message was optional. Could you make that clear earlier? In the IANA Considerations, you talk about creating a new "EAP Channel Binding Parameters" top level registry. That's fine. But then you talk about a "Channel Binding Codes" registry. Didn't you mean a "sub registry"? If you want the Channel Binding Codes registry to be in the EAP Channel Binding Paramters registry, I think the first one is really a sub registry. Also, you say that "Early allocation is allowed" for that registry. What does that mean? I don't see any description of "early allocation" in RFC 5226. I expect that IANA will want to know what they need to do to provide "early allocation". How early? Etc. In the definition of the "Channel Binding Namespaces" registry, did you want to include a reference column as you did in the "Channel Binding Codes" registry? If so, maybe you should say so. At the end of section 11.1, a sentence says that "Values skipped in the above table are available for assignment." I don't think any values were skipped so I don't think you need that sentence. Appendix A is pretty similar to section 1. Might you be able to merge them somehow? In section A.3, you describe downgrading attacks and how channel bindings can prevent them. However, I think this will only work if the EAP peer rejects all methods that don't include channel bindings. Otherwise, the NAS can just offer an unauthorized EAP method that permits it to obtain the user's credentials and off to the bank. Non-Substantive Comments ------------------------ In the top right header of the first page, the organization for T. Clancy should probably be Virginia Tech not Electrical and Computer Engineering. In the fourth paragraph of the Introduction, I think you should add the word "the" before "lying provider" problem. In the last sentence of that paragraph, I'd suggest adding "also" before "gain access". That should make things clearer. In the first bullet in section 3 (at the bottom of page 6), "virtual Lads" should probably be "virtual LANs". Unless you are talking about some other phenomenon! ;-) In the second paragraph of section 4.3, the phrase "More often it is useful" can be confusing. The word "it" seems to refer to the subject of the previous sentence ("verification of the MAC or IP address of the NAS"). Actually, the word "it" refers to the idea of making policy decisions about services but that idea doesn't appear until later in the sentence. I suggest that you reword the sentence to say "More often the best approach is to make policy decisions [...]". In the first sentence of section 8, the phrase "a AAA Accept- Request messages" can't be right. Is it singular or plural? I think it's plural so the word "a" should be removed. In section 12 (Acknowledgements), I think Sam Hartman's last name should be capitalized.