Subject: [eap] Proposed Resolution to Issue 183

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Oct 2003 10:52:35 -0700 (PDT)

Here is the proposed Resolution to Issue 183, which involves adding new
sections 3-3.4.  I'd like to split off the discussion of Service SAs into
a separate issue, and will post a proposed resolution to that in a separate
mail.

Proposed fix:

Replace Sections 3, 3.1 and 3.2 with the following:

3. Security Associations

EAP key management involves five types of security associations
(SAs):

[1] EAP SA. This is an SA between the peer and
EAP server, which allows them to authenticate each other.

[2] EAP method SA. This SA is also between the peer
and EAP server. It stores state that can be used
for "fast resume" or other functionality in some
EAP methods. Not all EAP methods create such an SA.

[3] EAP-Key SA. This is an SA between the peer and EAP
server, which is used to store the keying material
exported by the EAP method. Current EAP
server implementations do not retain this SA after
the EAP conversation completes, but future implementations
could use this SA for pre-emptive key distribution.

[4] AAA SA(s). These SAs are between the authenticator and the
backend authentication server. They permit the parties to
mutually authenticate each other and protect the communications
between them.

[5] Service SA(s). These SAs are between the peer and authenticator,
and they are created as a result of phases 1-2 of the
conversation (see Section 1.3).  Service SA(s) are required for the
derivation of transient session keys (TSKs) as well as for the
transmission of unicast and multicast data traffic.

3.1 EAP SA (peer - EAP server)

In order for the peer and EAP server to authenticate each
other, they need to store some information.

The authentication can be based on different mechanisms, such
as shared secrets or certificates. If the authentication is
based on a shared secret key, the parties store the EAP
method to be used and the key. The EAP server also stores
the peer's identity and/or other information necessary to
decide whether access to some service should be granted.
The peer stores information necessary to choose which secret
to use for which service.

3.2 EAP method SA (peer - EAP server)

An EAP method may store some state on the peer and EAP
server even after phase 1a has completed.

Typically, this is used for "fast resume": the peer and
EAP server can confirm that they are still talking to the
same party, perhaps using fewer roundtrips or less
computational power. In this case, the EAP method SA is
essentially a cache for performance optimization, and either
party may remove the SA from its cache at any point.

An EAP method may also keep state in order to support
pseudonym-based identity protection. This is typically a
cache as well (the information can be recreated if the
original EAP method SA is lost), but may be stored for
longer periods of time.

The EAP method SA is not restricted to a particular
service or authenticator and is most useful when the peer
accesses many different authenticators.

An EAP method is responsible for specifying how the parties
select if an existing EAP method SA should be used, and if so,
which one. Where multiple backend authentication servers
are used, EAP method SAs are not typically synchronized
between them.

EAP method implementations should consider the appropriate
lifetime for the EAP method SA. "Fast resume" assumes that
the information required (primarily the keys in the EAP method
SA) hasn't been compromised. In case the original authentication
was carried out using, for instance, a smart card, it may be
easier to compromise the EAP method SA (stored on the PC,
for instance), so typically the EAP method SAs have a limited
lifetime.

Contents:

o Implicitly, the EAP method this SA refers to
o One or more internal (non-exported) keys
o EAP method SA name
o SA lifetime

3.2.1 Example: EAP-TLS

In EAP-TLS [RFC2716], after the EAP authentication the client (peer)
and server can store the following information:

o Implicitly, the EAP method this SA refers to (EAP-TLS)
o Session identifier (a value selected by the server)
o Certificate of the other party (server stores the clients's
certificate and vice versa)
o Ciphersuite and compression method
o TLS Master secret (known as the EAP-TLS Master Key or MK)
o SA lifetime (ensuring that the SA is not stored forever)
o If the client has multiple different credentials (certificates
and corresponding private keys), a pointer to those credentials

When the server initiates EAP-TLS, the client can look up the
EAP-TLS SA based on the credentials it was going to use
(certificate and private key), and the expected credentials
(certificate or name) of the server. If an EAP-TLS SA exists,
and it is not too old, the client informs the server about
the existence of this SA by including its Session-Id in the
TLS ClientHello message. The server then looks up the correct
SA based on the Session-Id (or detects that it doesn't yet
have one).

3.2.2 Example: EAP-AKA

In EAP-AKA [AKA], after EAP authentication the client and
server can store the following information:

o Implicitly, the EAP method this SA refers to (EAP-AKA)
o A re-authentication pseudonym
o The client's permanent identity (IMSI) (server)
o Replay protection counter
o Authentication key (K_aut)
o Encryption key (K_encr)
o Original Master Key (MK)
o SA lifetime (ensuring that the SA is not stored forever)

When the server initiates EAP-AKA, the client can look up the
EAP-AKA SA based on the credentials it was going to use
(permanent identity). If an EAP-AKA SA exists, and it is not
too old, the client informs the server about the existence of
this SA by sending its re-authentication pseudonym as its
identity in EAP Identity Response message, instead of its
permanent identity. The server then looks up the correct SA
based on this identity.

3.3 EAP-key SA

This is an SA between the peer and EAP server, which is used
to store the keying material exported by the EAP method.
Current EAP server implementations do not retain this SA after
the EAP conversation completes, but future implementations
could use this SA for pre-emptive key distribution.

Contents:
o Name/identifier for this SA
o Identities of the parties
o MSK and EMSK

3.4 AAA SA(s) (authenticator - backend authentication server)

In order for the authenticator and backend authentication
server to authenticate each other, they need to store some
information.

In case the authenticator and backend authentication server
are colocated, and they communicate using local procedure
calls or shared memory, this SA need not necessarily contain
any information.

3.4.1 Example: RADIUS

In RADIUS, where shared secret authentication is used, the
client and server store each other's IP address and the
shared secret, which is used to calculate the Response
Authenticator [RFC2865] and Message-Authenticator [RFC3579]
values, and to encrypt some attributes (such as the
AAA-Key [RFC2548]).

Where IPsec is used to protect RADIUS [RFC3579] and
IKE is used for key management, the parties store
information necessary to authenticate and authorize
the other party (e.g. certificates, trust anchors and
names). The IKE exchange results in IKE Phase 1 and
Phase 2 SAs containing information used to protect
the conversation (session keys, selected ciphersuite, etc.)

3.4.2 Example: Diameter with TLS

When using Diameter protected by TLS, the parties store
information necessary to authenticate and authorize the
other party (e.g. certificates, trust anchors and names).
The TLS handshake results in a short-term TLS SA that contains
information used to protect the actual communications
(session keys, selected TLS ciphersuite, etc.).
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap