draft-ietf-eap-keying-19.txt   draft-ietf-eap-keying-20.txt 
EAP Working Group Bernard Aboba EAP Working Group Bernard Aboba
Internet Draft Dan Simon Internet Draft Dan Simon
Updates: 3748 Microsoft Corporation Updates: 3748 Microsoft Corporation
Category: Standards Track P. Eronen Category: Standards Track P. Eronen
Expires: April 23, 2008 Nokia Expires: May 1, 2008 Nokia
23 October 2007 30 October 2007
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
draft-ietf-eap-keying-19.txt draft-ietf-eap-keying-20.txt
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 23, 2008. This Internet-Draft will expire on May 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). All rights reserved. Copyright (C) The IETF Trust (2007). All rights reserved.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748, The Extensible Authentication Protocol (EAP), defined in RFC 3748,
enables extensible network access authentication. This document enables extensible network access authentication. This document
specifies the EAP key hierarchy and provides a framework for the specifies the EAP key hierarchy and provides a framework for the
transport and usage of keying material and parameters generated by transport and usage of keying material and parameters generated by
EAP authentication algorithms, known as "methods". It also provides EAP authentication algorithms, known as "methods". It also provides
a detailed system-level security analysis, demonstrating compliance a detailed system-level security analysis, describing the conditions
with the key management guidelines described in RFC 4962. under which the key management guidelines described in RFC 4962 can
be satisfied.
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 7 1.3 Overview ........................................ 7
1.4 EAP Key Hierarchy ............................... 9 1.4 EAP Key Hierarchy ............................... 9
1.5 Security Goals .................................. 13 1.5 Security Goals .................................. 13
1.6 EAP Invariants .................................. 14 1.6 EAP Invariants .................................. 14
skipping to change at page 3, line 28 skipping to change at page 3, line 28
used by EAP methods themselves and part of this material can be used by EAP methods themselves and part of this material can be
exported. In addition to export of keying material, EAP methods can exported. In addition to export of keying material, EAP methods can
also export associated parameters such as authenticated peer and also export associated parameters such as authenticated peer and
server identities and a unique EAP conversation identifier, and can server identities and a unique EAP conversation identifier, and can
import and export lower layer parameters known as "channel binding import and export lower layer parameters known as "channel binding
parameters", or simply "channel bindings". parameters", or simply "channel bindings".
This document specifies the EAP key hierarchy and provides a This document specifies the EAP key hierarchy and provides a
framework for the transport and usage of keying material and framework for the transport and usage of keying material and
parameters generated by EAP methods. It also provides a detailed parameters generated by EAP methods. It also provides a detailed
security analysis, demonstrating compliance with the requirements security analysis, describing the conditions under which the
described in "Guidance for Authentication, Authorization and requirements described in "Guidance for Authentication, Authorization
Accounting (AAA) Key Management" [RFC4962]. and Accounting (AAA) Key Management" [RFC4962] can be satisfied.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
The terms "Cryptographic binding", "Cryptographic separation", "Key The terms "Cryptographic binding", "Cryptographic separation", "Key
skipping to change at page 27, line 26 skipping to change at page 27, line 26
EAP methods that export the Server-Id MUST authenticate the server. EAP methods that export the Server-Id MUST authenticate the server.
However, not all EAP methods supporting mutual authentication provide However, not all EAP methods supporting mutual authentication provide
a non-null Server-Id; some methods only enable the EAP peer to verify a non-null Server-Id; some methods only enable the EAP peer to verify
that the EAP server possesses a long-term secret, but do not provide that the EAP server possesses a long-term secret, but do not provide
the identity of the EAP server. In this case the EAP peer will know the identity of the EAP server. In this case the EAP peer will know
that an authenticator has been authorized by an EAP server, but will that an authenticator has been authorized by an EAP server, but will
not confirm the identity of the EAP server. Where the EAP method not confirm the identity of the EAP server. Where the EAP method
does not provide a Server-Id, the peer cannot identify the EAP server does not provide a Server-Id, the peer cannot identify the EAP server
with which it generated keying material. This can make it difficult with which it generated keying material. This can make it difficult
for the EAP peer to identity the location of a key possessed by that for the EAP peer to identify the location of a key possessed by that
EAP server. EAP server.
As noted in [I-D.simon-emu-rfc2716bis] Section 5.2, EAP methods As noted in [I-D.simon-emu-rfc2716bis] Section 5.2, EAP methods
supporting authentication using server certificates can determine the supporting authentication using server certificates can determine the
Server-Id from the subject or subjectAltName fields in the server Server-Id from the subject or subjectAltName fields in the server
certificate. Validating the EAP server identity can help the EAP certificate. Validating the EAP server identity can help the EAP
peer to decide whether a specific EAP server is authorized. In some peer to decide whether a specific EAP server is authorized. In some
cases, such as where the certificate extensions defined in [RFC4334] cases, such as where the certificate extensions defined in [RFC4334]
are included in the server certificate, it can even be possible for are included in the server certificate, it can even be possible for
the peer to verify some Channel Binding parameters from the server the peer to verify some Channel Binding parameters from the server
certificate. certificate.
It is possible for problems to arise in situations where the EAP It is possible for problems to arise in situations where the EAP
server identifies itself differently to the EAP peer and server identifies itself differently to the EAP peer and
authenticator. For example, it is possible that the Server-Id authenticator. For example, it is possible that the Server-Id
exported by EAP methods will not be identical to the Fully Qualified exported by EAP methods will not be identical to the Fully Qualified
Domain Name (FQDN) of the backend authentication server. Where Domain Name (FQDN) of the backend authentication server. Where
certificate-based authentication is used within RADIUS or Diameter, certificate-based authentication is used within RADIUS or Diameter,
it is possible that the subjectAltName used in the backend it is possible that the subjectAltName used in the backend
authentication server certificate will not be identical to the authentication server certificate will not be identical to the
Server-Id or backend authentication server FQDN. Server-Id or backend authentication server FQDN. This is not
normally an issue in EAP, as the authenticator will be unaware of the
identities used between the EAP peer and server. However, this can
be an issue for key caching, if the authenticator is expected to
locate a backend authentication server corresponding to a Server-Id
provided by an EAP peer.
Where the backend authentication server FQDN differs from the Where the backend authentication server FQDN differs from the
subjectAltName in the backend authentication server certificate, it subjectAltName in the backend authentication server certificate, it
is possible that the AAA client will not be able to determine whether is possible that the AAA client will not be able to determine whether
it is talking to the correct backend authentication server. Where it is talking to the correct backend authentication server. Where
the Server-Id and backend server FQDN differ, it is possible that the the Server-Id and backend server FQDN differ, it is possible that the
combination of the key scope (Peer-Id(s), Server- Id(s)) and EAP combination of the key scope (Peer-Id(s), Server- Id(s)) and EAP
conversation identifier (Session-Id) will not be sufficient to conversation identifier (Session-Id) will not be sufficient to
determine where the key resides. For example, the authenticator can determine where the key resides. For example, the authenticator can
identify backend servers by their IP address (as occurs in RADIUS), identify backend servers by their IP address (as occurs in RADIUS),
 End of changes. 7 change blocks. 
11 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/