One document matched: 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 2, 2008 Huawei
H. Tschofenig, Ed.
Siemens Networks GmbH & Co KG
July 1, 2007
PP-EAP - A Protected Password-Based EAP Method
draft-zhou-emu-pp-eap-00.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 2, 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 communication between a peer and a server by using the
Transport Layer Security (TLS) to establish a server-authentictaed
tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used
Zhou, et al. Expires January 2, 2008 [Page 1]
Internet-Draft PP-EAP July 2007
to convey password-based authentication between the peer and the EAP
server.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Specification . . . . . . . . . . . . . . . . . . . . 4
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Password Authentication Exchange . . . . . . . . . . . . . 4
4.3. Crypto-Binding . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . 7
4.4.1. PP-EAP Message Format . . . . . . . . . . . . . . . . 7
4.4.2. TLV Format . . . . . . . . . . . . . . . . . . . . . . 9
4.4.3. Password-Authentication TLV . . . . . . . . . . . . . 9
4.4.4. Result TLV . . . . . . . . . . . . . . . . . . . . . . 10
4.4.5. Crypto-Binding TLV . . . . . . . . . . . . . . . . . . 10
4.4.6. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 13
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 16
7.2. Server Certificate Validation . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Zhou, et al. Expires January 2, 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 TLS to establish a
protected TLS tunnel and then exchange password-based authentication
within the TLS tunnel. However, there is no standard mechanism and
format defined for the inner data exchange, as well as the mechanism
to support crypto-binding, extension of the data exchanged, and
crypto-agility. The protocol defined in this document intends to
address these limitations to ensure better interopabilities.
The protected password-based EAP method described in this document
consists of two steps:
In step (1), the EAP-TLS protocol exchange is performed 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 interaction.
In step (2), Type-Length-Value (TLV) payloads for password-based
authenication as well as protected result indication and crypo-
binding are exchanged. This step will occur only if establishment
of a protected TLS tunnel in step (1) was successful. Any data
that is exchanged in this step is not vulnerable to active and
passive man-in-the-middle attacks.
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 [8].
3. Requirements
This section lists mandatory requirements that guided the work on
this EAP method:
1. Support secure transport of clear text password to support
legacy username and password databases, such as One-time
Password (OTP) and LDAP.
2. Provide server authentication.
3. Provide resistance to offline dictionary attacks, man-in-the-
middle attacks, and replay attacks.
Zhou, et al. Expires January 2, 2008 [Page 3]
Internet-Draft PP-EAP July 2007
4. Support exchange of channel binding data.
5. Compliant with RFC 3748, RFC 4017, EAP keying draft (includes
MSK and EMSK generation).
6. Support user identity confidentiality for the peer.
7. Support Crypto-agility and cipher suite negotiation (need to
define mandatory supported ciphers).
8. Support Session Resumption (avoid the need for use to re-enter
the password every time).
9. Support protected result indication.
10. Support Fragmentation and reassembly.
The following requirements are nice to have:
o Support password/PIN changes.
o Support Crypto-Binding to make sure the inner authenticaytion
method and outer TLS tunnel exhcnage are terminated at 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 fo carrying oither data exchanges within the tunnel.
o Support standard extension of the inner data exchange.
o Support online server certificate validation such as OCSP.
4. Protocol Specification
4.1. Overview
The exchanges for step (1) are described in EAP-TLS [7]. For
interoperability reasons the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA
is mandatory to implement. Step (1) provides the functionality for
fragmentation, session resumption, ciphersuite negotation and key
derivation of the MSK and the EMSK.
In step (2) Password-Authentication TLVs are exchanged. After an
authentication protocol exchange the two peers MUST exchange Result
TLVs and Crypto-Binding TLVs. If the Crypto-Binding TLV is invalid
or missing, the other peer MUST assume an error.
4.2. Password Authentication Exchange
All password authentication exchanges 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 password." and client response will be in the form of
"RESPONSE=\205." If the client or the server receive password
request or response not in the format specified, it should fail the
authentication.
Zhou, et al. Expires January 2, 2008 [Page 4]
Internet-Draft PP-EAP July 2007
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.
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].
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 inner method
server, it can simply just return what the backend inner method
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, client can potentially prompt the user for new credentials to
try again without restarts the password authentication from the
beginning. Client 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. Client use empty Password-Authentication TLV
payload as an acknowledgment to the failure.
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
Zhou, et al. Expires January 2, 2008 [Page 5]
Internet-Draft PP-EAP July 2007
displayable message for the user prompt.
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 is used to separate the user name and
password.
The inclusion of both username and secret in a single message is to
achieve optimization by eliminating the inner method EAP-Identity 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
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 [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 [11]. This behavior
is described in [8].
4.3. Crypto-Binding
To provide support for a cryptographic binding between the TLS tunnel
establishment and the authentication running on top of the TLS record
layer fresh and unique keying material of both exchanges need to be
combined. Both the EAP peer and EAP server MUST compute the compound
session keys using the procedure described below.
The 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]:
Zhou, et al. Expires January 2, 2008 [Page 6]
Internet-Draft PP-EAP July 2007
PRF(master secret,"client EAP encryption", random)
Where random is the concatenation of client_hello.random and
server_hello.random
The first 32 octets of the MSK provided by each successful inner EAP
method
The PRF algorithm is based on PRF+ from IKEv2 shown below ("|"
denotes concatenation)
K = Key, S = Seed, LEN = output length, represented as binary
in a single octet.
PRF (K,S,LEN) = T1 | T2 | T3 | T4 | ... where:
T1 = HMAC-SHA1(K, S | LEN | 0x01)
T2 = HMAC-SHA1 (K, T1 | S | LEN | 0x02)
T3 = HMAC-SHA1 (K, T2 | S | LEN | 0x03)
T4 = HMAC-SHA1 (K, T3 | S | LEN | 0x04)
...
The compound session key (CSK) is derived on both the peer and EAP
server.
CSK = PRF+(TK, "Session Key Generating Function", OutputLength)
The output length of the CSK must be at least 128 bytes. The first
64 octets are taken and the MSK and the second 64 octets are taken as
the EMSK. The MSK and EMSK are described in [8].
4.4. Packet Formats
4.4.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... +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhou, et al. Expires January 2, 2008 [Page 7]
Internet-Draft PP-EAP July 2007
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|
+-+-+-+-+-+
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.
Zhou, et al. Expires January 2, 2008 [Page 8]
Internet-Draft PP-EAP July 2007
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.4.2. TLV Format
TLVs are defined as described below. The fields are transmitted from
left to right.
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.
Length
The length of the Value field in octets.
Value
The value of the TLV.
4.4.3. Password-Authentication TLV
The Password-Authentication TLV cantains password exchanges described
in Section 4.2 and its payload is placed into the Value field of
Section 4.4.2.
Zhou, et al. Expires January 2, 2008 [Page 9]
Internet-Draft PP-EAP July 2007
This TLV has the TLV Type (2).
4.4.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, PAP 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
Length
2
Status
The Status field is two octets. Values include:
1 Success
2 Failure
4.4.5. Crypto-Binding TLV
The Crypto-Binding TLV is used prove that both peers participated in
the sequence of authentications (specifically the TLS session and
inner EAP methods that generate keys).
Both the Binding Request (B1) and Binding Response (B2) use the same
packet format. However the Sub-Type indicates whether it is B1 or
B2.
The Crypto-Binding TLV MUST be used to perform Cryptographic Binding
after each successful authentication protocol exchange.
Zhou, et al. Expires January 2, 2008 [Page 10]
Internet-Draft PP-EAP July 2007
This message format is used for the Binding Request (B1) and also the
Binding Response. This uses TLV type CRYPTO_BINDING_TLV. 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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zhou, et al. Expires January 2, 2008 [Page 11]
Internet-Draft PP-EAP July 2007
M
1 - Mandatory TLV
R
Reserved, set to zero (0)
TLV Type
12
Length
56
Reserved
Reserved, set to zero (0)
Version
Set to (0)
Received Version
Set to (0)
Sub-Type
The Sub-Type field is two octets. Possible 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. This is the S_NONCE for the B1 message and a C_NONCE for the
B2 message.
Compound MAC
The Compound MAC field is 20 octets. This can be the Server MAC
(B1_MAC) or the Client MAC (B2_MAC). It is computed using the
HMAC-SHA1-160 keyed MAC that provides 160 bits of output using the
CMK key. The MAC is computed over the buffer created after
concatenating these fields in the following order:
Zhou, et al. Expires January 2, 2008 [Page 12]
Internet-Draft PP-EAP July 2007
The entire Crypto-Binding TLV attribute with the MAC field zeroed
out.
4.4.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 2, 2008 [Page 13]
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.
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/
Zhou, et al. Expires January 2, 2008 [Page 14]
Internet-Draft PP-EAP July 2007
EAP-Type=PP-EAP
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[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,
PAP TLV
TLS channel established
TLVs sent within TLS channel
PAP TLV
{PAP-Request}->
// Protected termination
<-
Result TLV
Crypto-Binding TLV
(Nonce, B1_MAC)
Result TLV
Crypto-Binding TLV
(Nonce, B2_MAC)->
TLS channel torn down
(messages sent in cleartext)
<- EAP-Success
6. 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:
Zhou, et al. Expires January 2, 2008 [Page 15]
Internet-Draft PP-EAP July 2007
o Mohamad Badra
o Pascal Urien
o Charles Clancy
o Madjid Nakhjiri
o Joe Salowey
o Jouni Malinen
o Hannes Tschofenig
o Hao Zhou
o Ray Bell
o Vijay Devarapalli
7. Security Considerations
7.1. Security Claims
EAP security claims are defined in [RFC3748] Section 7.2.1. The
security claims for PP-EAP are as follows:
Auth. mechanism: Certificate-based server authentication and
password-based peer authentication
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes
Replay protection: Yes
Confidentiality: Yes
Key derivation: Yes
Key strength: See Note 1 below.
Dictionary attack prot.: Yes
Fast reconnect: Yes
Crypt. binding: Yes
Session independence: Yes
Fragmentation: Yes
Channel binding: No
Zhou, et al. Expires January 2, 2008 [Page 16]
Internet-Draft PP-EAP July 2007
[1] BCP 86 [RFC3766] Section 5 offers advice on the required RSA or
DH module and DSA subgroup size in bits, for a given level of attack
resistance in bits. For example, a 2048-bit RSA key is recommended
to provide 128-bit equivalent key strength. The National Institute
for Standards and Technology (NIST) also offers advice on appropriate
key sizes in [SP800-57].
7.2. Server Certificate Validation
Please refere to Section 5.3 and 5.4 described in EAP-TLS [7].
8. 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.2 defines the TLV types that initially populate the registry. A
summary of the PP- TLV types is given below:
0 Reserved
1 Reserved
2 Password-Authentication TLV
3 Result TLV
7 Vendor-Specific TLV
12 Crypto-Binding TLV
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
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.
Zhou, et al. Expires January 2, 2008 [Page 17]
Internet-Draft PP-EAP July 2007
[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. and B. Aboba, "The EAP TLS Authentication Protocol",
draft-simon-emu-rfc2716bis-10 (work in progress), June 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] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and
Passwords", RFC 4013, February 2005.
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
Zhou, et al. Expires January 2, 2008 [Page 18]
Internet-Draft PP-EAP July 2007
Madjid Nakhjiri (editor)
Huawei
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 2, 2008 [Page 19]
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 2, 2008 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 02:47:26 |