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

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 15 Oct 2007 19:27:38 -0700

From: Charlie Kaufman <[email-masked]
To: "[email-masked]" <[email-masked], "[email-masked]" <[email-masked],
    Bernard Aboba <[email-masked],        Dan
Simon<[email-masked],        "[email-masked]"
<[email-masked],        "[email-masked]"
<[email-masked]
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 "[email-masked]" 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."

_________________________________________________________________
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: Mon, 15 Oct 2007 19:29:21 -0700

From: Bernard Aboba <[email-masked]>
To: [email-masked]
Cc: [email-masked]
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 <[email-masked]
To: "[email-masked]" <[email-masked], "[email-masked]" <[email-masked],
   Bernard Aboba <[email-masked],        Dan
Simon<[email-masked],        "[email-masked]"
<[email-masked],        "[email-masked]"
<[email-masked]
Subject: [secdir] secdir review of draft-ietf-eap-keying-18.txt
Date: Sun, 25 Feb 2007 18:55:23 -0800

[Charliek]

To:

IEEE 802.1X-2004

IKEv2

IEEE 802.11

IEEE 802.16e