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

[Bernard Aboba (bernard_aboba]

From: Bernard Aboba <bernard_aboba [at] hotmail.com>
To: sec-dir [at] mit.edu
Cc: eap [at] frascone.com
Subject: Re: [secdir] secdir review of draft-ietf-eap-keying-18.txt (part 2)
Sent: Monday, October 15, 2007 7:27 PM
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

[Charliek]
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] P25 1st paragraph reads:

"  As a result, an EAP peer, on connecting to a new authenticator or
 reconnecting to the same authenticator, may find itself communicating
 with a different EAP server.  Fast reconnect, defined in [RFC3748]
 Section 7.2, may fail if the EAP server that the peer communicates
 with is not the same one with which it initially established a
 security association.  For example, an EAP peer attempting an EAP-TLS
 session resume may find that the new EAP-TLS server will not have
 access to the TLS Master Key identified by the TLS Session-Id, and
 therefore the session resumption attempt will fail, requiring
 completion of a full EAP-TLS exchange.
"

This paragraph is getting at the fact that an EAP peer doesn't "direct"
its traffic to a particular EAP server; rather, it only specifies the
realm within which the server resides (via the EAP-Response/Identity),
and the request is routed by the AAA system.  Since the routing can
be dynamic, the EAP peer may not be routed to the same EAP server
on every connection to a particular authenticator, or on movement
from one authenticator to a nearby one.  This can make it difficult
for the EAP peer to make use of facilities such as TLS Session Resume.

For example, the user might provide "charliek [at] microsoft.com" within
the EAP-Response/Identity, and on first connection the EAP server
might be "radius1.corp.ntdev.microsoft.com".  On the second
connection, the request could be routed to "radius2.corp.ntdev.
microsoft.com" - and TLS Session Resume might fail.  Similar
things can happen with load balanced web farms, but typically
with HTTPS: the client has an expectation that the server
certificate subjectAltName contain the FQDN it put into the
HTTP GET.

or did you mean P26 1st paragraph?  That one reads:

"   Where the backend server FQDN differs from the subjectAltName in the
 certificate, the AAA client may not be able to successfully determine
 whether it is talking to the correct backend authentication server.
 Where the Server-Id and backend server FQDN differ, the combination
 of the key scope (Peer-Id, Server-Id) and EAP conversation identifier
 (Session-Id) may not be sufficient for the authenticator to determine
 where the key resides.  For example, the authenticator may identify
 backend servers by their IP address (as occurs in RADIUS), or using a
 Fully Qualified Domain Name (as in Diameter).  If the Server-Id does
 not correspond to the IP address or FQDN of a known backend
 authentication server, then the authenticator will not know which
 backend authentication server possesses the key.
"
The paragraph is attempting to address several potential issues.
One is the consequence of a mismatch between the server FQDN and the
subjectAltName, which could result in an authentication failure
between the AAA client and server.

Diameter utilizes either IPsec/IKE or TLS for transmission
layer security, so clients and server identities can often
be determined from their certificates, and if these do not
match the FQDNs utilized in Diameter URIs, connection setup
will fail.  Since in RADIUS [RFC2865] clients and servers
identify each other by their IP addresses and utilize
shared secrets for authentication, this issue typically
will not arise.

Another issue is a mismatch between the EAP Server-Id and
and the AAA server FQDN.  RFC 2716bis Section 5.2 states:

"  A server identity will typically represent a host, not a user or a
 resource.  As a result, a subjectAltName of type dnsName SHOULD be
 present in the server certificate.  If a dnsName is not available
 other field types (for example a subjectAltName of type ipAddress or
 uniformResourceIdentifier) MAY be used."

There are situations in which the Server-Id may not be present or
may not match the FQDN of the backend authentication server.
For example, not all EAP methods export a Server-Id, and
there is no requirement that the EAP Server-Id match the FQDN
of the backend server that it resides on.  For
example, a given backend server might handle multiple
realms but might have only a single IP address and
corresponding FQDN.  It is also possible that the Server-Id
might not match the identity provided in the backend server
certificate in type and/or contents.

To improve clarity, I would suggest changing the paragraph from:

"  Where the backend server FQDN differs from the subjectAltName in the
 certificate, the AAA client may not be able to successfully determine
 whether it is talking to the correct backend authentication server.
 Where the Server-Id and backend server FQDN differ, the combination
 of the key scope (Peer-Id, Server-Id) and EAP conversation identifier
 (Session-Id) may not be sufficient for the authenticator to determine
 where the key resides.  For example, the authenticator may identify
 backend servers by their IP address (as occurs in RADIUS), or using a
 Fully Qualified Domain Name (as in Diameter).  If the Server-Id does
 not correspond to the IP address or FQDN of a known backend
 authentication server, then the authenticator will not know which
 backend authentication server possesses the key."

To:

"  Where the backend authentication server FQDN differs from the 
subjectAltName
 in the server certificate, it is possible that the AAA client will not be 
able
 to determine whether it is talking to the correct backend authentication
 server.  Similarly, where the AAA client FQDN differs from
 the subjectAltName in the client certificate, it is possible that
 the backend authentication server will not be able to determine
 whether it is talking to the correct AAA client.  As a result,
 the AAA client and backend authentication server can fail to
 mutually authenticate each other.

 Not all EAP methods export the Server-Id, and where the
 Server-Id is exported, it is possible that it will not match
 the identity of the backend authentication server in type or
 contents.  For example, depending on the EAP method, the
 Server-Id could be expressed as an FQDN, an RDN, an
 IP address, etc., Similarly, depending on the authentication
 mechanism used by the AAA protocol, the backend authentcation
 server identity might be an IP address (RADIUS),
 or an FQDN (Diameter or RADIUS over IPsec utilizing
 IKE with certificate authentication).  As a result, it
 can prove difficult to determine which backend authentication
 server contains EAP keying material based on the Server-Id
 exported by the EAP method.  As a result, the combination of
 the key scope and name (Server-Id, Session-Id) is not
 necessarily sufficient to determine which backend
 authentication server possesses the specified keying material."

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] Section 1.3.1 provides examples of existing EAP lower layers and
describes whether they include support for a Secure Association
Protocol.  Section 2.1 describes how existing EAP lower layers
generate transient session keys and the resulting cryptographic
properties.  As noted in Section 2.1, the security properties of
existing SAPs are not ideal.

The function of Section 3.1 is to describe the
functionality that Secure Association Protocols should provide.
As a result, it represents more of a set of criteria by which SAP
designs should be judged than the description of an existing SAP.

To make this more clear, I propose to add a section 3.1.1
describing how existing SAP designs stack up against the
requirements of Section 3.1.

Also, I propose changing the text in Section 2.1 to include more
information on the functionality of existing EAP lower layers:

"2.1.  Transient Session Keys

 Where explicitly supported by the lower layer, lower layers MAY cache
 keying material, including exported EAP keying material and/or TSKs;
 the structure of this key cache is defined by the lower layer.  So as
 to enable interoperability, new lower layer specifications MUST
 describe key caching behavior.  Unless explicitly specified by the
 lower layer, the EAP peer, server and authenticator MUST assume that
 peers and authenticators do not cache keying material.  Existing EAP
 lower layers and AAA layers handle the generation of transient
 session keys and caching of EAP keying material in different ways:

IEEE 802.1X-2004
   When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] does
   not support link layer ciphersuites and a result, it does not
   provide for generation of TSKs, or caching of EAP keying material
   and parameters.  Once EAP authentication completes, it is assumed
   that EAP keying material and parameters are discarded; on IEEE 802
   wired networks there is no subsequent Secure Association Protocol
   exchange.  Perfect Forward Secrecy (PFS) is only possible if the
   negotiated EAP method supports this.

PPP  PPP, defined in [RFC1661] does not include support for a Secure
   Association Protocol; nor does it support caching of EAP keying
   material or parameters.  PPP ciphersuites derive their TSKs
   directly from the MSK, as described in [RFC2716].  This is NOT
   RECOMMENDED, since if PPP were to support caching of EAP keying
   material, this could result in TSK reuse.  As a result, once the
   PPP session is terminated, EAP keying material and parameters MUST
   be discarded.  Since caching of EAP keying material is not
   permitted within PPP, there is no way to handle TSK re-key without
   EAP re-authentication.  Perfect Forward Secrecy (PFS) is only
   possible if the negotiated EAP method supports this.

IKEv2
   IKEv2, defined in [RFC4306] only uses the MSK for authentication
   purposes and not key derivation.  The EMSK, IV, Peer-Id, Server-Id
   or Session-Id are not used.  As a result, the TSKs derived by IKEv2
   are cryptographically independent of the EAP keying material and
   re-key of IPsec SAs can be handled without requiring EAP re-
   authentication.  Within IKEv2 it is possible to negotiate PFS,
   regardless of which EAP method is negotiated.  IKEv2 as specified
   in [RFC4306] does not cache EAP keying material or parameters; once
   IKEv2 authentication completes it is assumed that EAP keying
   material and parameters are discarded.  The Session-Timeout
   attribute is therefore interpreted as a limit on the VPN session
   time, rather than an indication of the MSK key lifetime.

IEEE 802.11
   IEEE 802.11 enables caching of the MSK, but not the EMSK, IV, Peer-
   Id, Server-Id, or Session-Id.  More details about the structure of
   the cache are available in [IEEE-802.11].  In IEEE 802.11, TSKs are
   derived from the MSK using a Secure Association Protocol known as
   the 4-way handshake, which includes a nonce exchange.  This
   guarantees TSK freshness even if the MSK is reused.  The 4-way
   handshake also enables TSK re-key without EAP re-authentication.
   PFS is only possible within IEEE 802.11 if caching is not enabled
   and the negotiated EAP method supports PFS.

IEEE 802.16e
   IEEE 802.16e, defined in [IEEE-802.16e] supports caching of the
   MSK, but not the EMSK, IV, Peer-Id, Server-Id or Session-Id.  IEEE
   802.16e support a Secure Association Protocol in which TSKs are
   chosen by the authenticator without any contribution by the peer.
   The TSKs are encrypted, authenticated and integrity protected using
   the MSK and are transported from the authenticator to the peer.
   TSK re-key is possible without EAP re-authentication.  PFS is not
   possible even if the negotiated EAP method supports it."

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] In order to enable the peer and authenticator to
skip EAP authentication, and proceed directly to the SAP,
it is necessary for them to determine whether they already
hold keying material in common.

For example, in IEEE 802.11, many lightweight APS can be attached
to a controller acting as an authenticator.  Since the 4-way
handshake identifies the APs by their MAC address, but not does
not identify the authenticator, without additional assistance the
STA cannot determine whether it already possesses a PMK for a
lightweight AP that it hadn't previously attached to, even
if that lightweight AP is connected to an authenticator
with which the STA had successfully completed an EAP exchange.
This can lead to the STA initiating unnecessary EAP exchanges
with lightweight APs, wasting time and resources on the
EAP peer, authenticator and server.

As a result, the SAP needs to explicitly identify the authenticator,
or at least the ports attached to the same authenticator.  Even where the 
latter
approach is supported (such as in IEEE 802.11k [IEEE-802.11k[ and IEEE 
802.16e
[IEEE-802.16e]) support for authenticator identification is still
valuable since:

1) An authenticator can have many attached ports and limitations
of the EAP lower layer (such as frame size and fragmentation
limitations) can prevent ennumerating all of them to the peer.
If the authenticator can only provide a partial list of its
ports to the peer, then if the authenticator does not correctly
anticipate which ports the peer will find to be desirable
handoff candidates, then unnecessary EAP exchange can result.
2) Without providing the authenticator identity to the peer,
the peer and server cannot verify that the authenticator has provided
the same identity to both of them (channel bindings).

Some of the same issues can arise with respect to peer identification.
A peer can have multiple interfaces and it can be desirable to
allow EAP keying material to be used on all of them.
However if the SAP only identifies the ports of the peer (e.g.
using an IP or MAC address) but not the peer itself, then
the authenticator cannot recognize that already possesses
a key for the peer when it encounters a peer port that it had not
previously connected with.  As a result, the authenticator
will require the peer to complete an unnecessary EAP authentication
on each port.  One solution to this problem is for the SAP to
utilize a peer identifier rather than a port identifier.
In order to address potential privacy issues, the actual Peer-Id
is not required; an identifier such as the CUI [RFC4372] could
be used instead.

Is a change needed to make this more clear?

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] As noted in (f),  either explicit key lifetime negotiation or
re-key are ok.

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] Repeating the EAP exchange will work as long as the EAP
lower layer can reliably determine when to do this.  In some
cases (such as with IEEE 802.11w), lower layer failure indications may
be protected so that if one side loses key state, it may not
longer be able to determine when it has lost synchronization,
unless it sets a timer.  For example, in IEEE 802.11w, STAs
or APs that have key state will silently discard unauthenticated
Disassociate and Deauthenticate frames.

Here is a proposed modification to the text:

"(g) Key state resynchronization.  It is possible for the peer or
authenticator to reboot or reclaim resources, clearing portions or
all of the key cache.  Therefore, key lifetime negotiation cannot
guarantee that the key cache will remain synchronized, and it may
not be possible for the peer to determine before attempting to use a key 
whether
it exists within the authenticator cache.  It is therefore
RECOMMENDED for the EAP lower layer to provide a mechanism for key
state resynchronization, either via the SAP or using a lower layer
indication (see [RFC3748] Section 3.4).  Where the peer and authenticator
do not jointly possess a key with which to protect the resynchronization
exchange, secure resychronization is not possible and
alternatives (such as a initiation of EAP re-authentication
after expiration of a timer) is needed to
ensure timely resynchronization."