Subject: [eap] IETF Last Call Issue 395: SecDir Review

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 01 Mar 2007 18:14:42 -0800

Issue 395: Secdir Review
Submitter name: Charlie Kaufman
Submitter email address: [email-masked]
Date Submitted: February 25, 2007
Reference:
Document: KEYING-18
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

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. 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.

I found nothing objectionable from a security perspective.

I did find some things confusing; these might be symptoms of real problems,
might be candidates for better explanations, or might just be a reflection
of my density:

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?

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.

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

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.

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?

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.

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).

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?

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?

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.

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.

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.

P45 5.1 1st para: This seems to have requirements that conflict with the
ability to hand off connections (though perhaps some clever mechanism
involving doing all handoffs through the EAP server is what you have in
mind).

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.

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.

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"

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 01 Mar 2007 18:17:06 -0800

>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.

>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.

>later in the document, but never appears to be defined wrt how it relates

[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).

>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 [email-masked] and the
Peer-Id as presented in say, EAP-TLS, might be [email-masked].

>keying material to a third party. It seems likely some other meaning was

[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.

>to AAA servers without checking the name or the key in the server

[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.

>or recommending that some such protocol be developed for each scenario that

[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.

>that the output of the EAP protocol includes a Peer-ID and Server-ID.

[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.

>lifetime be bounded to the crypto-period of the keys. Is this intending to

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

>exchange in this (unlikely) situation?

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

>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).

>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.

>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?

>authenticator". I suspect this is another term for "NAS-Identifier", but

[BA] Yes.

>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