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.