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?
> > 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.
> > 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?
>
> [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.
> > 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.
> > 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.
> > 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?
>
> [Joe] The server is required to return the channel-binding attributes
> it verified because the client may require certain attributes to be
> checked. This list of verified attributes is not equivalent to i2.
> i2 is what attributes are sent in the AAA protocol and I don't think it
> should be referenced here. Instead it should probably say:
>
> "sending the result from server to peer over integrity-protected
> channel"
OK, 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.
> > 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.
> >
>
> [Joe] I see your point here, how about:
>
> "The use of EAP in situations where different authenticators provide
> different services makes the ability to authorize different
> authenticators more important. The system as a whole needs to be
> analyzed to
> evaluate cases where one authenticator may impersonate another and
> to evaluate the impact of this impersonation. Channel bindings
> provides a way to address these issues. "
Yes, good.
> > 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.
> > 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).
> > Appendix A is pretty similar to section 1. Might you
> > be able to merge them somehow?
> >
>
> [Joe] I think the authors attempted to do this and then decided it was
> better to keep them separate.
OK.