eap Mailing List

View Index by: Date - Thread - Author
Re: IETF Last Call Issue 395: SecDir Review
From: Bernard Aboba (bernard_abobahotmail.com)
Date: Thu, 1 Mar 2007 18:17:13 -0800 (PST) 
I found this document well written and interesting (no accounting for taste
;-) ), but difficult to categorize. It is not clear to me whether this is a
tutorial on how EAP fits into (or should fit into) other protocols, or
prescriptive as to how future EAP methods should be specified and what the
specifications should include, or whether it is primarily about specifying
additional characteristics of existing EAP methods (in Appendix A). It has
elements of each.


[BA] It started out as a document desccribing existing usage of EAP keying
material and also analyzing the security properties of that usage. In the
process, some issues were found that were not adequately discussed in RFC
3748 (such as the Peer-Id/Server-Id described in Appendix A), so this
material was added.

I also could not figure out whether "Secure Association Protocol" was a
defined thing (like EAP), a way of looking at several layer-specific
mechanisms in a uniform way, or a recommendation for something new to be
developed. It would be nice if the introduction could sort all this out.


[BA] It's a way of looking at several layer-specific mechanisms in a uniform
way (though it would also be possible to develop a media-independent SAP).
PPP, the initial EAP lower layer, didn't include a SAP, and as a result,
could only guarantee session key freshness if EAP keying material was not
cached.

P12 section 1.4.1. The peer and server names define the scope of the
exported parameters, but some existing EAP methods do not provide such
names (or technically provide null strings). What does this imply about the
scope of those parameters?


[BA] All EAP methods authenticate the peer, so even though they might not
provide their own method-specific identity, they do authenticate the
identity in the RADIUS User-Name attribute. However, some EAP methods that
derive keys and mutually authenticate between peer and server do not derive
the identity of the server. This means that the EAP peer does not know
which server it has been talking to. This could create an issue if the peer
ever needed to talk to the same server again (such as during a fast resume),
since it might attempt to resume an exchange with a different server in the
mistaken believe that it was the same one. In existing deployments this is
not a big problem since with TLS-based methods the server will force a full
authentication if the TLS SessionId is not found. But in future "fast
handoff" schemes such as those under investigation by HOKEY it could become
a bigger issue.

P13 section 1.5, 3rd paragraph: NAS-Identifier is introduced. Is this a
fourth ID to come out of the EAP protocol (along with Peer-ID, Server-ID,
and Session-ID), or is it something else? NAS-Identifier is used many times
later in the document, but never appears to be defined wrt how it relates
to EAP.


[BA] Later on it is stated that channel bindings (such as NAS-Identifier)
are not incorporated into EAP methods, except as opaque blobs. However, the
NAS-Identifier is important for lower layer handling of EAP keying material,
since the lower layer assumes that the keying material is being provided to
the peer and authenticator (as identified by the NAS-Identifier).

P18 section 2.1 re: IKEv2: I believe that what EAP calls the Peer-ID must
match what IKEv2 calls IDi.


It is possible that they will not be identical. RFC 3748 states that the
EAP-Response/Identity is only used for routing, and since IKEv2 uses the IDi
instead of the EAP-Response/Identity, the same advice applies to IDi.

For example, if the user is roaming, the IDi (equivalent to the
EAP-Response/Identity) could be microsoft.com!charliek [at] bt.com and the
Peer-Id as presented in say, EAP-TLS, might be charliek [at] microsoft.com.

P25 next to last paragraph: "Where the EAP peer does not verify the EAP
server identity, it is not possible for the peer to determine whether the
EAP server has shared keying material outside its authorized scope." What
is meant here? In general, it is never possible for one party to a
conversation to determine whether the other party has improperly disclosed
keying material to a third party. It seems likely some other meaning was
intended.


[BA] What is meant here is that if the EAP peer doesn't know who it was
talking to, it has no way of differentiating one server from another. If
the server were caching keying material, this would mean that the EAP peer
would not have a way of specifying the location of the cache.

P25 1st paragraph: I think the point of this paragraph is that a AAA client
must authenticate the AAA server. If it doesn't, something impersonating
the AAA server could falsely authenticate EAP-peers. Whether the server
authentication takes play by matching names in certificates to configured
names of AAA servers or by some other means is not relevant; all that
matters is that this authentication take place. Is this observation perhaps
a response to some bad existing implementations that open SSL connections
to AAA servers without checking the name or the key in the server
certificate?


[BA] AAA protocols do provide for mutual authentication between client and
server. However, in some circumstances the client or server may share
credentials. For example, in some deployments all AAA clients use the same
shared secret with the AAA server. This kind of sharing can enable clients
to impersonate other clients, servers to impersonate other servers, or
servers to impersonate clients.

P27 section 3.1 Secure Association Protocol. I could not tell whether this
document was trying to describe some existing "Secure Association Protocol"
or recommending that some such protocol be developed for each scenario that
uses EAP.


[BA] It is describing the properties that Secure Association Protocols
should have. A SAP is required whenever EAP keying material is cached. No
existing Secure Association Protocols have all of these properties.

P27 3.1 (a): "Without explicit identification, the parties engaged in the
exchange are not identified and the scope of the EAP keying parameters
negotiated during the EAP exchange is undefined." I believe it would be
more correct to say that the scope is defined only by the context. I was
confused as to why the SAP is responsible for the explicit naming given
that the output of the EAP protocol includes a Peer-ID and Server-ID.
(Clearly, I'm confused).


[BA] The SAP is response for binding the EAP keying material to the names
used in the lower layer protocol. Even though the context of the EAP
exchange might be given by the Peer-Id and Server-Id, once the keying
material is transferred to the authenticator, there is a need to specify the
appropriate usage of that keying material.

P27 3.1 (d): This appears to require that the SAP handle key rollover for
long lived sessions. Alternatively a protocol could require that session
lifetime be bounded to the crypto-period of the keys. Is this intending to
rule that out?


[BA] Session lifetime bound to the crypto-period is not ruled out.

P28 3.1 (g): There is a recommendation that the SAP handle key state
resynchronization along with an acknowledgement that this may be difficult
to make secure. Why not recommend the alternative of repeating the EAP
exchange in this (unlikely) situation?


[BA] In practice this is typically what happens, so recommending it would
make sense.

P29 3.1 (j): Why is it important that the SAP be implemented in the
authenticator rather than the backend authentication server? I can see how
it would usually be implemented there, and the system would be marginally
more secure if it were implemented there, but MUST NOT seems a bit strong.
This is really an implementation choice.


[BA] If the SAP were implemented in the backend authentication server, then
it would not provide for mutual authentication and authorization between the
peer and authenticator (one of the security goals of EAP).

P30 3.3: "This is true even where exported EAP keying material is only used
for entity authentication...". Why? It would seem that in that case, the
lifetime of the TSKs and the lifetime of MSK/EMSK would be independent. If
I use my driver's license to authenticate myself to a passport agency,
there is no requirement that the passport expiration be sooner than the
driver's license expiration. If I authenticate with unexpired credentials,
my authentication does not expire just because the credentials do.


[BA] I think that this assertion need not necessarily hold. Let me explain
why.

EAP re-authentication always results in a new MSK/EMSK. Where child keys
are derived from the MSK/EMSK, then the child keys are rekeyed when the
parents (MSK/EMSK) are rekeyed. Where child keys are not derived from the
MSK/EMSK (e.g. IKEv2 DH exchange) then EAP keying material is only used for
authentication. If the key exchange were not rerun when EAP
re-authentication occurred, then the session keys would not be refreshed. I
do not think there is any inherent problem with this, as long as the
unrefreshed session keys are bound to the newly derived EAP keying material,
preventing a man-in-the-middle attack. So while in practice the session
keys might be refreshed, I don't think they have to be.

P43 Security Considerations: What got included under security
considerations, what was in the main text of the document, and what
appeared in both places seemed largely random. That's probably OK. When a
document is primarily about security (as this one is), it's hard to know
how to structure it. This document has a very good flow for readability.


[BA] Actually the Security Considerations section is supposed to demonstrate
that the requirements of "Guidelines for AAA Key Management" have been met.
Perhaps that should have been explained more clearly?

P45 5.1 "No Key Sharing" talks about the "identity of the EAP
authenticator". I suspect this is another term for "NAS-Identifier", but
I'm not sure.


[BA] Yes.

P45 5.2: Given that EAP methods can be negotiated, one possible way to
implement negotiation of cryptographic algorithms is to define a new EAP
method which is identical to the old one except that it uses different
cryptographic algorithms. It's not obvious why you say the ability to
negotiate KDFs is not required. Does that mean the ability to negotiate the
others is required? Why exempt KDFs? Just because a number of existing
protocols made that mistake? This section seems to be placing requirements
(or at least recommendations) on future protocols, in which case
negotiation of KDFs seems like a really good idea.


[BA] RFC 3748 describes the "protected ciphersuite negotaition" security
claim. The ability to negotiate ciphersuites in a protected way is required
to be able to make that claim. In turn the claim is a requirement for
methods that satisfy RFC 4017 (WLAN requirements). The exemption for KDFs
is inherited from "Guidelines for AAA Key Management". In practice once TLS
is enabled to negotiate KDFs, then EAP methods utilizing TLS will also be
able to negotiate KDFs. But not all EAP methods utilize TLS. So while I
would agree that negotiation of KDFs is a good idea going forward (perhaps
even RECOMMENDED), I don't think it can be REQURIED.

Some typos:



P10: "Initiatlization" -> "Initialization"

P16: "material needs to be" -> "material be"

P17: "material and material" -> "material"

P28: "derived from a portion" -> "derived solely from a portion"

P31: "card hold holding" -> "card holding"

P40: "is not longer able" -> "is no longer able"

P45: "algorithms resilience" -> "algorithms provides resilience"

P46: "EAP methods satisfying this" -> "EAP methods to satisfy this"

P46: "EAP methods may not enable" -> "EAP methods are not required to
enable"

P46: "Key Distribution Function" -> "Key Derivation Function" (twice)

P46: "algorithm MUST be selected" -> "algorithms MUST be selected" 

OK


Results generated by Tiger Technologies using MHonArc.