draft-ietf-emu-eaptunnel-req-00.txt   draft-ietf-emu-eaptunnel-req-01.txt 
EMU Working Group K. Hoeper EMU Working Group K. Hoeper
Internet-Draft NIST Internet-Draft NIST
Intended status: Informational S. Hanna Intended status: Informational S. Hanna
Expires: December 27, 2008 Juniper Networks Expires: May 4, 2009 Juniper Networks
H. Zhou H. Zhou
J. Salowey, Ed. J. Salowey, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
June 25, 2008 October 31, 2008
Requirements for an Tunnel Based EAP Method Requirements for an Tunnel Based EAP Method
draft-ietf-emu-eaptunnel-req-00.txt draft-ietf-emu-eaptunnel-req-01.txt
Status of this Memo Status of this Memo
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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 December 27, 2008. This Internet-Draft will expire on May 4, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memo defines the requirements for a tunnel-based Extensible This memo defines the requirements for a tunnel-based Extensible
Authentication Protocol (EAP) Method. This method will use Transport Authentication Protocol (EAP) Method. This method will use Transport
Layer Security (TLS) to establish a secure tunnel. The tunnel will Layer Security (TLS) to establish a secure tunnel. The tunnel will
skipping to change at page 2, line 19 skipping to change at page 2, line 19
2. Conventions Used In This Document . . . . . . . . . . . . . . 4 2. Conventions Used In This Document . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Password Authentication . . . . . . . . . . . . . . . . . 5 3.1. Password Authentication . . . . . . . . . . . . . . . . . 5
3.2. Protect Weak EAP Methods . . . . . . . . . . . . . . . . . 5 3.2. Protect Weak EAP Methods . . . . . . . . . . . . . . . . . 5
3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 5 3.3. Chained EAP Methods . . . . . . . . . . . . . . . . . . . 5
3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6 3.4. Identity Protection . . . . . . . . . . . . . . . . . . . 6
3.5. Emergency Services Authentication . . . . . . . . . . . . 6 3.5. Emergency Services Authentication . . . . . . . . . . . . 6
3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 6 3.6. Network Endpoint Assessment . . . . . . . . . . . . . . . 6
3.7. Credential Provisioning and Enrollment . . . . . . . . . . 7 3.7. Resource Constrained Environments . . . . . . . . . . . . 6
3.8. Resource Constrained Environments . . . . . . . . . . . . 7 3.8. Client Authentication During Tunnel Establishment . . . . 7
3.9. Client Authentication During Tunnel Establishment . . . . 7 3.9. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7
3.10. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. General Requirements . . . . . . . . . . . . . . . . . . . 8 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7
4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 8 4.1.1. RFC Compliance . . . . . . . . . . . . . . . . . . . . 7
4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 8 4.1.2. Draw from Existing Work . . . . . . . . . . . . . . . 8
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 9 4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 8
4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 9 4.2.1. TLS Requirements . . . . . . . . . . . . . . . . . . . 9
4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 9 4.2.1.1. Cipher Suites . . . . . . . . . . . . . . . . . . 9
4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 9 4.2.1.1.1. Cipher Suite Negotiation . . . . . . . . . . . 9
4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 10 4.2.1.1.2. Tunnel Data Protection Algorithms . . . . . . 9
4.2.1.1.3. Tunnel Authentication and Key Establishment . 10 4.2.1.1.3. Tunnel Authentication and Key Establishment . 9
4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 12 4.2.1.2. Tunnel Replay Protection . . . . . . . . . . . . . 11
4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 12 4.2.1.3. TLS Extensions . . . . . . . . . . . . . . . . . . 11
4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12 4.2.1.4. Peer Identity Privacy . . . . . . . . . . . . . . 12
4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12 4.2.1.5. Session Resumption . . . . . . . . . . . . . . . . 12
4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
4.2.3. EAP Header Protection . . . . . . . . . . . . . . . . 12 4.2.3. Protection of Data External to Tunnel . . . . . . . . 12
4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12 4.3. Tunnel Payload Requirements . . . . . . . . . . . . . . . 12
4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 13 4.3.1. Extensible Attribute Types . . . . . . . . . . . . . . 12
4.3.2. Request/Challenge Response Operation . . . . . . . . . 13 4.3.2. Request/Challenge Response Operation . . . . . . . . . 13
4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13 4.3.3. Mandatory and Optional Attributes . . . . . . . . . . 13
4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13 4.3.4. Vendor Specific Support . . . . . . . . . . . . . . . 13
4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13 4.3.5. Result Indication . . . . . . . . . . . . . . . . . . 13
4.3.6. Internationalization of Display Strings . . . . . . . 14 4.3.6. Internationalization of Display Strings . . . . . . . 13
4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14 4.4. EAP Channel Binding Requirements . . . . . . . . . . . . . 14
4.5. Requirements Associated with Carrying Username and 4.5. Requirements Associated with Carrying Username and
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14 Passwords . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14 4.5.1. Security . . . . . . . . . . . . . . . . . . . . . . . 14
4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 15 4.5.1.1. Confidentiality and Integrity . . . . . . . . . . 14
4.5.1.2. Authentication of Server . . . . . . . . . . . . . 15 4.5.1.2. Authentication of Server . . . . . . . . . . . . . 14
4.5.1.3. Server Credential Revocation Checking . . . . . . 15 4.5.1.3. Server Credential Revocation Checking . . . . . . 14
4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15 4.5.2. Internationalization . . . . . . . . . . . . . . . . . 15
4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15 4.5.3. Meta-data . . . . . . . . . . . . . . . . . . . . . . 15
4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15 4.5.4. Password Change . . . . . . . . . . . . . . . . . . . 15
4.6. Requirements Associated with Carrying EAP Methods . . . . 16 4.6. Requirements Associated with Carrying EAP Methods . . . . 15
4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 16 4.6.1. Method Negotiation . . . . . . . . . . . . . . . . . . 15
4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 16 4.6.2. Chained Methods . . . . . . . . . . . . . . . . . . . 15
4.6.3. Cryptographic Binding with TLS Tunnel . . . . . . . . 16 4.6.3. Cryptographic Binding with TLS Tunnel . . . . . . . . 15
4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17 4.6.4. Peer Initiated . . . . . . . . . . . . . . . . . . . . 17
4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17 4.6.5. Method Meta-data . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Ciphersuite Selection . . . . . . . . . . . . . . . . . . 18 6.1. Cipher Suite Selection . . . . . . . . . . . . . . . . . . 17
6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 19 6.2. Tunneled Authentication . . . . . . . . . . . . . . . . . 18
6.3. Outer EAP Method Header . . . . . . . . . . . . . . . . . 19 6.3. Data External to Tunnel . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . . 20 7.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Introduction 1. Introduction
Running EAP methods within a TLS protected tunnel has been deployed Running EAP methods within a TLS protected tunnel has been deployed
in several different solutions. EAP methods supporting this include in several different solutions. EAP methods supporting this include
PEAP, TTLS [I-D.funk-eap-ttls-v0] and EAP-FAST [RFC4851]. There have PEAP, TTLS [RFC5281] and EAP-FAST [RFC4851]. There have been various
been various reasons for employing a protected tunnel for EAP reasons for employing a protected tunnel for EAP processes. They
processes. They include protecting weak authentication exchanges, include protecting weak authentication exchanges, such as username
such as username and password. In addition a protected tunnel can and password. In addition a protected tunnel can provide means to
provide a means to provide peer identity protection and EAP method provide peer identity protection and EAP method chaining. Finally,
chaining. Finally, systems have found it useful to transport systems have found it useful to transport additional types of data
additional types of data within the protected tunnel. within the protected tunnel.
This document describes the requirements for an EAP tunnel method as This document describes the requirements for an EAP tunnel method as
well as for a password protocol supporting legacy password databases well as for a password protocol supporting legacy password
within the tunnel method. verification within the tunnel method.
2. Conventions Used In This Document 2. Conventions Used In This Document
Because this specification is an informational specification (not Because this specification is an informational specification (not
able to directly use [RFC2119]), the following capitalized words are able to directly use [RFC2119]), the following capitalized words are
used to express requirements language used in this specification. used to express requirements language used in this specification.
Use of each capitalized word within a sentence or phrase carries the Use of each capitalized word within a sentence or phrase carries the
following meaning during the EMU WG's method selection process: following meaning during the EMU WG's method selection process:
MUST - indicates an absolute requirement MUST - indicates an absolute requirement
skipping to change at page 5, line 20 skipping to change at page 5, line 20
where the authentication server does not have access to the cleartext where the authentication server does not have access to the cleartext
password or a consistent transform of the cleartext password. password or a consistent transform of the cleartext password.
Example of such systems are one time password (OTP) systems and other Example of such systems are one time password (OTP) systems and other
systems where the username and password are submitted to an external systems where the username and password are submitted to an external
party for validation. The tunnel method MUST meet this use case. party for validation. The tunnel method MUST meet this use case.
However, it MUST NOT expose the username and password to untrusted However, it MUST NOT expose the username and password to untrusted
parties and it MUST provide protection against man-in-the-middle and parties and it MUST provide protection against man-in-the-middle and
dictionary attacks. dictionary attacks.
Since EAP authentication occurs before network access is granted the Since EAP authentication occurs before network access is granted the
tunnel method SHOULD provide support for minimal password management tunnel method SHOULD enable an inner exchange to provide support for
tasks including password change, "new PIN mode", and "next token minimal password management tasks including password change, "new PIN
mode" required by some systems. mode", and "next token mode" required by some systems.
3.2. Protect Weak EAP Methods 3.2. Protect Weak EAP Methods
Some existing EAP methods have vulnerabilities that could be Some existing EAP methods have vulnerabilities that could be
eliminated or reduced by running them inside a protected tunnel. For eliminated or reduced by running them inside a protected tunnel. For
example, a method such as EAP-MD5 does not provide mutual example, a method such as EAP-MD5 does not provide mutual
authentication or protection from dictionary attacks. In addition, authentication or protection from dictionary attacks. In addition,
tunneled EAP methods are subject to a specific form of man-in-the- tunneled EAP methods are subject to a specific form of man-in-the-
middle attack described in [TUNNEL-MITM]. middle attack described in [TUNNEL-MITM].
skipping to change at page 6, line 15 skipping to change at page 6, line 15
3.4. Identity Protection 3.4. Identity Protection
When performing an EAP authentication, the peer may want to protect When performing an EAP authentication, the peer may want to protect
its identity, only disclosing its identity to a trusted backend its identity, only disclosing its identity to a trusted backend
authentication server. This helps to maintain the privacy of the authentication server. This helps to maintain the privacy of the
peer's identity. peer's identity.
The tunnel method MUST support identity protection, ensuring that The tunnel method MUST support identity protection, ensuring that
peer identity is not disclosed to the authenticator and any other peer identity is not disclosed to the authenticator and any other
intermediaries before the server that terminates the tunnel method. intermediaries before the server that terminates the tunnel method.
If an inner method also provides identity protection, this protection Note that the peer may need to expose the realm portion of the EAP
MUST extend all the way to the server that terminates that inner outer identity in the NAI [RFC4282] in a roaming scenario in order to
method. Note that the peer may need to expose the realm portion of reach the appropriate authentication server.
the EAP outer identity in the NAI [RFC4282] in a roaming scenario in
order to reach the appropriate authentication server.
3.5. Emergency Services Authentication 3.5. Emergency Services Authentication
When wireless VOIP service is provided, some regulations require any When wireless VOIP service is provided, some regulations require any
user to be able to gain access to the network to make an emergency user to be able to gain access to the network to make an emergency
telephone call. To avoid eavesdropping on this call, it's best to telephone call. To avoid eavesdropping on this call, it's best to
negotiate link layer security as with any other authentication. negotiate link layer security as with any other authentication.
Therefore, the tunnel method SHOULD allow anonymous peers or server- Therefore, the tunnel method SHOULD allow anonymous peers or server-
only authentication, but still derive keys that can be used for link only authentication, but still derive keys that can be used for link
layer security. The tunnel method MAY also allow for the bypass of layer security. The tunnel method MAY also allow for the bypass of
server authentication processing on the client. Forgoing server authentication processing on the client. Forgoing
authentication increases the chance of man-in-the-middle and other authentication increases the chance of man-in-the-middle and other
types of attacks that can compromise the derived keys used for link types of attacks that can compromise the derived keys used for link
layer security. layer security.
3.6. Network Endpoint Assessment 3.6. Network Endpoint Assessment
The Network Endpoint Assessment (NEA) protocols and reference model The Network Endpoint Assessment (NEA) protocols and reference model
described in [I-D.ietf-nea-requirements] provide a standard way to described in [RFC5209] provide a standard way to check the health
check the health ("posture") of a device at or after the time it ("posture") of a device at or after the time it connects to a
connects to a network. If the device does not comply with the network. If the device does not comply with the network's
network's requirements, it can be denied access to the network or requirements, it can be denied access to the network or granted
granted limited access to remediate itself. EAP is a convenient limited access to remediate itself. EAP is a convenient place for
place for conducting an NEA exchange. conducting an NEA exchange.
The tunnel method SHOULD support carrying NEA protocols such as PB- The tunnel method SHOULD support carrying NEA protocols such as PB-
TNC [I-D.ietf-nea-pb-tnc]. Depending on the specifics of the tunnel TNC [I-D.ietf-nea-pb-tnc]. Depending on the specifics of the tunnel
method, these protocols may be required to be carried in an EAP method, these protocols may be required to be carried in an EAP
method. method.
3.7. Credential Provisioning and Enrollment 3.7. Resource Constrained Environments
When a peer has authenticated with EAP, this is a convenient time to
distribute credentials to that peer that may be used for later
authentication exchanges. For example, the authentication server can
provide a private key or shared key to the peer that can be used by
the peer to perform rapid re-authentication or roaming. In addition
there have been proposals to perform enrollment within EAP, such as
[I-D.mahy-eap-enrollment].
The tunnel method SHOULD support carrying credential distribution
protocols.
3.8. Resource Constrained Environments
A growing number of "resource constrained" devices (e.g. printers and A growing number of "resource constrained" devices (e.g. printers and
phones) are connecting to IP networks and those networks increasingly phones) are connecting to IP networks and those networks increasingly
require EAP authentication to gain access. Therefore, it is natural require EAP authentication to gain access. Therefore, it is natural
to expect that new EAP methods be designed to work as well as to expect that new EAP methods be designed to work as well as
possible with these devices. possible with these devices.
For the purposes of this document, the phrase "resource constrained" For the purposes of this document, the phrase "resource constrained"
means any combination of the following constraints: little processing means any combination of the following constraints: little processing
power, small amounts of memory (both ROM and RAM), small amounts of power, small amounts of memory (both ROM and RAM), small amounts of
long-term mutable storage (e.g. flash or hard drive) or none at all, long-term mutable storage (e.g. flash or hard drive) or none at all,
and constrained power usage (perhaps due to small battery). and constrained power usage (perhaps due to small battery).
The tunnel method SHOULD be designed so it can be configured to work The tunnel method SHOULD be designed so it can be configured to work
with "resource constrained" devices, when possible. with "resource constrained" devices, when possible.
3.9. Client Authentication During Tunnel Establishment 3.8. Client Authentication During Tunnel Establishment
In cases where client authentication can be performed as part of the In cases where client authentication can be performed as part of the
tunnel establishment it is efficient for the tunnel method to allow tunnel establishment it is efficient for the tunnel method to allow
this. The tunnel MUST be capable of providing client side this. The tunnel MUST be capable of providing client side
authentication during tunnel establishment. authentication during tunnel establishment.
3.10. Extensibility 3.9. Extensibility
The tunnel method MUST provide extensibility so that additional types The tunnel method MUST provide extensibility so that additional types
of data can be carried inside the tunnel in the future. This removes of data can be carried inside the tunnel in the future. This removes
the need to develop new tunneling methods for specific purposes. the need to develop new tunneling methods for specific purposes.
One example of a application for extensibility is credential
provisioning. When a peer has authenticated with EAP, this is a
convenient time to distribute credentials to that peer that may be
used for later authentication exchanges. For example, the
authentication server can provide a private key or shared key to the
peer that can be used by the peer to perform rapid re-authentication
or roaming. In addition there have been proposals to perform
enrollment within EAP, such as [I-D.mahy-eap-enrollment].
4. Requirements 4. Requirements
4.1. General Requirements 4.1. General Requirements
4.1.1. RFC Compliance 4.1.1. RFC Compliance
The tunnel method MUST include a Security Claims section with all The tunnel method MUST include a Security Claims section with all
security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In
addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC addition, it MUST meet the requirement in Sections 2.1 and 7.4 of RFC
3748 that tunnel methods MUST support protection against man-in-the- 3748 that tunnel methods MUST support protection against man-in-the-
middle attacks. Furthermore, all tunnel methods MUST support middle attacks. Furthermore, all tunnel methods MUST support
identity protection as specified in Section 7.3 in RFC 3748. identity protection as specified in Section 7.3 in RFC 3748.
The tunnel method MUST be unconditionally compliant with RFC 4017 The tunnel method MUST be unconditionally compliant with RFC 4017
[RFC4017] (using the definition of "unconditionally compliant" [RFC4017] (using the definition of "unconditionally compliant"
contained in section 1.1 of RFC 4017). This means that the method contained in section 1.1 of RFC 4017). This means that the method
MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT
requirements in RFC 4017. requirements in RFC 4017.
The tunnel method MUST meet all the EAP method requirements contained The tunnel method MUST meet all the EAP method requirements contained
in the EAP Key Management Framework draft [I-D.ietf-eap-keying] or in the EAP Key Management Framework [RFC5247] or its successor. The
its successor. The tunnel method MUST include MSK and EMSK tunnel method MUST include MSK and EMSK generation. This will enable
generation. This will enable the tunnel method to properly fit into the tunnel method to properly fit into the EAP key management
the EAP key management framework, maintaining all of the security framework, maintaining all of the security properties and guarantees
properties and guarantees of that framework. of that framework.
The tunnel method MUST NOT be tied to any single cryptographic The tunnel method MUST NOT be tied to any single cryptographic
algorithm. Instead, it MUST support run-time negotiation to select algorithm. Instead, it MUST support run-time negotiation to select
among an extensible set of cryptographic algorithms. This among an extensible set of cryptographic algorithms. This
"cryptographic algorithm agility" provides several advantages. Most "cryptographic algorithm agility" provides several advantages. Most
important, when a weakness in an algorithm is discovered or increased important, when a weakness in an algorithm is discovered or increased
processing power overtakes an algorithm, users can easily transition processing power overtakes an algorithm, users can easily transition
to a new algorithm. Also, users can choose the algorithm that best to a new algorithm. Also, users can choose the algorithm that best
meets their needs. meets their needs.
The tunnel method MUST meet requirements pertinent to EAP method The tunnel method MUST meet requirements pertinent to EAP method
contained in Section 3 of RFC 4962 [RFC4962]. This includes: contained in Section 3 of RFC 4962 [RFC4962]. This includes:
cryptographic algorithm independence; strong, fresh session keys; cryptographic algorithm independence; strong, fresh session keys;
replay detection; keying material confidentiality and integrity; replay detection; keying material confidentiality and integrity;
confirm cipher suite selection; and uniquely named keys. In confirm cipher suite selection; and uniquely named keys.
addition, the tunnel method MUST support EAP channel bindings to
enable a system based on EAP to meet the additional requirements in
Section 3 of RFC 4962.
4.1.2. Draw from Existing Work 4.1.2. Draw from Existing Work
Several existing tunnel methods are already in widespread usage: EAP- Several existing tunnel methods are already in widespread usage: EAP-
FAST [RFC4851], EAP-TTLS [I-D.funk-eap-ttls-v0], and PEAP. FAST [RFC4851], EAP-TTLS [RFC5281], and PEAP. Considerable
Considerable experience has been gained from various deployments with experience has been gained from various deployments with these
these methods. This experience SHOULD be considered when evaluating methods. This experience SHOULD be considered when evaluating tunnel
tunnel methods. If one of these existing tunnel methods can meet the methods. If one of these existing tunnel methods can meet the
requirements contained in this specification then that method SHOULD requirements contained in this specification then that method SHOULD
be preferred over a new method. be preferred over a new method.
Even if minor modifications or extensions to an existing tunnel Even if minor modifications or extensions to an existing tunnel
method are needed, this method SHOULD be preferred over a completely method are needed, this method SHOULD be preferred over a completely
new method so that the advantage of accumulated deployment experience new method so that the advantage of accumulated deployment experience
and security analysis can be gained. and security analysis can be gained.
4.2. Tunnel Requirements 4.2. Tunnel Requirements
Existing tunnel methods make use of TLS [I-D.ietf-tls-rfc4346-bis] to Existing tunnel methods make use of TLS [RFC5246] to provide the
provide the protected tunnel. In general this has worked well so protected tunnel. In general this has worked well so there is
there is consensus to continue to use TLS as the basis for a tunnel consensus to continue to use TLS as the basis for a tunnel method.
method.
4.2.1. TLS Requirements 4.2.1. TLS Requirements
The tunnel based method MUST support TLS version 1.2 The tunnel based method MUST support TLS version 1.2 [RFC5246] and
[I-D.ietf-tls-rfc4346-bis] and SHOULD support TLS version 1.0 SHOULD support TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] to
[RFC2246] and version 1.1 [RFC4346] to enable the possibility of enable the possibility of backwards compatibility with existing
backwards compatibility with existing deployments. The following deployments. The following section discusses requirements for TLS
section discusses requirements for TLS Tunnel Establishment. Tunnel Establishment.
4.2.1.1. Cipher Suites 4.2.1.1. Cipher Suites
4.2.1.1.1. Cipher Suite Negotiation 4.2.1.1.1. Cipher Suite Negotiation
Cipher suite negotiations always suffer from downgrading attacks when Cipher suite negotiations always suffer from downgrading attacks when
they are not secured by any kind of integrity protection. A common they are not secured by any kind of integrity protection. A common
practice is a post integrity check in which, as soon as available, practice is a post integrity check in which, as soon as available,
the established keys (here the tunnel key) are used to derive the established keys (here the tunnel key) are used to derive
integrity keys. These integrity keys are then used by peer and integrity keys. These integrity keys are then used by peer and
skipping to change at page 12, line 24 skipping to change at page 12, line 8
4.2.1.3. TLS Extensions 4.2.1.3. TLS Extensions
In order to meet the requirements in this document TLS extensions MAY In order to meet the requirements in this document TLS extensions MAY
be used. For example, TLS extensions may be useful in providing be used. For example, TLS extensions may be useful in providing
certificate revocation information via the TLS OCSP extension (thus certificate revocation information via the TLS OCSP extension (thus
meeting the requirement in Section 4.5.1.3). meeting the requirement in Section 4.5.1.3).
4.2.1.4. Peer Identity Privacy 4.2.1.4. Peer Identity Privacy
A tunnel protocol MUST support peer privacy. This requires that the A tunnel protocol MUST support peer privacy. This requires that the
username is not transmitted in the clear and, if applicable, the peer username and other attributes associated with the peer are not
certificate is sent confidentially (i.e. encrypted). transmitted in the clear or to an unauthenticated, unauthorized
party. If applicable, the peer certificate is sent confidentially
(i.e. encrypted).
4.2.1.5. Session Resumption 4.2.1.5. Session Resumption
The tunnel method MUST support TLS session resumption as defined in The tunnel method MUST support TLS session resumption as defined in
[I-D.ietf-tls-rfc4346-bis]. The tunnel method MAY support other [RFC5246]. The tunnel method MAY support other methods of session
methods of session resumption such as those defined in [RFC5077]. resumption such as those defined in [RFC5077].
4.2.2. Fragmentation 4.2.2. Fragmentation
Tunnel establishment sometimes requires the exchange of information Tunnel establishment sometimes requires the exchange of information
that exceeds what can be carried in a single EAP message. In that exceeds what can be carried in a single EAP message. In
addition information carried within the tunnel may also exceed this addition information carried within the tunnel may also exceed this
limit. Therefore a tunnel method MUST support fragmentation and limit. Therefore a tunnel method MUST support fragmentation and
reassembly. reassembly.
4.2.3. EAP Header Protection 4.2.3. Protection of Data External to Tunnel
A tunnel method SHOULD provide protection of the outer EAP header A tunnel method MUST provide protection of any data external to the
information when possible to make sure the outer EAP header is not TLS tunnel that can cause a problem if it is modified by an attacker.
modified by the intermediaries. This may include data such as type codes and version numbers
4.3. Tunnel Payload Requirements 4.3. Tunnel Payload Requirements
This section describes the payload requirements inside the tunnel. This section describes the payload requirements inside the tunnel.
These requirements frequently express features that a candidate These requirements frequently express features that a candidate
protocol must be capable of offering so that a deployer can decide protocol must be capable of offering so that a deployer can decide
whether to make use of that feature. This section does not state whether to make use of that feature. This section does not state
requirements about what features of each protocol must be used during requirements about what features of each protocol must be used during
a deployment. a deployment.
skipping to change at page 14, line 17 skipping to change at page 14, line 7
The payload MAY provide a standard attribute format that supports The payload MAY provide a standard attribute format that supports
international strings. This attribute format MUST support encoding international strings. This attribute format MUST support encoding
strings in UTF-8 [RFC3629] format. Any strings sent by the server strings in UTF-8 [RFC3629] format. Any strings sent by the server
intended for display to the user MUST be sent in UTF-8 format and intended for display to the user MUST be sent in UTF-8 format and
SHOULD be able to be marked with language information and adapted to SHOULD be able to be marked with language information and adapted to
the user's language preference. the user's language preference.
4.4. EAP Channel Binding Requirements 4.4. EAP Channel Binding Requirements
The so-called "lying NAS" problem is a well-documented problem with The tunnel method MUST be capable of meeting EAP channel binding
the current Extensible Authentication Protocol (EAP) architecture requirements described in [I-D.clancy-emu-chbind].
[RFC3748] when used with pass-through authenticators. Here, a
Network Access Server (NAS), or pass-through authenticator, may
authenticate to the backend AAA infrastructure using one set of
credentials, while representing contrary information to EAP peers.
Such attacks can be prevented by so-called channel bindings
[I-D.clancy-emu-chbind], in which key channel binding characteristics
are transported from the peer to the server, allowing the server to
verify whether the authenticator has advertised valid information to
the peer. The server can also respond back with additional
information that could be useful for the peer to decide whether or
not to continue its session with the serving authenticator.
The tunnel method MUST be capable of supporting EAP channel bindings
described above.
4.5. Requirements Associated with Carrying Username and Passwords 4.5. Requirements Associated with Carrying Username and Passwords
This section describes the requirements associated with tunneled This section describes the requirements associated with tunneled
password authentication. The password authentication mentioned here password authentication. The password authentication mentioned here
refers to user or machine authentication using a legacy password refers to user or machine authentication using a legacy password
database, such as LDAP, OTP, etc. These legacy user databases database or verifier, such as LDAP, OTP, etc. These typically
typically require the password in its original text form in order to require the password in its original text form in order to
authenticate the peer, hence they require the peer to send the clear authenticate the peer, hence they require the peer to send the clear
text user name and password to the EAP server. text user name and password to the EAP server.
4.5.1. Security 4.5.1. Security
Due to the fact that the EAP peer needs to send clear text password Due to the fact that the EAP peer needs to send clear text password
to the EAP server to authenticate to the legacy user database, the to the EAP server to authenticate against the legacy user
security measures in the following sections MUST be met. information, the security measures in the following sections MUST be
met.
4.5.1.1. Confidentiality and Integrity 4.5.1.1. Confidentiality and Integrity
The clear text password exchange MUST be integrity and The clear text password exchange MUST be integrity and
confidentiality protected. As long as the password exchange occurs confidentiality protected. As long as the password exchange occurs
inside an authenticated and encrypted tunnel, this requirement is inside an authenticated and encrypted tunnel, this requirement is
met. met.
4.5.1.2. Authentication of Server 4.5.1.2. Authentication of Server
The EAP server MUST be authenticated before the peer can send the The EAP server MUST be authenticated before the peer can send the
clear text user name and password to the server. clear text password to the server.
4.5.1.3. Server Credential Revocation Checking 4.5.1.3. Server Credential Revocation Checking
In some cases, the EAP peer needs to present its password to the In some cases, the EAP peer needs to present its password to the
server before it has network access to check the revocation status of server before it has network access to check the revocation status of
the server's credentials. Therefore, the tunnel method MUST support the server's credentials. Therefore, the tunnel method MUST support
mechanisms to check the revocation status of a credential. The mechanisms to check the revocation status of a credential. The
tunnel method SHOULD make use of Online Certificate Status Protocol tunnel method SHOULD make use of Online Certificate Status Protocol
(OCSP) [RFC2560] or Server-based Certificate Validation Protocol (OCSP) [RFC2560] or Server-based Certificate Validation Protocol
(SCVP) [RFC5055] to obtain the revocation status of the EAP server (SCVP) [RFC5055] to obtain the revocation status of the EAP server
skipping to change at page 15, line 52 skipping to change at page 15, line 29
authentication is for a user or a machine. This allows the EAP authentication is for a user or a machine. This allows the EAP
server and peer to request and negotiate authentication specifically server and peer to request and negotiate authentication specifically
for a user or machine. This is useful in the case of multiple inner for a user or machine. This is useful in the case of multiple inner
authentications where the user and machine both need to be authentications where the user and machine both need to be
authenticated. authenticated.
4.5.4. Password Change 4.5.4. Password Change
The password authentication exchange MUST support password change, as The password authentication exchange MUST support password change, as
well as other multiple round trips exchanges like new pin mode and well as other multiple round trips exchanges like new pin mode and
next token mode for OTP database. next token mode for OTP verifiers.
4.6. Requirements Associated with Carrying EAP Methods 4.6. Requirements Associated with Carrying EAP Methods
The tunnel method MUST be able to carry inner EAP methods without
modifying them.
4.6.1. Method Negotiation 4.6.1. Method Negotiation
The tunnel method MUST support the protected negotiation of the inner The tunnel method MUST support the protected negotiation of the inner
EAP method. It MUST NOT allow the inner EAP method negotiation to be EAP method. It MUST NOT allow the inner EAP method negotiation to be
downgraded or manipulated by intermediaries. downgraded or manipulated by intermediaries.
4.6.2. Chained Methods 4.6.2. Chained Methods
The tunnel method MUST support the chaining of multiple EAP methods. The tunnel method MUST support the chaining of multiple EAP methods.
The tunnel method MUST allow for the communication of intermediate The tunnel method MUST allow for the communication of intermediate
skipping to change at page 16, line 34 skipping to change at page 16, line 14
cryptographic binding. Without such bindings attacks are feasible on cryptographic binding. Without such bindings attacks are feasible on
tunnel methods [TUNNEL-MITM] and chained methods. tunnel methods [TUNNEL-MITM] and chained methods.
Cryptographic bindings are typically achieved by securely mixing the Cryptographic bindings are typically achieved by securely mixing the
established keying material (say tunnel key TK) from the tunnel established keying material (say tunnel key TK) from the tunnel
protocol with the established keying material (say method key MK) protocol with the established keying material (say method key MK)
from the inner authentication method(s) in order to derive fresh from the inner authentication method(s) in order to derive fresh
keying material. If chained EAP methods are executed in the tunnel, keying material. If chained EAP methods are executed in the tunnel,
all derived inner keys are combined to one method key MK. The keying all derived inner keys are combined to one method key MK. The keying
material derived from mixing tunnel and method keys is also referred material derived from mixing tunnel and method keys is also referred
to as compound key CTK. In particular, CTK is used to derive MSK, to as compound tunnel key (CTK). In particular, CTK is used to
EMSK and other transient keys TEK, such as transient encryption keys derive the EAP MSK, EMSK and other transient keys (TEK), such as
and integrity protection keys. The key hierarchy for tunnel methods transient encryption keys and integrity protection keys. The key
executions that derive compound keys for the purpose of cryptographic hierarchy for tunnel methods executions that derive compound keys for
binding is depicted in Figure 1. the purpose of cryptographic binding is depicted in Figure 1.
----------- -----------
| TK | MK | | TK | MK |
----------- -----------
| | | |
v v v v
-------- --------
| CTK | | CTK |
-------- --------
| |
skipping to change at page 17, line 40 skipping to change at page 17, line 7
o use compound key CTK to derive transient keys for use in a o use compound key CTK to derive transient keys for use in a
cryptographic protocol that verifies the integrity of the tunnel cryptographic protocol that verifies the integrity of the tunnel
and the inner authentication method. and the inner authentication method.
Furthermore, the compound key CTK and all keys derived from it SHOULD Furthermore, the compound key CTK and all keys derived from it SHOULD
be derived in accordance to the guidelines for key derivations and be derived in accordance to the guidelines for key derivations and
key hierarchies as specified in Section 4.2.1.1.3. In particular, key hierarchies as specified in Section 4.2.1.1.3. In particular,
all derived keys MUST have a lifetime assigned that does not exceed all derived keys MUST have a lifetime assigned that does not exceed
the lifetime of any key higher in the key hierarchy, and MUST prevent the lifetime of any key higher in the key hierarchy, and MUST prevent
domino effects. domino effects where a compromise in one part of the system leads to
compromises in other parts of the system.
4.6.4. Peer Initiated 4.6.4. Peer Initiated
The tunnel method SHOULD allow for the peer to initiate an inner EAP The tunnel method SHOULD allow for the peer to initiate an inner EAP
authentication in order to meet its policy requirements for authentication in order to meet its policy requirements for
authenticating the server. authenticating the server.
4.6.5. Method Meta-data 4.6.5. Method Meta-data
The tunnel method MUST allow for the communication of additional data The tunnel method MUST allow for the communication of additional data
skipping to change at page 18, line 23 skipping to change at page 17, line 40
6. Security Considerations 6. Security Considerations
A tunnel method is often deployed to provide mutual authentication A tunnel method is often deployed to provide mutual authentication
between EAP Peer and EAP Server and to generate strong key material between EAP Peer and EAP Server and to generate strong key material
for use in protecting lower layer protocols. In addition the tunnel for use in protecting lower layer protocols. In addition the tunnel
is used to protect the communication of additional data, including is used to protect the communication of additional data, including
peer identity between the EAP Peer and EAP Server from disclosure to peer identity between the EAP Peer and EAP Server from disclosure to
or modification by an attacker. These sections cover considerations or modification by an attacker. These sections cover considerations
that affect the ability for a method to achieve these goals. that affect the ability for a method to achieve these goals.
6.1. Ciphersuite Selection 6.1. Cipher Suite Selection
TLS supports a wide variety of cipher suites providing a variety of TLS supports a wide variety of cipher suites providing a variety of
security properties. The selection of strong cipher suites is security properties. The selection of strong cipher suites is
critical to the security of the tunnel method. Selection of a cipher critical to the security of the tunnel method. Selection of a cipher
suite with weak or no authentication, such as an anonymous Diffie- suite with weak or no authentication, such as an anonymous Diffie-
Hellman based cipher suite will greatly increase the risk of system Hellman based cipher suite will greatly increase the risk of system
compromise. Since a tunnel method uses the TLS tunnel to transport compromise. Since a tunnel method uses the TLS tunnel to transport
data, the selection of a ciphersuite with weak data encryption and data, the selection of a ciphersuite with weak data encryption and
integrity algorithms will also increase the vulnerability of the integrity algorithms will also increase the vulnerability of the
method to attacks. method to attacks.
skipping to change at page 19, line 10 skipping to change at page 18, line 27
Mutually anonymous tunnel protocols are prone to man-in-the-middle Mutually anonymous tunnel protocols are prone to man-in-the-middle
attacks described in [KHLC07]. During such an attack, an adversary attacks described in [KHLC07]. During such an attack, an adversary
establishes a tunnel with each the peer and the authentication establishes a tunnel with each the peer and the authentication
server, while peer and server believe that they established a tunnel server, while peer and server believe that they established a tunnel
with each other. Once both tunnels have been established, the with each other. Once both tunnels have been established, the
adversary can eavesdrop on all communications within the tunnels, adversary can eavesdrop on all communications within the tunnels,
i.e. the execution of the inner authentication method(s). i.e. the execution of the inner authentication method(s).
Consequently, the adversary can eavesdrop on the identifiers that are Consequently, the adversary can eavesdrop on the identifiers that are
exchanged as part of the EAP method and thus, the privacy of peer exchanged as part of the EAP method and thus, the privacy of peer
and/or authentication server is compromised along with any other data and/or authentication server is compromised along with any other data
transmitted within the tunnels. transmitted within the tunnels. This document requires server
authentication to avoid the risks associated with anonymous cipher
suites.
6.2. Tunneled Authentication 6.2. Tunneled Authentication
In many cases a tunnel method provides mutual authentication by In many cases a tunnel method provides mutual authentication by
authenticating the server during tunnel establishment and authenticating the server during tunnel establishment and
authenticating the peer within the tunnel using an EAP method. As authenticating the peer within the tunnel using an EAP method. As
described in [TUNNEL-MITM], this mode of operation can allow a man- described in [TUNNEL-MITM], this mode of operation can allow a man-
in-the-middle to authenticate to the server as the peer by tunneling in-the-middle to authenticate to the server as the peer by tunneling
the inner EAP protocol messages to and from a peer executing the the inner EAP protocol messages to and from a peer executing the
method outside a tunnel or with an untrustworthy server. method outside a tunnel or with an untrustworthy server.
Cryptographic binding between the established keying material from Cryptographic binding between the established keying material from
the inner authentication method(s) and the tunnel protocol verifies the inner authentication method(s) and the tunnel protocol verifies
that the endpoints of the tunnel and the inner authentication that the endpoints of the tunnel and the inner authentication
method(s) are the same. this can thwart the attack if the inner method(s) are the same. This can thwart the attack if the inner
method derived keys of sufficient strength that they cannot be broken method derived keys of sufficient strength that they cannot be broken
in real-time. in real-time.
In cases where the inner authentication method does not generate any In cases where the inner authentication method does not generate any
or only weak key material care must be taken to ensure that the peer or only weak key material care must be taken to ensure that the peer
does not execute the inner method with the same credentials outside a does not execute the inner method with the same credentials outside a
protective tunnel or with an untrustworthy server. protective tunnel or with an untrustworthy server.
6.3. Outer EAP Method Header 6.3. Data External to Tunnel
There are several existing EAP methods which use a similar packet The tunnel method will use data that is outside the TLS tunnel such
format to EAP-TLS. Often for the initial portions of the exchange as the EAP type code or version numbers. If an attacker can
the execution of the method is identical except for the method ID. compromise the protocol by modifying these values the tunnel method
Protection of the outer EAP header helps to avoid vulnerabilities MUST protect this data.
that may arise when an attacker attempts to modify packets to make
one EAP message look like one from a different method.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.clancy-emu-chbind] [I-D.clancy-emu-chbind]
Clancy, C. and K. Hoeper, "Channel Binding Support for EAP Clancy, C. and K. Hoeper, "Channel Binding Support for EAP
Methods", draft-clancy-emu-chbind-00 (work in progress), Methods", draft-clancy-emu-chbind-03 (work in progress),
February 2008. October 2008.
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
[I-D.ietf-tls-rfc4346-bis]
Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
(work in progress), March 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999. Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
skipping to change at page 20, line 42 skipping to change at page 19, line 47
Wireless LANs", RFC 4017, March 2005. Wireless LANs", RFC 4017, March 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007. BCP 132, RFC 4962, July 2007.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
Polk, "Server-Based Certificate Validation Protocol Polk, "Server-Based Certificate Validation Protocol
(SCVP)", RFC 5055, December 2007. (SCVP)", RFC 5055, December 2007.
7.2. Informative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[I-D.funk-eap-ttls-v0] [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol (EAP) Key Management Framework",
Authentication Protocol Version 0 (EAP-TTLSv0)", RFC 5247, August 2008.
draft-funk-eap-ttls-v0-05 (work in progress), April 2008.
7.2. Informative References
[I-D.ietf-nea-pb-tnc] [I-D.ietf-nea-pb-tnc]
Sahita, R., Hanna, S., and R. Hurst, "PB-TNC: A Posture Sahita, R., Hanna, S., and K. Narayan, "PB-TNC: A Posture
Broker Protocol (PB) Compatible with TNC", Broker Protocol (PB) Compatible with TNC",
draft-ietf-nea-pb-tnc-00 (work in progress), April 2008. draft-ietf-nea-pb-tnc-01 (work in progress), July 2008.
[I-D.ietf-nea-requirements]
Sangster, P., "Network Endpoint Assessment (NEA): Overview
and Requirements", draft-ietf-nea-requirements-07 (work in
progress), April 2008.
[I-D.mahy-eap-enrollment] [I-D.mahy-eap-enrollment]
Mahy, R., "An Extensible Authentication Protocol (EAP) Mahy, R., "An Extensible Authentication Protocol (EAP)
Enrollment Method", draft-mahy-eap-enrollment-01 (work in Enrollment Method", draft-mahy-eap-enrollment-01 (work in
progress), March 2006. progress), March 2006.
[KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail", [KHLC07] Hoeper, K. and L. Chen, "Where EAP Security Claims Fail",
ICST QShine , August 2007. ICST QShine , August 2007.
[NIST SP 800-108] [NIST SP 800-108]
skipping to change at page 21, line 52 skipping to change at page 21, line 7
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851, Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007. May 2007.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, June 2008.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[TUNNEL-MITM] [TUNNEL-MITM]
Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunnelled Authentication Protocols", Cryptology ePrint in Tunnelled Authentication Protocols", Cryptology ePrint
Archive: Report 2002/163, November 2002. Archive: Report 2002/163, November 2002.
Authors' Addresses Authors' Addresses
Katrin Hoeper Katrin Hoeper
NIST NIST
100 Bureau Drive, MS: 8930 100 Bureau Drive, MS: 8930
 End of changes. 53 change blocks. 
164 lines changed or deleted 139 lines changed or added

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