Re: [secdir] secdir review of draft-ietf-emu-chbind-14

[Joe Salowey <[e-mail]>]

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.