eap Mailing List: Re: [secdir] secdir review of draft-ietf-eap-keying-18.txt (part 1)

[Bernard Aboba (bernard_aboba]

From: Charlie Kaufman <charliek [at] exchange.microsoft.com
To: "iesg [at] ietf.org" <iesg [at] ietf.org, "secdir [at] mit.edu" <secdir 
[at] mit.edu,
   Bernard Aboba <bernarda [at] windows.microsoft.com,        Dan
Simon<dansimon [at] microsoft.com,        "Pasi.Eronen [at] nokia.com"
<Pasi.Eronen [at] nokia.com,        "henrik [at] levkowetz.com"
<henrik [at] levkowetz.com
Subject: [secdir] secdir review of draft-ietf-eap-keying-18.txt
Date: Sun, 25 Feb 2007 18:55:23 -0800

I am reviewing this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments. Feel free to forward to any appropriate
forum.

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?

[BA] The presence of a null Peer-Id or Server-Id implies that in the
process of key generation, a method-specific identity of either the
peer, server or both was not securely confirmed.

There are potential situations in which this could occur:

1. The method does not provide for authentication of a peer or
server method-specific identity.  An example of such a method
is EAP OTP, which only authenticates the peer identity provided
in the EAP-Response/Identity, but does not support either a peer
or server method-specific identity.

2. The method does not support mutual authentication.
An example would be a method utilized for emergency calling which
only supported server authentication.  In this case the method
might provide a Server-Id (as determined from the server certificate)
but not a Peer-Id since the identity of the peer was not authenticated.

3. The method supports mutual authentication, but the peer and server
identities are not securely bound to the keys generated by the method.
An example would be a method that utilizes server-only authentication to
establish a TLS tunnel, then completes an additional authentication within
the tunnel, but does not mix keying material generated in the inner
authentication with keying material from the outer authentication in
generating the EAP method keying material (EAP/MSK).  Such a method
would have provide a Server-Id, but a null Peer-Id, since the identity
of the peer entity contributing to the keying material was not
securely confirmed.  Note that the absence of a Peer-Id in this case
does not necessarily imply a man-in-the-middle vulnerability;  it
may be possible for the method to prove mutual possession of both
inner and outer keying material without actually utilizing both to
determine the EAP method keying material.

4. The method supports mutual authentication via password or shared
secret, but only the Peer provides a method-specific identity.  In
this case, the server is confirmed to possess the password or
shared secret, but the server identity may not be provided.  Note
that even if the server provides its identity, the peer will not
be able to confirm it, as would be possible if server-side certificate
authentication was used.  Nevertheless, where the server provides its
identity and proves possession of a shared secret or password, the
method is capable of providing a Server-Id.

In terms of clarification, I would propose to change the text in
Section 1.4 from:

"  EAP methods supporting key derivation and mutual authentication
  SHOULD export a method-specific EAP conversation identifier known as
  the Session-Id, as well as one or more peer identifiers (Peer-Id(s))
  and MAY export one or more method-specific server identifiers
  (Server-Id(s)).  EAP methods MAY also support the import and export
  of channel binding parameters.  EAP method specifications developed
  after the publication of this document MUST define the Peer-Id,
  Server-Id and Session-Id.  The combination of the Peer-Id(s) and
  Server-Id(s) uniquely specifies the endpoints of the EAP method
  exchange when they are provided.  For existing EAP methods the Peer-
  Id, Server-Id, and Session-Id are defined in Appendix A."

To:

"  EAP methods supporting key derivation and mutual authentication
  SHOULD export a method-specific EAP conversation identifier known as
  the Session-Id, as well as one or more peer identifiers (Peer-Id(s))
  and MAY export one or more method-specific server identifiers
  (Server-Id(s)).  EAP methods MAY also support the import and export
  of channel binding parameters.  EAP method specifications developed
  after the publication of this document MUST define the Peer-Id,
  Server-Id and Session-Id.  The Peer-Id(s) and Server-Id(s), when
  provided, identify the entities involved in generating the
  keying material exported by the EAP method.  For existing
  EAP methods the Peer-Id, Server-Id and Session-Id are defined in
  Appendix A."

In Section 1.4.1, change the following text from:

"  Each key created within the EAP key management framework has
  a name (a unique identifier),
  as well as a scope (the parties to whom the key is available).
  The scope of exported keying material and TEKs is defined by the 
authenticated
  peer identities (Peer-Id(s)) and the authenticated server identities
  (Server-Id(s)), where available.  Where an EAP method that derives
  keys does not provide a Server-Id,
  the EAP peer will not know the identity of the EAP server with which it
  derived EAP keying material.  Where an EAP method that derives keys
  does not provide a Peer-Id, the EAP server will not know the identity
  of the EAP peer with which it derived EAP keying material."

To:

" Each key created within the EAP key management framework has
 a name (a unique identifier), as well as a scope (the parties to whom
 the key is available).  The scope of exported keying material and TEKs is
 defined by the authenticated peer identities (Peer-Id(s)) and the
 authenticated server identities (Server-Id(s)), where available.
 Where an EAP method that derives keys does not provide a Server-Id,
 the EAP peer will not know the identity of the EAP server with which it
 derived EAP keying material.  Where an EAP method that derives keys
 does not provide a Peer-Id, the EAP server will not know the identity
 of the EAP peer with which it derived EAP keying material.

  An EAP method that satisfies the [RFC4017] mandatory security
  requirements will typically provide a non-null Peer-Id;  however
  it is possible for an EAP method to satisfy the [RFC4017] mandatory
  security requirements while providing a null Server-Id.

  In an EAP method where EAP keying material is generated solely based on
  a TLS exchange involving server-only certificate authentication,
  the Peer-Id would be the null string and the Server-Id(s) would be 
determined
  from the server certificate.  Even where Peer-Id(s)/Server-Id(s) are
  exported by an inner EAP method, if keying material derived from the
  inner exchange is not incorporated into EAP keying material exported
  by the tunnel method, then the inner identities are not relevant for the
  purpose of determining the tunnel method's Peer-Id(s)/Server-Id(s).
  This is true even if the tunnel method proves that a single peer
  or server participated in the inner and outer authentications.

  If a server identity is not claimed, the Server-Id is the null string.
  However, if a server identity is claimed and authenticated, then a
  Server-Id can be provided, even if the server only proves possession
  of a shared secret or password.  For example, a method providing
  for exchange of method-specific peer and server identities can prove
  that both the peer and server possess a shared secret or password.
  In this case both a Peer-Id and Server-Id can be provided, even
  though the server identity was not confirmed as it would be where
  server certificate authentication is supported."

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] The NAS-Identifier is a Channel Binding parameter that is treated as
an opaque blob by EAP methods.  This is described in Sections 1.4 and
5.3.3.

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

[BA]  What IKEv2 calls IDi corresponds to the EAP-Response/Identity;
this may not be the same as the Peer-Id.

RFC 3748 notes that the contents of the EAP-Response/Identity should only
used for routing purposes, and similar considerations apply to IDi.
For example, the EAP-Response/Identity might be a "decorated NAI"
as defined in RFC 4284, such as "microsoft.com!charliek [at] bt.com", while the
Peer-Id determined from EAP-TLS might be "charliek [at] microsoft.com".

Assuming that IKEv2 responders place IDi into the RADIUS User-Name
Attribute as well as an EAP-Message/EAP-Response/Identity Attribute,
and the EAP method implementation does not require a match between
the EAP-Response/Identity and the Peer-Id, then I don't think any
problems will result from this.

I don't think that any new text is required in the document to
clarify this point.

[Charliek]
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]  I agree with your point.

I think what is meant here is that the server identity has not
been authenticated, so that if the peer subsequently needs to identify
the server, it cannot.  For example, the peer cannot later
say to another authenticator "I engaged in a successful
authentication with server X, who can verify this" because the peer
didn't determine the server's identity.

The suggested text addition is:

"Where the EAP method does not provide a Server-Id, it is not possible
for the peer to identify the EAP server with which it generated keying
material.  This could be problematic if it is subsequently necessary for
the EAP peer to refer to a key possessed by that EAP server."