One document matched: draft-zhou-emu-pp-eap-01.txt
Differences from draft-zhou-emu-pp-eap-00.txt
EMU H. Zhou, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track M. Nakhjiri, Ed.
Expires: January 9, 2008 Huawei USA
H. Tschofenig, Ed.
Siemens Networks GmbH & Co KG
July 8, 2007
PP-EAP - A Protected Password-Based EAP Method
draft-zhou-emu-pp-eap-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines the Protected Password-based Extensible
Authentication Protocol (EAP) method. PP-EAP is an EAP method that
enables secure exchange of password authentication mechanisms between
a peer and an EAP server by using the Transport Layer Security (TLS)
to establish a server-authenticated TLS tunnel. Within the tunnel,
Zhou, et al. Expires January 9, 2008 [Page 1]
Internet-Draft PP-EAP July 2007
Type-Length-Value (TLV) objects are used to convey password-based
authentication between the peer and the EAP server.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 5
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Version Negotiation . . . . . . . . . . . . . . . . . . . 6
4.3. Phase 1: Tunnel Establishment . . . . . . . . . . . . . . 6
4.4. Phase 2: Password Authentication Exchange . . . . . . . . 7
4.4.1. Failure/ Error handling . . . . . . . . . . . . . . . 8
4.5. Protected Termination . . . . . . . . . . . . . . . . . . 9
4.6. Session Resumption . . . . . . . . . . . . . . . . . . . . 11
4.7. Determining Peer-Id and Server-Id . . . . . . . . . . . . 11
4.8. PP-EAP Session Identifier . . . . . . . . . . . . . . . . 12
4.9. Cryptographic Agility . . . . . . . . . . . . . . . . . . 12
4.10. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
4.11. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 12
4.11.1. PP-EAP Message Format . . . . . . . . . . . . . . . . 13
4.11.2. TLV Format . . . . . . . . . . . . . . . . . . . . . . 14
4.11.3. Password-Authentication TLV . . . . . . . . . . . . . 16
4.11.4. Result TLV . . . . . . . . . . . . . . . . . . . . . . 17
4.11.5. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 18
4.11.6. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 19
4.11.7. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 20
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
6.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 23
6.2. Server Certificate Validation . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Zhou, et al. Expires January 9, 2008 [Page 2]
Internet-Draft PP-EAP July 2007
1. Introduction
There were several existing EAP methods that support password-based
authentications developed over the years, for example, PEAP, EAP-
FAST, and EAP-TTLS. Most of them are based on Transport Layer
Security (TLS) to establish a protected TLS tunnel and then exchange
password-based authentication within the TLS tunnel. However, there
are several reasons that prompt the work on a new password-based EAP
method:
1. There is no standard track based password based EAP method. The
EAP methods listed above are either expired Internet draft or
Informational RFC. The Internet community and other standard
bodies call for a standard track based password-based EAP method
for better interoperability.
2. There is no standard mechanism and format defined for the inner
data exchange, nor the mechanism to support cryptographic binding
and extend the data exchanged inside the tunnel.
3. None of the existing EAP methods listed above supports
cryptographic algorithm agility.
The protocol defined in this document intends to address these
limitations as a standard tracked based password-based EAP method.
While in first version it only supports password-based
authentication, it is designed with an extensibility framework so
additional authentications and data exchanges can be added in the
future without changing the basic protocol operation.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
This document uses the terminology defined in EAP [8] and EAP Keying
Management Framework draft. Additional terms are defined below:
Cryptographic Algorithm Agility
Ability for a protocol to disable a cryptographic algorithm and
negotiate a different algorithm when a new vulnerability specific
to an algorithm is discovered, as well as ability to allow
deployment of new cryptographic algorithms to be done
incrementally.
Zhou, et al. Expires January 9, 2008 [Page 3]
Internet-Draft PP-EAP July 2007
Compound MAC Key (CMK)
Key used to generate the compound Message Authentication Code
(MAC) during cryptographic binding.
Compound Session Key (CSK)
Session key consists of the MSK and EMSK, derived from the
combination of the Tunnel key and inner method key.
Tunnel Key (TK)
Key derived as part of the TLS Tunnel establishment and used to
derive the CSK.
3. Design Requirements
The following are mandatory requirements that guided the work on this
EAP method:
1. Support secure transport of clear text password to support
legacy user name and password databases, such as One-time
Password (OTP) and LDAP.
2. Provide mutual authentication.
3. Provide resistance to offline dictionary attacks, man-in-the-
middle attacks, and replay attacks.
4. Comply with RFC 3748, RFC 4017, EAP keying management framework
draft (including MSK and EMSK generation).
5. Support user identity confidentiality for the peer.
6. Support cipher suite negotiation and cryptographic algorithm
agility.
7. Support session resumption and avoid the need for use to re-
enter the password every time).
8. Support protected result indication.
9. Support fragmentation and reassembly.
10. Support standard way of extending inner data exchanges to other
than password-based authentications.
The following requirements are optional and nice to have:
o Support password/PIN changes.
o Support cryptographic binding to make sure the inner
authentication method and outer TLS tunnel exchange are terminated
by the same peers.
o Support other password based protocols (CHAP, MSCHAP, etc).
o Support for carrying payloads of the Extensible Authentication
Protocol (EAP).
o Support of carrying other data exchanges within the tunnel. An
specific example for this type of data exchange is channel binding
data.
Zhou, et al. Expires January 9, 2008 [Page 4]
Internet-Draft PP-EAP July 2007
o Support online server certificate validation such as OCSP.
4. Protocol Specification
4.1. Overview
The network architectural model for PP-EAP usage is shown below:
+----------+ +----------+ +----------+ +----------+
| | | | | | | User |
| Peer |<---->| Authen- |<---->| PP-EAP |<---->| Database |
| | | ticator | | Server | | Server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
PP-EAP Architectural Model
The entities depicted above are logical entities and may or may not
correspond to separate network components. For example, the PP-EAP
server and user database server might be a single entity; the
authenticator and PP-EAP server might be a single entity; or the
functions of the authenticator, PP-EAP server, and user database
server might be combined into a single physical device. For example,
typical IEEE 802.11 deployments place the Authenticator in an access
point (AP) while a Radius Server may provide the PP-EAP and user
database server components. The above diagram illustrates the
division of labor among entities in a general manner and shows how a
distributed system might be constructed; however, actual systems
might be realized more simply.
The protocol consists of two phases, during the first phase, a TLS
tunnel is established between the peer and the EAP server (PP-EAP
server) with the server authenticating to the client and optionally
the client to the server. The TLS record layer is then used to offer
authentication and integrity/confidentiality protection of the
subsequent interactions. Phase 2 will occur only if establishment of
a protected TLS tunnel in phase 1 was successful. Any data that is
exchanged in Phase 2 is not vulnerable to active and passive man-in-
the-middle attacks. In phase 2, Type-Length-Value (TLV) payloads for
password-based authentication are exchanged. After a successful
authentication protocol exchange the two peers MUST exchange Result
TLVs and Crypto-Binding TLVs to ensure synchronized state and
termination for both the TLS tunnel and inner authentication
exchange.
PP-EAP peer and server implementations MAY support user identity
privacy. Disclosure of the username is avoided by utilizing a
Zhou, et al. Expires January 9, 2008 [Page 5]
Internet-Draft PP-EAP July 2007
privacy Network Access Identifier (NAI) [RFC4282] in the EAP-
Response/Identity in the outer tunnel, and transmitting the real user
identity within the TLS tunnel providing confidentiality.
4.2. Version Negotiation
PP-EAP packets contain a 3-bit version field, following the Flags
field, which enables PP-EAP implementations to be backward compatible
with previous versions of the protocol. This specification documents
the PP-EAP version 1 protocol; implementations of this specification
MUST use a version field set to 1.
Version negotiation proceeds as follows:
In the first EAP-Request sent with EAP type=PP-EAP, the EAP server
must set the version field to the highest supported version
number.
If the EAP peer supports this version of the protocol, it MUST
respond with an EAP-Response of EAP type=PP-EAP, and the version
number proposed by the PP-EAP server.
If the EAP peer does not support this version, it responds with an
EAP-Response of EAP type=PP-EAP and the highest supported version
number.
If the EAP server does not support the version number proposed by
the EAP peer, it terminates the conversation. Otherwise the PP-
EAP conversation continues.
The version negotiation procedure guarantees that the EAP peer and
server will agree to the latest version supported by both parties.
If version negotiation fails, then use of PP-EAP will not be
possible, and another mutually acceptable EAP method will need to be
negotiated if authentication is to proceed.
The PP-EAP version is not protected by TLS; and hence can be modified
in transit. In order to detect a modification of the PP-EAP version,
the peers MUST exchange the PP-EAP version number received during
version negotiation using the Crypto-Binding TLV. The receiver of
the Crypto-Binding TLV MUST verify that the version received in the
Crypto-Binding TLV matches the version sent by the receiver in the
PP-EAP version negotiation.
4.3. Phase 1: Tunnel Establishment
The exchanges for Phase 1 uses the EAP-TLS exchanges as described in
EAP-TLS [7]. For interoperability reasons the ciphersuite
TLS_RSA_WITH_AES_128_CBC_SHA is mandatory to implement. Phase 1
provides the functionality for fragmentation, session resumption,
ciphersuite negotiation and resistance to offline dictionary attacks,
Zhou, et al. Expires January 9, 2008 [Page 6]
Internet-Draft PP-EAP July 2007
man-in-the-middle attacks, and replay attacks. However, the purpose
of this specification is to provide a password-based method for
client authentication. Thus, the EAP-TLS exchange MUST allow for the
EAP peer and server to complete the TLS handshake using only server
certificate, i.e. without requiring the peer to provide a
certificate. Thus the exchange MUST be able to complete without the
need for the peer to respond to a certificate-request from the
server. There are scenarios where multi-factor authentication is
required based on a client certificate authentication followed by a
user password authentication. In such cases the EAP Peer MAY present
the client certificate during phase 1 exchange. The EAP Peer MUST
validate the server certificate during EAP-TLS exchanges, as it will
send its password in the clear inside the TLS tunnel in Phase 2.
Phase 2 will occur only if establishment of a protected TLS tunnel in
phase 1 was successful.
4.4. Phase 2: Password Authentication Exchange
After the TLS encryption channel is established and PP-EAP
Authentication Phase 2 starts, the EAP Server sends Password-
Authentication TLV, which contains a server challenge, often with a
displayable message for the user prompt.
All password authentication exchanges in phase 2 are encapsulated in
Password-Authentication TLVs and must follow the "LABEL=Value"
format. For instance, the server request will be in the form of
"REQUEST=please enter your username and password" and client response
will be in the form of "RESPONSE=test\0205." If the client or the
server receive password request or response not in the format
specified, it should fail the authentication.
A peer may prompt the user for the user credentials, or decide to use
the user credentials gained through some other means without
prompting the user. The peer sends the user credentials back in the
Password-Authentication TLV using the following format:
"RESPONSE=johndoe\0secret"
where "johndoe" is the actual user name and "secret" is the actual
password. The NULL character "\0" is used to separate the user name
and password.
The inclusion of both user name and password in a single message is
to achieve optimization by eliminating the optional Identity exchange
and save an extra round trip by peer sending both use name and
password in the first response packet.
Once the PP-EAP Server receives the user credentials, it will
Zhou, et al. Expires January 9, 2008 [Page 7]
Internet-Draft PP-EAP July 2007
continue to authenticate the user with internal or external user
databases.
Additional exchanges may occur between the PP-EAP server and peer to
facilitate various user authentications. The PP-EAP Server might
send additional challenges to user for additional information, such
as password change or new pin mode. The peer may prompt the user
again and send back the needed information in Password-Authentication
TLV.
The username and password, as well as server challenges MAY support
non-ASCII characters. In this case, the input should be processed
according to EAP [8], using an appropriate stringprep [9] profile,
and encoded in octets using UTF-8 encoding [10]. A preliminary
version of a possible stringprep profile is described in [13]. This
behavior is described in EAP [8].
4.4.1. Failure/ Error handling
As mentioned earlier, if the client or the server receive password
request or response not in the format specified, it should fail the
authentication. An PP-EAP server implementation uses the following
format if an authentication fails:
"E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc M=<msg> "
where
The "eeeeeeeeee" is the ASCII representation of a decimal error code
corresponding to one of those listed below, though implementations
should deal with codes not on this list gracefully. The error code
need not be 10 digits long. Here are some pre-defined error codes:
646 ERROR_RESTRICTED_LOGON_HOURS
647 ERROR_ACCT_DISABLED
648 ERROR_PASSWD_EXPIRED
649 ERROR_NO_DIALIN_PERMISSION
691 ERROR_AUTHENTICATION_FAILURE
709 ERROR_CHANGING_PASSWORD
The "r" is a single character ASCII flag set to '1' if a retry is
allowed, and '0' if not. When the authenticator sets this flag to
'1' it disables short timeouts, expecting the peer to prompt the user
for new credentials and resubmit the response.
The <msg> is human-readable text in the appropriate character set and
language [5].
Zhou, et al. Expires January 9, 2008 [Page 8]
Internet-Draft PP-EAP July 2007
The "cccccccccccccccccccccccccccccccc" is the ASCII representation of
a hexadecimal challenge value.
The error format described above is similar to what are defined in
MSCHAPv2, except for the server challenge. So if the PP-EAP Server
is distributing MSCHAPV2 exchanges to the backend user database
server, it can simply just return what the backend user database
server returns. In the case of connecting to an OTP or LDAP server,
the PP-EAP Server can format the error message into this format and
define some additional error codes. With the addition of the retry
count, EAP peer can potentially prompt the user for new credentials
to try again without restarts the password authentication from the
beginning. EAP peer will respond to the error code with another
Password-Authentication TLV Response with either the new Username and
Password or in case of other unrecoverable failures, an
acknowledgement. EAP peer uses empty Password-Authentication TLV
payload as an acknowledgment to the failure.
4.5. Protected Termination
A successful PP-EAP Phase 2 conversation MUST always end in a
successful Result TLV exchange. A PP-EAP server MAY initiate the
Result TLV exchange without initiating any password authentication in
PP-EAP Phase 2. After the final Result TLV exchange, the TLS tunnel
is terminated and a clear text EAP-Success or EAP-Failure is sent by
the server. The format of the Result TLV is described in
Section 4.11.4.
A server initiates a successful protected termination exchange by
sending a Result TLV indicating success. The server MAY send the
Result TLV along with a Crypto-Binding TLV. If the peer requires
nothing more from the server it will respond with a Result TLV
indicating success accompanied by a Crypto-Binding TLV if necessary.
The server then tears down the tunnel and sends a clear text EAP-
Success.
To provide support for a cryptographic binding between the TLS tunnel
establishment and the authentication running inside the TLS tunnel,
fresh and unique keying material of both exchanges need to be
combined. This means, the EAP peer and EAP server MUST compute
compound session keys (CSK) that take the keying material from the
initial TLS exchange and inner authentication into account.
Furthermore, the peer and the server MUST exchange the Crypto-Binding
TLVs including MAC signature that proves the knowledge of the keying
material (compound MAC key, CMK) that are created as a result the
successful completion of both TLS and the inner authentication
exchanges. Details are described as follows:
Zhou, et al. Expires January 9, 2008 [Page 9]
Internet-Draft PP-EAP July 2007
As a result of the successful TLS tunnel establishment, a tunnel key
(TK) is calculated using the first 40 octets of the (secret) key
material generated as described in the EAP-TLS algorithm (see [7],
Section 3.5). More explicitly, the TK is the first 40 octets of the
PRF as defined in [7]:
TK=PRF(master secret,"client EAP encryption", random)
Where random is the concatenation of client_hello.random and
server_hello.random
The compound session key (CSK) is then calculated based on the
knowledge of the tunnel key (TK), using the same PRF as that used in
EAP-TLS specification [7]. Note that this provides better crypto-
agility properties than the previous work in PEAPv2 or EAP-FAST where
PRF+ from IKEv2 was used.
We refer to MSK of the inner method as MSKi. When a legacy password
exchange (e.g., OTP) is used, no MSK is generated. However, when an
inner EAP method capable of MSK generation is used for password
authentication, we refer to the MSK generated by the inner EAP method
as MSKi.
ISK0=First(32, MSK0)
When no MSK is generated, the ISK0 is 32 zero octets.
First (M, K) and Last (N, K) denote the first M octets, and the last
N octets of a key K, respectively.
IMCK0=PRF(TK, "Inner method compound keys", ISK0)
S-IMCK0=First (40, IMCK0).
CMK=Last(20, IMCK0)
Where IMCK0 stands for Inner Method Compound key and S-IMCK is the
shortened IMCK.
The CMK is the compound MAC key used in generating the Crypto-Binding
Compound MAC value sent in Crypto-Binding TLV Section 4.11.7.
The Compound MAC computation is as follows:
Compound-MAC = TLS-Hash( CMK, Crypto-Binding TLV )
where TLS-Hash is the TLS hash function negotiated in the TLS
handshake.
Zhou, et al. Expires January 9, 2008 [Page 10]
Internet-Draft PP-EAP July 2007
The compound session key (CSK) is derived on both the peer and EAP
server.
CSK = PRF(S-IMCK0, "Session Key Generating Function")
The output length of the CSK must be at least 128 octets. The first
64 octets are taken as the MSK and the second 64 octets are taken as
the EMSK. The MSK and EMSK are described in [8].
MSK=First (64, CSK)
EMSK=last (64, CSK)
4.6. Session Resumption
PP-EAP session resumption is achieved in the same manner EAP-TLS
achieves session resume. To support session resumption, the server
and peer must minimally cache the SessionID, master secret, and
ciphersuite. The peer attempts to resume a session by including a
valid SessionID from a previous handshake in its ClientHello message.
If the server finds a match for the SessionID and is willing to
establish a new connection using the specified session state, the
server will respond with the same SessionID and proceed with the
phase 1 tunnel establishment based on a TLS abbreviated handshake.
After a successful conclusion of the Phase 1 conversation, the
conversation then continues directly to Phase 2 termination,
bypassing the password user authentication.
4.7. Determining Peer-Id and Server-Id
The Peer-Id and Server-Id may be determined based on the types of
credentials used during either the PP-EAP tunnel creation or
authentication within the tunnel.
The Server-Id is determined by the subject or subjectAltName fields
in the server certificate. As noted in [12]:
The subject field identifies the entity associated with the public
key stored in the subject public key field. The subject name MAY
be carried in the subject field and/or the subjectAltName
extension.... If subject naming information is present only in
the subjectAltName extension (e.g., a key bound only to an email
address or URI), then the subject name MUST be an empty sequence
and the subjectAltName extension MUST be critical.
Zhou, et al. Expires January 9, 2008 [Page 11]
Internet-Draft PP-EAP July 2007
Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN).
The Peer-Id is obtained from the inner password authentication
method.
4.8. PP-EAP Session Identifier
The EAP session identifier is constructed using the random values
provided by the peer and server during the TLS tunnel establishment.
The Session-Id is defined as follows:
Session-Id = PP_EAP_type || client_random || server_random
PP-EAP_type = PP-EAP EAP type number (TBD)
client_random = 32 octet nonce generated by the peer
server_random = 32 octet nonce generated by the server
4.9. Cryptographic Agility
Cryptographic agility is achieved using the PRF and hash functions
defined in TLS. With TLS 1.2 or above, crypto-agility is supported
so the hash, PRF and encryption algorithms used in TLS handshake and
PP-EAP session key generation can all be negotiated.
4.10. Extensibility
The protocol is designed with extensibility in mind. Although the
first version only supports password-based authentication, the
protocol can be extended in the following ways:
o Additional TLVs can be defined to support exchanges of other type
of authentications, such as CHAP, MSCHAP, even certificate-base or
bio-based authentication.
o Additional TLVs can also be defined to exchange arbitrary data
exchange between the peer and the server. This can be used to
support channel-binding etc.
o Additional Vendor-Specific TLVs can be defined to support non-
standard and experimental data exchange.
All these can be achieved without changing the basic operation of the
protocol including its session key generation and crypto-binding
exchange.
4.11. Packet Formats
Zhou, et al. Expires January 9, 2008 [Page 12]
Internet-Draft PP-EAP July 2007
4.11.1. PP-EAP Message Format
A summary of the PP-EAP Request/Response packet format is shown
below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Message Length :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Length | Data ... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
The code field is one octet in length defined as follows:
1 Request
2 Response
Identifier
The Identifier field is one octet and aids in matching
responses with requests. The Identifier field MUST be changed
on each Request packet. The Identifier field in the Response
packet MUST match the Identifier field from the corresponding
request.
Length
The Length field is two octets and indicates the length of the
EAP packet including the Code, Identifier, Length, Type, Flags,
Ver, Message Length, and Data fields. Octets outside the range
of the Length field should be treated as Data Link Layer
padding and should be ignored on reception.
Type
TBD
Flags
0 1 2 3 4
+-+-+-+-+-+
|L M S R R|
+-+-+-+-+-+
Zhou, et al. Expires January 9, 2008 [Page 13]
Internet-Draft PP-EAP July 2007
L Length included; set to indicate the presence of the four-
octet Message Length field
M More fragments; set on all but the last fragment
S PP-EAP start; set in an PP-EAP Start message
R Reserved (must be zero)
Ver
This field contains the version of the protocol. This document
describes version 1 (001 in binary) of PP-EAP.
Message Length
The Message Length field is four octets, and is present only if
the L bit is set. This field provides the total length of the
message that may be fragmented over the data fields of multiple
packets.
Data
When the Data field is present, it consists of an encapsulated
TLS packet in TLS record format. A PP-EAP packet with Flags
and Version fields, but with zero length data field, is used to
indicate PP-EAP acknowledgement for either a fragmented
message, a TLS Alert message or a TLS Finished message.
4.11.2. TLV Format
The TLVs defined here are standard Type-Length-Value (TLV) objects.
The TLV objects could be used to carry arbitrary parameters between
EAP peer and EAP server within the protected TLS tunnel.
TLVs are defined as described below. The fields are transmitted from
left to right.
Zhou, et al. Expires January 9, 2008 [Page 14]
Internet-Draft PP-EAP July 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Optional TLV
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
A 14-bit field, denoting the TLV type. Allocated Types include:
0 Reserved
1 Reserved
2 Password-Authentication TLV
3 Result TLV
4 NAK TLV
7 Vendor-Specific TLV
12 Crypto-Binding TLV
Length
The length of the Value field in octets.
Value
The value of the TLV.
The EAP peer may not necessarily implement all the TLVs supported by
the EAP server. To allow for interoperability, TLVs are designed to
allow an EAP server to discover if a TLV is supported by the EAP
peer, using the NAK TLV. The mandatory bit in a TLV indicates
whether support of the TLV is required. If the peer or server does
not support a TLV marked mandatory, then it MUST send a NAK TLV in
the response, and all the other TLVs in the message MUST be ignored.
If an EAP peer or server finds an unsupported TLV that is marked as
optional, it can ignore the unsupported TLV. It MUST NOT send an NAK
TLV for a TLV that is not marked mandatory.
Note that a peer or server may support a TLV with the mandatory bit
Zhou, et al. Expires January 9, 2008 [Page 15]
Internet-Draft PP-EAP July 2007
set, but may not understand the contents. The appropriate response
to a supported TLV with content that is not understood is defined by
the individual TLV specification.
EAP implementations compliant with this specification MUST support
TLV exchanges, as well as the processing of mandatory/optional
settings on the TLV. Implementations conforming to this
specification MUST support the following TLVs:
Password-Authentication TLV
Result TLV
NAK TLV
Vendor-Specific TLV
Crypto-Binding TLV
4.11.3. Password-Authentication TLV
The Password-Authentication TLV contains password exchanges described
in Section 4.4 and its payload is placed into the Value field of
Section 4.11.2.
This TLV has the TLV Type (2).
The password-Authentication TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhou, et al. Expires January 9, 2008 [Page 16]
Internet-Draft PP-EAP July 2007
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
2
Length
>=4
Value
The password authentication request and response.
4.11.4. Result TLV
The Result TLV provides support for acknowledged success and failure
messages for protected termination within PP-EAP. A Result TLV
indicating failure MUST NOT be accompanied by the following TLVs:
NAK, Password-Authentication TLV, or Crypto-Binding TLV. The Result
TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
Mandatory, set to one (1)
R
Reserved, set to zero (0)
TLV Type
3 for Result TLV
Zhou, et al. Expires January 9, 2008 [Page 17]
Internet-Draft PP-EAP July 2007
Length
2
Status
The Status field is two octets. Values include:
1 Success
2 Failure
4.11.5. NAK TLV
The NAK TLV allows a peer to detect TLVs that are mandatory and not
supported by the other peer. An PP-EAP packet can contain zero or
more NAK TLVs. A NAK TLV should not be accompanied by other TLVs. A
NAK TLV MUST NOT be sent in response to a message containing a Result
TLV, instead a Result TLV of failure should be sent indicating
failure. The NAK TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
Mandatory, set to one (1)
R
Reserved, set to zero (0)
TLV Type
4 for NAK TLV
Length
>=6
Vendor-Id
The Vendor-Id field is four octets, and contains the Vendor-Id
of the TLV that was not supported. The high-order octet is 0
and the low-order three octets are the Structure of Management
Information (SMI) Network Management Private Enterprise Code of
the Vendor in network byte order. The Vendor-Id field MUST be
zero for TLVs that are not Vendor-Specific TLVs.
Zhou, et al. Expires January 9, 2008 [Page 18]
Internet-Draft PP-EAP July 2007
NAK-Type
The NAK-Type field is two octets. The field contains the Type
of the TLV that was not supported. A TLV of this Type MUST
have been included in the previous packet.
TLVs
This field contains a list of zero or more TLVs, each of which
MUST NOT have the mandatory bit set. These optional TLVs are
for future extensibility to communicate why the offending TLV
was determined to be unsupported.
4.11.6. Vendor-Specific TLV
The Vendor-Specific TLV is available to allow vendors to support
their own extended attributes not suitable for general usage.
A Vendor-Specific-TLV attribute can contain one or more TLVs,
referred to as Vendor TLVs. The TLV-type of the Vendor-TLV will be
defined by the vendor. All the Vendor TLVs inside a single Vendor-
Specific TLV belong to the same vendor.
Vendor TLVs may be optional or mandatory. Vendor TLVs sent in the
protected success and failure packets MUST be marked as optional.
The Vendor-Specific TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhou, et al. Expires January 9, 2008 [Page 19]
Internet-Draft PP-EAP July 2007
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
7
Length
>=4
Vendor-Id
The Vendor-Id field is four octets. The high-order octet is 0 and
the low-order 3 octets are the SMI Network Management Private
Enterprise Code of the Vendor in network byte order. The Vendor-
Id MUST be zero for TLVs that are not Vendor-Specific TLVs. For
Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code.
Vendor TLVs
This field is of indefinite length. It contains vendor-specific
TLVs, in a format defined by the vendor.
4.11.7. Crypto-Binding TLV
The Crypto-Binding TLV is used to prove that both the peer and server
participated in the tunnel establishment and inner authentications.
It also provides verification of the PP-EAP version negotiated before
TLS tunnel establishment, see Section 4.2.
The Crypto-Binding TLV MUST be included with the Result TLV to
perform Cryptographic Binding after each successful inner
authentication method. The Crypto-Binding TLV can be issued at other
times as well.
The Crypto-Binding TLV is valid only if the following checks pass:
o The Crypto-Binding TLV version is supported
o The Compound MAC verifies correctly
o The received version in the Crypto-Binding TLV matches the version
sent by the receiver during the EAP version negotiation
Zhou, et al. Expires January 9, 2008 [Page 20]
Internet-Draft PP-EAP July 2007
o The Sub-Type is set to the correct value
If any of the above checks fails, then the TLV is invalid. An
invalid Crypto-Binding TLV is a fatal error and is handled as
described in Section 4.5.
The Crypto-Binding TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version | Received Ver. | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
Mandatory, set to (1)
R
Reserved, set to zero (0)
TLV Type
12 for Crypto-Binding TLV
Length
56
Reserved
Reserved, set to zero (0)
Version
The Version field is a single octet, which is set to the
version of Crypto-Binding TLV the EAP method is using. For an
implementation compliant with this version of PP-EAP, the
version number MUST be set to 1.
Zhou, et al. Expires January 9, 2008 [Page 21]
Internet-Draft PP-EAP July 2007
Received Version
The Received Version field is a single octet and MUST be set to
the EAP version number received during version negotiation.
Note that this field only provides protection against downgrade
attacks, where a version of EAP requiring support for this TLV
is required on both sides.
Sub-Type
The Sub-Type field is one octet. Defined values include:
0 Binding Request
1 Binding Response
Nonce
The Nonce field is 32 octets. It contains a 256-bit nonce that
is temporally unique, used for compound MAC key derivation at
each end. The nonce in a request MUST have its least
significant bit set to 0 and the nonce in a response MUST have
the same value as the request nonce except the least
significant bit MUST be set to 1.
Compound MAC
The Compound MAC field is 20 octets. The computation of the
MAC is described in Section 4.5.
5. Examples
This section shows an example protocol exchanges.
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=PP-EAP
EAP-Response/
EAP-Type=PP-EAP
(TLS client_hello)->
<- EAP-Request/
EAP-Type=PP-EAP
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
Zhou, et al. Expires January 9, 2008 [Page 22]
Internet-Draft PP-EAP July 2007
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=PP-EAP
(TLS client_key_exchange,
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=PP-EAP
(TLS change_cipher_spec,
TLS finished,
Password-Authentication TLV
(Challenge))
TLS channel established
TLVs sent within TLS channel
Password-Authentication TLV
{Response}->
... Additional Password-Authentication TLV exchanges
// Protected termination
<-
Result TLV
Crypto-Binding TLV
Result TLV
Crypto-Binding TLV->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
6. Security Considerations
6.1. Security Claims
EAP security claims are defined in EAP [8] Section 7.2.1. The
security claims for PP-EAP are as follows:
Zhou, et al. Expires January 9, 2008 [Page 23]
Internet-Draft PP-EAP July 2007
Auth. mechanism: Certificate based, password based.
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes, Any method executed within the PP-EAP
tunnel is integrity protected. The
cleartext EAP headers outside the tunnel are
not integrity protected.
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes
Key strength: See Note 1 below.
Dictionary attack prot.: Yes
Fast reconnect: Yes
Cryptographic binding: Yes
Session independence: Yes
Fragmentation: Yes
Key Hierarchy: Yes
Channel binding: No, but TLVs could be defined for this.
Notes
1. BCP 86 [11] offers advice on appropriate key sizes. The National
Institute for Standards and Technology (NIST) also offers advice
on appropriate key sizes in [14].
6.2. Server Certificate Validation
Please refer to Section 5.3 and 5.4 described in EAP-TLS [7].
7. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the PP-
EAP protocol, in accordance with BCP 26, [RFC2434]. a new EAP method
type will be assigned to the PP-EAP.
The document defines a registry for PP-EAP TLV types, which may be
assigned by Specification Required as defined in [RFC2434].
Section 4.11.2 defines the TLV types that initially populate the
registry. A summary of the PP- TLV types is given below:
0 Reserved
1 Reserved
Zhou, et al. Expires January 9, 2008 [Page 24]
Internet-Draft PP-EAP July 2007
2 Password-Authentication TLV
3 Result TLV
4 NAK TLV
7 Vendor-Specific TLV
12 Crypto-Binding TLV
8. Contributors
This work is a joint effort of a design team established by the EMU
Working Group in order to develop an password-based EAP method. The
contributors include:
o Mohamad Badra
o Ray Bell
o Charles Clancy
o Vijay Devarapalli
o Jouni Malinen
o Madjid Nakhjiri
o Joe Salowey
o Hannes Tschofenig
o Pascal Urien
o Hao Zhou
9. Acknowledgments
The protocol description in this document was inspired by PEAP, EAP-
FAST and TTLS. The authors would therefore like to thank PEAP, EAP-
FAST and TTLS authors for their work.
10. References
Zhou, et al. Expires January 9, 2008 [Page 25]
Internet-Draft PP-EAP July 2007
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
[2] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, October 1998.
[3] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759,
January 2000.
[4] Lloyd, B. and W. Simpson, "PPP Authentication Protocols",
RFC 1334, October 1992.
[5] Zorn, G., "PPP LCP Internationalization Configuration Option",
RFC 2484, January 1999.
[6] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[7] Simon, D., "The EAP TLS Authentication Protocol",
draft-simon-emu-rfc2716bis-11 (work in progress), July 2007.
10.2. Informative References
[8] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized
Strings ("stringprep")", RFC 3454, December 2002.
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[11] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004.
[12] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[13] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and
Passwords", RFC 4013, February 2005.
[14] National Institute of Standards and Technology, "Recommendation
for Key Management", Special Publication 800-57, May 2006.
Zhou, et al. Expires January 9, 2008 [Page 26]
Internet-Draft PP-EAP July 2007
Authors' Addresses
Hao Zhou (editor)
Cisco Systems, Inc.
4125 Highlander parkway
Richfield, Ohio 44286
USA
Phone:
Email: hzhou@cisco.com
URI: http://www.cisco.com
Madjid Nakhjiri (editor)
Huawei USA
Phone:
Email: mnakhjiri@huawei.com
Hannes Tschofenig (editor)
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Zhou, et al. Expires January 9, 2008 [Page 27]
Internet-Draft PP-EAP July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Zhou, et al. Expires January 9, 2008 [Page 28]
| PAFTECH AB 2003-2026 | 2026-04-24 02:45:05 |