eap Mailing List: IETF Last Call Issue 395: SecDir Review

[Bernard Aboba (bernard_aboba]

Issue 395: Secdir Review
Submitter name: Charlie Kaufman
Submitter email address: charliek [at] exchange.microsoft.com
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"