Thanks, Joe. Looks like we've reached agreement on most things. There are a few items left where Sam's input is needed. I'll wait to see what he has to say. Thanks, Steve > -----Original Message----- > From: Joe Salowey [mailto:jsalowey@xxxxxxxxx] > Sent: Wednesday, April 25, 2012 1:34 AM > To: Stephen Hanna > Cc: draft-ietf-emu-chbind@xxxxxxxxxxxxxx; secdir@xxxxxxxx; IETF- > Discussion list; Sam Hartman > Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14 > Importance: High > > > On Apr 24, 2012, at 2:05 PM, Stephen Hanna wrote: > > > Joe, > > > > I'm glad that my comments were useful to you and to the editors > > of this draft. I will respond to your comments below inline. > > I'm going to clip out as much as I can, including anything > > that has already been agreed on. > > > > Thanks, > > > > Steve > > > > ---------- > > > > Joe Salowey wrote: > >> > >> On Apr 13, 2012, at 11:26 AM, Stephen Hanna wrote: > >> > >>> 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. > >> > >> [Joe] The case here is both client and server credentials. If > >> different credentials are required for each type of service then the > >> authenticator will not be able to lie about the type of service it > is > >> representing to the client because the client credentials are bound > to > >> the service. > > > > SH> I don't see what the problem is with using the same > > client credentials with two different services if the > > server credentials are different. The client will be able > > to detect a lying NAS easily since the server credentials > > won't match what it expects for that service. Could you > > please explain this more? > > > > [Joe] In many cases the server credentials will be the same. They will > be the credentials of the AAA server. > > >>> 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. > >>> > >> > >> [Joe] I think I see your point, but I'm not sure. Traditionally, > we > >> have often thought of the path between EAP peer and EAP > authenticator > >> as being vulnerable to having multiple parties able to insert > >> themselves into the conversation. However it may be the case that > the > >> authenticator the peer is talking to isn't the one it thinks it is > and > >> the "real" authenticator may be somewhere in the path as well. The > >> conversation between the EAP peer and EAP server will not be > >> compromised, however the result of the conversation may not have its > >> intended effect. > > > > My point is that having a long distance between the EAP server > > and the authenticator has little to do with the "lying NAS" > > problem. The problem is that there are potentially untrustworthy > > parties (the NAS and any proxies) between the EAP peer and the > > EAP server and the EAP peer is trusting what it's told by them. > > If the EAP server and the authenticator were two inches apart > > with no intermediaries, that wouldn't help. The problem is the > > potentially untrustworthy folks between the EAP server and > > the EAP peer. You're trying to verify some of what they're > > telling the EAP peer. So I'm not sure that sentence helps but > > if it does, the problem is between the EAP peer and the EAP server. > > > > [Joe] I don't have an issue with stating that the problem is between > the peer and the server, but I'd like to hear the author's view on > this. > > >> > >> [Joe] THis is historical and reflects the discussion we had in the > >> working as the document was being developed. > >> > >>> 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. > >> > >> [Joe] I can see your point, but I think some members of the working > >> group would object if we removed some of this material. If its not > >> clear perhaps we can so a better job of indicating what is normative > >> and what is informative. > > > > OK. If you think the WG really wants this confusing text, > > leave it in. But maybe you should start section 4 by saying > > "This section describes several possible design choices > > for channel bindings. It is not normative." And then you'll > > need to change, delete, or move the paragraph in section 4.2 > > that includes a MUST and a SHOULD. I think that paragraph is > > redundant with the first paragraph in section 6.1 and not > > specific to sending channel bindings in the Secure Association > > Protocol (which is the topic of section 4.2) so I'd suggest > > that you just delete it. You won't lose anything. > > > [Joe] I'm OK with this. > > >>> 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. > >> > >> [Joe] That not how I interpret the text in section 7.1. This > document > >> does specify a general attribute that can be used to specify the > type > >> of lower layer used to carry EAP. Section 7.1 states that > additional > >> documents will be needed to specify attributes specific to a > particular > >> lower layer. ABFAB is working on a document that contains this > >> information for their lower layer, draft-ietf-abfab-gss-eap. > > > > Without a document that defines what information should be > > included in i1 for a given lower layer, the only thing this > > protocol gives you is a way to confirm that the EAP server > > is OK with the lower layer advertised by the authenticator. > > Whoop-dee-do. That doesn't address any of the use cases > > described in the Problem Statement. In all those cases, > > the authenticator is advertising a lower layer that's > > supported by the EAP server. > > > > I'm not saying that EAP channel bindings have no value. > > I'm just saying that they don't have much value without > > a document that specifies the attributes relevant to > > the lower layer that's in use. So let's publish this > > spec and the GSS-EAP spec. But let's also work on a > > spec that describes the attributes for 802.11. > > > > [Joe] I agree we should work on a spec for 802.11 and perhaps other 802 > networks as well. > > > > >>> 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. > >> > >> [Joe] Perhaps, on the one hand I would think the system would not > >> behave this way, the server would be expecting a pseudonym or token > and > >> fail if it got something else. On the other hand, I don' think the > >> text for the user-name check or the test itself are that useful. We > >> could either warn against the possible identity disclosure or remove > >> the user-name check. > > > > I'd be inclined to warn about the problem since there may still > > be some utility in checking the value. Whichever you prefer. > > > > [Joe] I think adding the warning is fine. > > > > >>> 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". > >> > >> [Joe] As EAP is deployed in most cases today the authenticator is > not > >> identified, it is merely authorized as being part of the network. > The > >> peer does not expect differentiated service based on the NAS it is > >> connected to. Since the service is the same it does not matter to > the > >> peer if one authenticator impersonates another. When we start > >> discussing use case such as ABFAB where different services are being > >> provided did the identity of the authenticator really become an > issue. > >> > >> Perhaps the following text is better > >> > >> "In many EAP deployments today attacks where one authenticator can > >> impersonate another not a real concern since different > authenticators > >> provide the same service. In these situations an authenticator does > >> not gain significant advantage in impersonating another > authenticator. > >> " > > > > I'd say "all authenticators provide the same service". I think > > that's what you meant to say. With that change, my concerns are > > allayed. > > > [Joe] Yes, thanks. > > > > >>> 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. > >> > >> [Joe] OK, this test is referring to where there is separate between > >> the terminating server of the inner and outer methods. Maybe it > would > >> be clearer if the text said the following: > >> > >> "Even when cryptographic binding does attempt to confirm that the > inner > >> and outer server are the same, the Master Session Key (MSK) from the > >> inner method is typically used to protect the binding. However, if > the > >> outer method tunnel terminates on the authenticator the inner MSK is > >> disclosed to the authenticator, which can attack cryptographic > >> binding." > > > > Who on earth would terminate the outer method on the authenticator? > > The authenticator should be trusted as little as possible. The party > > who terminates the outer tunnel method must be highly trusted. > > One of the main benefits of having an authentication server is to > > reduce the number of highly trusted parties by centralizing the > > most security-critical activities such as authentication. That's > > why we have pass-through authenticator mode. Maybe you're not > > talking about using EAP pass-through authenticator mode any more. > > In that case, there's no backend authentication server so this > > whole document does not apply. At least, I don't think it does. > > Could you point out to me where in this document it explains > > how to handle this situation? If this situation is not in scope > > for this document, I think you should say that and remove this > > text about MSK problems since they don't apply to this document. > > If not using pass-through authenticator mode is in scope for > > this document, please say that and explain how EAP channel > > bindings work in that environment. > > > > [Joe] So, I'm not a big fan of splitting the inner and outer methods, > but there have been quite a few advocates for various use cases. The > current issue was brought up in ABFAB so I think Sam would be better at > providing the motivation for that. > > >>> 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. > >> > >> [Joe] The issue is when you have different services the client may > not > >> have enough information to determine what an authenticator is > >> authorized for based on its identity alone. In this case it would > like > >> help from the server that terminates the inner method. However > current > >> crypto binding is based on the MSK so the authenticator can generate > >> whatever channel binding quantities it wants because the > authenticator > >> has all the necessary key material. In order for channel bindings > to > >> determine if the authenticator is authorized or not, the method > needs > >> protect the channel bindings with a key generated from the inner > method > >> EMSK that the authenticator does not possess. Here is some text > that > >> may help: > >> > >> "If the authenticator controls the cryptographic binding then it > also > >> controls the channel binding parameters and results. If the channel > >> binding process is used to differentiate one authenticator from > another > >> then the authenticator can claim to support services that it was not > >> authorized to. This attack was not in scope for existing threat > models > >> for cryptographic binding because differentiated authenticators was > not > >> a consideration. Thus, existing cryptographic binding does not > >> typically provide mutual authentication of the inner method server > >> required for channel binding." > > > > Again, you've moved beyond pass-through authentication mode. I don't > > think this document covers that. If it's meant to cover that, it's > > missing a lot of text (to describe how that works). > > > [Joe] True, that is why this was previously out of scope. I think > there are other places where a more detailed of the ABFAB use case > would help.