One document matched: draft-ohba-hokey-emu-eap-ext-00.txt
Network Working Group Y. Ohba
Internet-Draft Toshiba
Intended status: Informational S. Das
Expires: July 8, 2007 Telcordia
January 4, 2007
An EAP Method for EAP Extension (EAP-EXT)
draft-ohba-hokey-emu-eap-ext-00
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 July 8, 2007.
Copyright Notice
Copyright (C) The Internet Society (2007).
Ohba & Das Expires July 8, 2007 [Page 1]
Internet-Draft EAP-EXT Method January 2007
Abstract
This document describes an EAP method that is used for extending EAP
functionality. The extended functionality includes re-authentication
and channel binding. The proposed EAP method (EAP-EXT) also allows
sequencing of multiple EAP methods within itself. EAP-EXT can
generate MSK (Master Session Key) and EMSK (Extended Master Session
Key) in cases where inner method(s) implementations generate MSK but
do not generate EMSK.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 3
2. EAP-EXT Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. MSK and EMSK exported from EAP-EXT . . . . . . . . . . . . 8
4.2. EAP-EXT-KEY . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. EAP-REAUTH-KEY . . . . . . . . . . . . . . . . . . . . . . 8
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 9
6. EAP-EXT TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Method TLV . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. AUTH TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Peer-ID TLV . . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Server-ID TLV . . . . . . . . . . . . . . . . . . . . . . 12
6.5. Reauth-Key-Lifetime TLV . . . . . . . . . . . . . . . . . 12
6.6. PRF TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.7. Channel-Binding-Mechanism TLV . . . . . . . . . . . . . . 13
6.8. Channel-Binding-Data TLV . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Ohba & Das Expires July 8, 2007 [Page 2]
Internet-Draft EAP-EXT Method January 2007
1. Introduction
EAP (Extensible Authentication Protocol) is an authentication
protocol which supports multiple authentication algorithms known as
"EAP methods" [RFC3748]. In EAP, an EAP peer and an EAP server
generates EAP keying material, i.e., MSK (Master Session Key) and
EMSK (Extended Master Session Key) upon successful authentication. A
detailed framework for the generation, transport and usage of MSK is
described in [I-D.ietf-eap-keying].
Additional functionalities such as re-authentication
[I-D.vidya-eap-reauth-ps] and channel binding [I-D.ietf-eap-keying]
can be supported by extending EAP functionality. There can be two
approaches for extending EAP functionality. One approach is to
define new EAP Codes to realize the extended EAP functionality in
addition to the existing ones, i.e., Request, Response, Success and
Failure. This approach, however, requires changes to [RFC3748] and
may also require changes to authenticators and lower layer protocols.
The other approach is to define a new EAP method to realize the
extended functionality. For both approaches, it may be desirable
that these extended functionalities are backward compatible. In such
cases, a mechanism for negotiating the capabilities on the extended
functionalities between an EAP peer and an EAP server may be needed.
This document describes an EAP method that is used for extending EAP
functionality. The extended functionality includes re-authentication
and channel binding. The proposed EAP method (EAP-EXT) also allows
sequencing of multiple EAP methods within itself. EAP-EXT can
generate MSK and EMSK in cases where inner method(s) implementations
generate MSK but do not generate EMSK.
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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 [RFC2119].
Ohba & Das Expires July 8, 2007 [Page 3]
Internet-Draft EAP-EXT Method January 2007
2. EAP-EXT Overview
EAP-EXT provides capabilities exchange. One bit (R-bit) is used for
indicating Re-authentication capability. One bit (C-bit) is used for
indicating channel binding capability.
When EAP-EXT is used, the precedent EAP-Identity exchange MAY be
omitted if the identity of the peer is known to the server before the
server sends the first EAP-Request. Note that there are several
outband mechanisms for providing the identity of the peer to the
server, e.g., transferring the identity of the peer between
authenticators and servers.
In EAP-EXT, extended EAP capabilities such as re-authentication and
channel binding are exchanged between the peer and the server. At
the same time, at least one EAP method (e.g., EAP-TLS) is run inside
EAP-EXT for authenticating the peer. Inner method(s) are carried in
Method TLVs (Type-Length-Values). Until an inner method generates
EAP keying material, no AUTH TLV is included and the capabilities are
non-protected. Hence, if there is only one inner EAP method,
additional EAP-EXT exchange(s) with an AUTH TLV need(s) to be
performed after completion of the inner method and before sending an
EAP-Success or an EAP-Failure message.
After an inner EAP method generates EAP keying material, EAP-EXT
messages MUST be protected with an AUTH TLV. AUTH TLVs in EAP-EXT
messages MUST be computed using EAP-EXT-KEY generated from EAP keying
material of the latest successful inner method. This means that if
there are multiple inner EAP methods that are sequentially run inside
EAP-EXT, a new EAP-EXT-KEY is generated each time an inner EAP method
in the sequence generates EAP keying material. Any inner EAP method
MUST be capable of generating EAP keying material.
At the end of a successful EAP-EXT run, EAP keying material is
derived from the MSK generated by the last successful inner EAP
method and is exported to the EAP layer. The pseudo random function
used for deriving the EAP keying material and USRKs (Usage Specific
Root Keys) [I-D.salowey-eap-emsk-deriv] MAY be negotiated within EAP-
EXT using PRF TLVs. F-bit is used for indicating the end of EXP-EXT
exchange.
Figure 1 shows an example of EAP-EXT message sequence with a single
inner EAP method and with PRF negotiation. Figure 2 shows an example
of EAP-EXT message sequence with multiple inner EAP methods and
without PRF negotiation.
Ohba & Das Expires July 8, 2007 [Page 4]
Internet-Draft EAP-EXT Method January 2007
Peer Server
| EAP-Request/Identity (optional) |
|<---------------------------------------------------|
| EAP-Response/Identity (optional) |
|--------------------------------------------------->|
| EAP-Request/EXT{Cap.(R,C),PRF(1,2),Method(Type X),|
| CBM(1,2),CBD} |
|<---------------------------------------------------|
| EAP-Response/EXT{Cap.(R,C),PRF(1),Method(Type X), |
| CBM(1)} |
|--------------------------------------------------->|
| ... |
| EAP-Request/EXT{F,Cap.(R,C),PRF(1,2),Peer-ID, |
| Server-ID,Reauth-Key-Lifetime, |
| CBM(1,2),CBD,AUTH} |
|<---------------------------------------------------|
| EAP-Response/EXT{F,Cap.(C,R),PRF(2),CBM(1),AUTH} |
|--------------------------------------------------->|
| EAP-Success |
|<---------------------------------------------------|
F: F-bit is set
Cap.(R,C): R-bit and C-bit of Capabilities field are set
PRF(1,2): PRF TLV carrying PRF numbers 1 and 2
PRF(1): PRF TLV carrying PRF numbers 1
Method(Type X): Method TLV carrying method Type X
Peer-ID: Peer-ID TLV
Server-ID: Server-ID TLV
Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV
AUTH: AUTH TLV
CBM(1,2): Channel-Binding-Mechanism TLV with
channel binding mechanism numbers 1 and 2
CBM(1): Channel-Binding-Mechanism TLV with
channel binding mechanism number 1
CBD: Channel-Binding-Data TLV
Figure 1: EAP-EXT message sequence with a single inner method and PRF
negotiation
Ohba & Das Expires July 8, 2007 [Page 5]
Internet-Draft EAP-EXT Method January 2007
Peer Server
| EAP-Request/Identity (optional) |
|<----------------------------------------------------|
| EAP-Response/Identity (optional) |
|---------------------------------------------------->|
| EAP-Request/EXT{Cap.(R,C),Method(Type=X),CBM(1,2), |
| CBD| |
|<----------------------------------------------------|
| EAP-Response/EXT{Cap.(R,C),Method(Type=X),CBM(2), |
| CBD} |
|---------------------------------------------------->|
| .... |
| EAP-Request/EXT{Cap.(R,C),Method(Type=Y), |
| CBM(1,2),CBD,AUTH} |
|<----------------------------------------------------|
| EAP-Response/EXT{Cap.(R,C),Method(Type=Y), |
| CBM(2),CBD,AUTH} |
|---------------------------------------------------->|
| .... |
| EAP-Request/EXT{F,Cap.(R,C),Method(Type=Y), |
| Peer-ID, Server-ID, |
| Reauth-Key-Lifetime, CBM(1,2), |
| CBD,AUTH} |
|<----------------------------------------------------|
| EAP-Response/EXT{F,Cap.(R,C),Method(Type=Y), |
| CBM(2),CBD,AUTH} |
|---------------------------------------------------->|
| EAP-Success |
|<----------------------------------------------------|
F: F-bit is set
Cap.(R,C): R-bit and C-bit of Capabilities field are set
Method(Type-X): Method TLV carrying method Type X
Method(Type-Y): Method TLV carrying method Type Y
Peer-ID: Peer-ID TLV
Server-ID: Server-ID TLV
Reauth-Key-Lifetime: Reauth-Key-Lifetime TLV
AUTH: AUTH TLV
CBM(1,2): Channel-Binding-Mechanism TLV with
channel binding mechanism numbers 1 and 2
CBM(2): Channel-Binding-Mechanism TLV with
channel binding mechanism number 2
CBD: Channel-Binding-Data TLV
Figure 2: EAP-EXT message sequence with multiple inner methods and
without PRF negotiation
Ohba & Das Expires July 8, 2007 [Page 6]
Internet-Draft EAP-EXT Method January 2007
3. Error Handling
An error may happen for several reasons, e.g., due to failure of
inner EAP method authentication or a malformed, unknown or missing
EAP-EXT TLV. An error may be detected either by the peer or by the
server. An EAP-EXT message that caused an error is referred to as an
erroneous message. EAP-EXT messages with E-bit set are used for
error indications. These messages are referred to as error
indications. An error indication MUST contain an AUTH TLV, and
SHOULD NOT contain other TLVs.
Any erroneous message (including an erroneous error indication)
without a valid AUTH TLV MUST be silently discarded.
For an erroneous Request with a valid AUTH TLV, the peer sends an
error indication Response. For an erroneous Response with a valid
AUTH TLV, the server sends an error indication Request which is
responded by the peer with an error indication Response. The server
returns an EAP-Failure message in response to an error indication
Response with a valid AUTH TLV.
Ohba & Das Expires July 8, 2007 [Page 7]
Internet-Draft EAP-EXT Method January 2007
4. Keys
EAP-EXT defines the following types of keys.
4.1. MSK and EMSK exported from EAP-EXT
A set of 64-octet MSK and 64-octet EMSK to be exported from EAP-EXT
is derived from MSK_i, the MSK generated by the last successful inner
EAP method, using the KDF defined in [I-D.salowey-eap-emsk-deriv] in
the following way.
(MSK, EMSK) = KDF(MSK_i, "EAP-EXT-EAP-Keying-Material", 128)
4.2. EAP-EXT-KEY
EAP-EXT-KEY is used for computing AUTH TLVs for integrity protecting
EAP-EXT messages. EAP-REAUTH-KEY is used within EAP-EXT only and is
never exported. The EAP-EXT-KEY is the first N octets of MSK
generated by an inner EAP method, where N denotes the length of EAP-
EXT-KEY. When HMAC-SHA-256 [sha256] is used for the integrity
algorithm, N=32.
4.3. EAP-REAUTH-KEY
EAP-REAUTH-KEY is used as the pre-shared key required by an EAP
method used for a re-authentication mechanism. The length of EAP-
REAUTH-KEY. The length of EAP-REAUTH-KEY depends on the re-
authentication mechanism. The EAP-REAUTH-KEY is derived from the
EMSK exported from EAP-EXT using the USRK derivation algorithm
defined in [I-D.salowey-eap-emsk-deriv] as follows.
EAP-REAUTH-KEY = KDF(EMSK, "EAP-EXT-Reauthentication-Key", length)
Ohba & Das Expires July 8, 2007 [Page 8]
Internet-Draft EAP-EXT Method January 2007
5. Message Format
EAP-EXT uses EAP Type XX (To be assigned by IANA). The message
format including the common EAP fields (i.e., Code, Identifier,
Length and Type) defined in [RFC3748] 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 | Version |F|E| Reserved | Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV(s) (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
F
This bit MUST be set to indicate that this is the last EAP-EXT
message from the sender. Otherwise, this bit MUST NOT be set.
E
This bit is set when the message is an error indication. When
this bit is set, F-bit MUST also be set. See Section 3 for
detailed description on error indications.
Version
This 8-bit field indicates the version of the EAP-EXT method.
This document defines Version 1.
Reserved
This 6-bit field is reserved for future extensions. This field
MUST be set to zero by the sender and the recipient MUST ignore
this field.
Capabilities
This field The Capabilities field contains extended EAP
capabilities. The Capabilities field the following format.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R C r r r r r r|
+-+-+-+-+-+-+-+-+
Ohba & Das Expires July 8, 2007 [Page 9]
Internet-Draft EAP-EXT Method January 2007
Each bit corresponds to a particular capability. The semantics of
each bit is as follows.
R
This bit is set to indicate that the sender supports a re-
authentication EAP method. When this bit is set in the final
Request/EXT message (i.e., the Request/EXT with F-bit is set),
the message MUST include a Server-ID TLV and a Peer-ID TLV and
MAY include a Reauth-Key-Lifetime AVP. If this bit is set in
the final Request/EXT and Response/EXT exchange, the peer and
the server MUST generate an EAP-REAUTH-KEY. The Server-ID and
Peer-ID contained in the Server-ID and Peer-ID TLVs and the
EAP-REAUTH-KEY is used for a re-authentication EAP method. The
default re-authentication mechanism is TBD.
C
This bit is set to indicate that the sender supports a channel
binding mechanism for MSK. When this bit is set in a Request/
EXT message, one Channel-Binding-Mechanism TLV MUST also be
included to indicate the channel binding mechanism(s) supported
by the server. If the peer supports and wants to enable one of
the the channel binding mechanism(s) supported by the server,
it sends a Response/EXT message with this bit set and one
Channel-Binding-Mechanism TLV containing the selected channel
binding mechanism. If this bit is set in the final Request/EXT
and Response/EXT exchange with successful negotiation of one
channel binding mechanism and the EAP-EXT method completes with
success, the peer and the server MUST enable the negotiated
channel binding mechanism.
Other bits are reserved for future use, and MUST be set to zero by
the sender and MUST be ignored by the recipient.
TLV
Zero, one or more TLVs (Type-Length-Value's). The TLV format of
is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Ohba & Das Expires July 8, 2007 [Page 10]
Internet-Draft EAP-EXT Method January 2007
Type
This field indicates the type of this TLV.
Length
This field indicates the length of this TLV in octets,
including the Type and Length fields of the TLV.
Value
This field contains data specific to the TLV Type.
Ohba & Das Expires July 8, 2007 [Page 11]
Internet-Draft EAP-EXT Method January 2007
6. EAP-EXT TLVs
The following TLVs are defined.
6.1. Method TLV
The Method TLV (Type 1) contains an EAP Method payload starting from
Type field.
6.2. AUTH TLV
The AUTH TLV (Type 2) contains integrity data used for protecting
EAP-EXT messages. The EAP-EXT-KEY is used for computing AUTH TLVs.
The TLV-Value field is computed over the entire EAP message including
this field. Before computing the integrity data, this field MUST be
initialized to all zeros. The length of this field depends on the
integrity algorithm in use. When the integrity check fails, the
message MUST be silently discarded. The default integrity algorithm
is HMAC-SHA-256 [sha256].
6.3. Peer-ID TLV
The Peer-ID TLV (Type 3) contains the identity of the peer used for
re-authentication.
6.4. Server-ID TLV
The Server-ID TLV (Type 4) contains the identity of the server used
for re-authentication.
6.5. Reauth-Key-Lifetime TLV
The Reauth-Key-Lifetime TLV (Type 5) contains the lifetime of EAP-
REAUTH-KEY in seconds.
6.6. PRF TLV
The PRF TLV (Type 6) contains one or more one-octet PRF numbers
defined in [I-D.salowey-eap-emsk-deriv]. When this TLV is carried in
a Request, it indicates the PRF number(s) supported by the server.
When this TLV is carried in a Request/EXT message, the corresponding
Response/EXT message MAY contain this TLV. A PRF TLV in a Response/
EXT message MUST contain exactly one PRF number that is supported and
selected by the peer among the PRF numbers in the Request/EXT
message. If the PRF number is successfully negotiated using the PRF
TLV exchange described above, the negotiated PRF number is used for
KDF to derive EAP keying material to be exported by EAP-EXT and
USRKs. Otherwise, the default PRF specified in
Ohba & Das Expires July 8, 2007 [Page 12]
Internet-Draft EAP-EXT Method January 2007
[I-D.salowey-eap-emsk-deriv] is used for KDF.
6.7. Channel-Binding-Mechanism TLV
The Channel-Binding-Mechanism TLV (Type 7) contains one or more one-
octet channel binding mechanism numbers. When this TLV is carried in
a Request/EXT message, it indicates the channel binding mechanism
number(s) supported by the server. When this TLV is carried in a
Request/EXT message, the corresponding Response/EXT message MAY
contain this TLV. A Channel-Binding-Mechanism TLV in a Response/EXT
message MUST contain exactly one channel binding mechanism number
that is supported and selected by the peer among the channel binding
mechanism numbers in the Request/EXT message. If the channel binding
mechanism is successfully negotiated using the Channel-Binding-
Mechanism TLV exchange described above, the negotiated channel
binding mechanism is enabled.
The following channel binding mechanism numbers are defined in this
document.
1 [I-D.ohba-eap-channel-binding]
2 [arkko-eap-service-identity-auth]
For channel binding mechanism 1, the default hash algorithm for prf+
is AUTH_HMAC_SHA1_160.
For channel binding mechanism 2, an additional Channel-Binding-Data
TLV is carried in Requests and Responses.
6.8. Channel-Binding-Data TLV
The Channel-Binding-Data TLV (Type 8) contains an octetstring data
used for [arkko-eap-service-identity-auth].
Ohba & Das Expires July 8, 2007 [Page 13]
Internet-Draft EAP-EXT Method January 2007
7. Security Considerations
Capability exchange before an inner EAP method exports EAP keying
material is unprotected. Hence, additional protected message
exchange after creation of EAP keying material is mandated to avoid
the capabilities information to be altered by an attacker without
being detected by the peer and the server.
EAP-EXT allows sequencing of multiple EAP methods inside it. It is
known that a compound authentication method that consists of multiple
nested or sequential authentication methods without cryptographically
binding them has a vulnerability to man-in-the-middle attack. EAP-
EXT is able to create the required cryptographically binding by
protecting each inner EAP method together with the outer EAP method
(i.e., EAP-EXT) with a key generated by its precedent successful
inner method in the sequence and finally exporting EAP keying
material derived from that is generated by the last successful inner
EAP method. In order to achieve cryptographic binding, EAP-EXT
requires inner EAP methods to be capable of generating EAP keying
material.
This method exports MSK and EMSK that are computed from MSK of an
inner method. Therefore, the strength of exported MSK and EMSK
altogether is the same as that of the MSK of the inner method.
Ohba & Das Expires July 8, 2007 [Page 14]
Internet-Draft EAP-EXT Method January 2007
8. IANA Considerations
TBD.
Ohba & Das Expires July 8, 2007 [Page 15]
Internet-Draft EAP-EXT Method January 2007
9. Acknowledgments
The authors would like to thank Bernard Aboba and Jari Arkko for
their valuable inputs.
Ohba & Das Expires July 8, 2007 [Page 16]
Internet-Draft EAP-EXT Method January 2007
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-16 (work in
progress), January 2007.
[I-D.vidya-eap-reauth-ps]
Narayanan, V. and L. Dondeti, "Problem Statement on EAP
Efficient Re-authentication and Key Management",
draft-vidya-eap-reauth-ps-00 (work in progress),
October 2006.
[I-D.ohba-eap-channel-binding]
Ohba, Y., "Channel Binding Mechanism based on Parameter
Binding in Key Derivation",
draft-ohba-eap-channel-binding-02 (work in progress),
December 2006.
[I-D.salowey-eap-emsk-deriv]
Salowey, J., "Specification for the Derivation of Usage
Specific Root Keys (USRK) from an Extended Master Session
Key (EMSK)", draft-salowey-eap-emsk-deriv-01 (work in
progress), June 2006.
[sha256] National Institute of Standards and Technology, "Secure
Hash Standard", August 2002.
10.2. Informative References
[arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", http://tools.ietf.org/html/
draft-arkko-eap-service-identity-auth-04, October 2005.
Ohba & Das Expires July 8, 2007 [Page 17]
Internet-Draft EAP-EXT Method January 2007
Authors' Addresses
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway, NJ 08854
USA
Phone: +1 732 699 5365
Email: yohba@tari.toshiba.com
Subir Das
Telcordia
1 Telcordia Drive
Piscateway, NJ 08854
USA
Phone: +1 732 699 2483
Email: subir@research.telcordia.com
Ohba & Das Expires July 8, 2007 [Page 18]
Internet-Draft EAP-EXT Method January 2007
Full Copyright Statement
Copyright (C) The Internet Society (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 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).
Ohba & Das Expires July 8, 2007 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 04:59:46 |