From: Bernard Aboba <bernard_aboba hotmail.com>
To: sec-dirmit.edu
Cc: eapfrascone.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 <charliekexchange.microsoft.com
To: "iesgietf.org" <iesgietf.org,
"secdirmit.edu" <secdirmit.edu,
Bernard Aboba <bernardawindows.microsoft.com,
Dan
Simon<dansimonmicrosoft.com,
"Pasi.Eronennokia.com"
<Pasi.Eronennokia.com, "henriklevkowetz.com"
<henriklevkowetz.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 "charliekmicrosoft.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."
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|