draft-ietf-emu-eap-gpsk-04.txt   draft-ietf-emu-eap-gpsk-05.txt 
EMU Working Group T. Clancy EMU Working Group T. Clancy
Internet-Draft LTS Internet-Draft LTS
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: September 12, 2007 Siemens Networks GmbH & Co KG Expires: October 7, 2007 Nokia Siemens Networks
March 11, 2007 April 5, 2007
EAP Generalized Pre-Shared Key (EAP-GPSK) EAP Generalized Pre-Shared Key (EAP-GPSK)
draft-ietf-emu-eap-gpsk-04.txt draft-ietf-emu-eap-gpsk-05
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 35 skipping to change at page 1, line 35
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 September 12, 2007. This Internet-Draft will expire on October 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This Internet Draft defines an Extensible Authentication Protocol This Internet Draft defines an Extensible Authentication Protocol
method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method
is a lightweight shared-key authentication protocol supporting mutual is a lightweight shared-key authentication protocol supporting mutual
skipping to change at page 2, line 30 skipping to change at page 2, line 30
6.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 12 6.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 12
6.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 13 6.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 13
6.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 13 6.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13
6.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14 6.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14
7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15 7.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15
7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16 7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 15
7.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 20 7.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 20
7.4.1. Protected Results Indication . . . . . . . . . . . . . 23 7.4.1. Protected Results Indication . . . . . . . . . . . . . 23
8. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 23 8. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 23
9. Example Message Exchanges . . . . . . . . . . . . . . . . . . 24 9. Example Message Exchanges . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 27 10.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 27
10.2. Protected Result Indications . . . . . . . . . . . . . . 28 10.2. Protected Result Indications . . . . . . . . . . . . . . 28
skipping to change at page 8, line 33 skipping to change at page 8, line 33
In GPSK-1, the EAP server sends its identity ID_Server, a random In GPSK-1, the EAP server sends its identity ID_Server, a random
number RAND_Server and a list of supported ciphersuites CSuite_List. number RAND_Server and a list of supported ciphersuites CSuite_List.
The decision which ciphersuite to offer and which ciphersuite to pick The decision which ciphersuite to offer and which ciphersuite to pick
is policy- and implementation-dependent and therefore outside the is policy- and implementation-dependent and therefore outside the
scope of this document. scope of this document.
In GPSK-2, the peer sends its identity ID_Peer and a random number In GPSK-2, the peer sends its identity ID_Peer and a random number
RAND_Peer. Furthermore, it repeats the received parameters of the RAND_Peer. Furthermore, it repeats the received parameters of the
GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected
ciphersuite. It computes a Message Authentication Code over all the ciphersuite. It computes a Message Authentication Code over all the
trasmitted parameters. transmitted parameters.
The EAP server verifies the received Message Authentication Code. In The EAP server verifies the received Message Authentication Code. In
case of successful verification, the EAP server computes a Message case of successful verification, the EAP server computes a Message
Authentication Code over the session parameter and returns it to the Authentication Code over the session parameter and returns it to the
peer (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP server peer (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP server
have the possibility to exchange encrypted protected data parameters. have the possibility to exchange encrypted protected data parameters.
The peer verifies the received Message Authentication Code. If the The peer verifies the received Message Authentication Code. If the
verification is successful, GPSK-4 is prepared. This message can verification is successful, GPSK-4 is prepared. This message can
optionally contain the peer's protected data parameters. optionally contain the peer's protected data parameters.
skipping to change at page 9, line 31 skipping to change at page 9, line 31
exchanged during the execution of the protocol, namely 'RAND_Peer || exchanged during the execution of the protocol, namely 'RAND_Peer ||
ID_Peer || RAND_Server || ID_Server' referred as inputString as its ID_Peer || RAND_Server || ID_Server' referred as inputString as its
short-hand form. short-hand form.
In case of successful completion, EAP-GPSK derives and exports an MSK In case of successful completion, EAP-GPSK derives and exports an MSK
and EMSK both in length of 64 octets. and EMSK both in length of 64 octets.
The following notation is used: KDF-X(Y, Z)[A..B], whereby The following notation is used: KDF-X(Y, Z)[A..B], whereby
X is the length, in octets, of the desired output, X is the length, in octets, of the desired output,
Y is a secret key, Y is a secret key,
Z is the inputstring, Z is the inputString,
[A..B] extracts the string of octects starting with octet A [A..B] extracts the string of octets starting with octet A finishing
finishing with octet B from the output of the KDF function. with octet B from the output of the KDF function.
This keying material is derived using the ciphersuite-specified KDF This keying material is derived using the ciphersuite-specified KDF
as follows: as follows:
o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
o MK = KDF-KS(0x00, PL || PSK || CSuite_Sel || inputString)[0..KS-1] o MK = KDF-KS(0x00, PL || PSK || CSuite_Sel || inputString)[0..KS-1]
o MSK = KDF-{128+2*KS}(MK, inputString)[0..63] o MSK = KDF-{128+2*KS}(MK, inputString)[0..63]
o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127] o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]
o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS] o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]
o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using
skipping to change at page 11, line 15 skipping to change at page 11, line 15
offered. Extensibility is provided with the introduction of new offered. Extensibility is provided with the introduction of new
ciphersuites; this document specifies an initial set. The CSuite/ ciphersuites; this document specifies an initial set. The CSuite/
Specifier column in Figure 3 uniquely identifies a ciphersuite. Specifier column in Figure 3 uniquely identifies a ciphersuite.
For a vendor-specific ciphersuite the first three octets are the For a vendor-specific ciphersuite the first three octets are the
vendor-specific OID, and the last three octets are vendor assigned vendor-specific OID, and the last three octets are vendor assigned
for the specific ciphersuite. for the specific ciphersuite.
The following ciphersuites are specified in this document: The following ciphersuites are specified in this document:
+-----------+----+-------------+--------------+----------------------+ +-----------+----+-------------+--------------+----------------+
| CSuite/ | KS | Encryption | Integrity | Key Derivation | | CSuite/ | KS | Encryption | Integrity / | Key Derivation |
| Specifier | | | | Function | | Specifier | | | KDF MAC | Function |
+-----------+----+-------------+--------------+----------------------+ +-----------+----+-------------+--------------+----------------+
| 0x000001 | 16 | AES-CBC-128 | AES_CMAC_128 | GKDF with SHA256 | | 0x000001 | 16 | AES-CBC-128 | AES_CMAC_128 | GKDF |
+-----------+----+-------------+--------------+----------------------+ +-----------+----+-------------+--------------+----------------+
| 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF with SHA256 | | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF |
+-----------+----+-------------+--------------+----------------------+ +-----------+----+-------------+--------------+----------------+
Figure 3: Ciphersuites Figure 3: Ciphersuites
Ciphersuite 1, which is based on AES as a cryptographic primitive, is Ciphersuite 1, which is based on AES as a cryptographic primitive, is
mandatory to implement. This document specifies also a second mandatory to implement. This document specifies also a second
ciphersuite, but its support is optional. ciphersuite, but its support is optional.
Each ciphersuite needs to specify a key derivation function. The Each ciphersuite needs to specify a key derivation function. The
ciphersuites defined in this document make use of the Generalized Key ciphersuites defined in this document make use of the Generalized Key
Distribution Function (GKDF). Future ciphersuites can use any other Distribution Function (GKDF) which utilizes the MAC function defined
formally specified KDF that takes as arguments a key and a seed in the ciphersuite. Future ciphersuites can use any other formally
value, and produces at least 128+2*KS octets of output. specified KDF that takes as arguments a key and a seed value, and
produces at least 128+2*KS octets of output.
GKDF has the following structure: GKDF has the following structure:
GKDF-X(Y, Z) GKDF-X(Y, Z)
X length, in octets, of the desired output X length, in octets, of the desired output
Y secret key Y secret key
Z inputstring Z inputString
Hash-Function hash function provided as part of the ciphersuite
definition.
hashlen the size of hash function output in octets.
GKDF-X (Y, Z) { GKDF-X (Y, Z) {
n = ceiling integer of ( X / hashlen ); n = ceiling integer of ( X / KS );
/* determine number of output blocks */ /* determine number of output blocks */
M_0 = ""; M_0 = "";
result = ""; result = "";
for i = 1 to n { for i = 1 to n {
M_i = Hash-Function (i || Y || Z); M_i = MAC_Y (i || Z);
result = result || M_i; result = result || M_i;
} }
return truncate (result) return truncate (result)
} }
Note that the variable 'i' in M_i is represented as a 2-octet value Note that the variable 'i' in M_i is represented as a 2-octet value
in network byte order. in network byte order.
6. Ciphersuites Processing Rules 6. Ciphersuites Processing Rules
skipping to change at page 13, line 25 skipping to change at page 13, line 25
MK = GKDF-32 (0x00, PL || PSK || CSuite_Sel || inputString) MK = GKDF-32 (0x00, PL || PSK || CSuite_Sel || inputString)
MSK = GKDF-160 (MK, inputString)[0..63] MSK = GKDF-160 (MK, inputString)[0..63]
EMSK = GKDF-160 (MK, inputString)[64..127] EMSK = GKDF-160 (MK, inputString)[64..127]
SK = GKDF-160 (MK, inputString)[128..143] SK = GKDF-160 (MK, inputString)[128..143]
PK = GKDF-160 (MK, inputString)[144..159] PK = GKDF-160 (MK, inputString)[144..159]
MID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel || Method-ID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type ||
inputString) CSuite_Sel || inputString)
Hash-Function = SHA256 (see [RFC4634])
hashlen = 32 octets (256 bits)
6.2. Ciphersuite #2 6.2. Ciphersuite #2
6.2.1. Encryption 6.2.1. Encryption
Ciphersuite 2 does not include an algorithm for encryption. With a Ciphersuite 2 does not include an algorithm for encryption. With a
NULL encryption algorithm, encryption is defined as: NULL encryption algorithm, encryption is defined as:
E_X(Y) = Y E_X(Y) = Y
When using this ciphersuite, the data exchanged inside the protected When using this ciphersuite, the data exchanged inside the protected
data block is not encrypted. Therefore this mode MUST NOT be used if data block is not encrypted. Therefore this mode MUST NOT be used if
confidential information appears inside the protected data block. confidential information appears inside the protected data block.
6.2.2. Integrity 6.2.2. Integrity
Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash
algorithm. algorithm (see [RFC4634]).
For integrity protection the following instantiation is used: For integrity protection the following instantiation is used:
HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK
where Input refers to the following content: where Input refers to the following content:
o Value of SEC_SK(Value) in message GPSK-2 o Value of SEC_SK(Value) in message GPSK-2
o Value of SEC_SK(Value) in message GPSK-3 o Value of SEC_SK(Value) in message GPSK-3
o Value of SEC_SK(Value) in message GPSK-4 o Value of SEC_SK(Value) in message GPSK-4
6.2.3. Key Derivation 6.2.3. Key Derivation
This ciphersuite instantiates the KDF in the following way: This ciphersuite instantiates the KDF in the following way:
inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
MK = GKDF-32 (0x00, PL || PSK || CSuite_Sel || inputString) MK = GKDF-32 (0x00, PL || PSK || CSuite_Sel || inputString)
MSK = GKDF-192 (MK, inputString)[0..63] MSK = GKDF-160 (MK, inputString)[0..63]
EMSK = GKDF-192 (MK, inputString)[64..127]
SK = GKDF-192 (MK, inputString)[128..159]
MID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel || EMSK = GKDF-160 (MK, inputString)[64..127]
inputString)
Hash-Function = SHA256 (see [RFC4634]) SK = GKDF-160 (MK, inputString)[128..159]
hashlen = 32 octets (256 bits) Method-ID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString)
7. Packet Formats 7. Packet Formats
This section defines the packet format of the EAP-GPSK messages. This section defines the packet format of the EAP-GPSK messages.
7.1. Header Format 7.1. Header Format
The EAP-GPSK header has the following structure: The EAP-GPSK header has the following structure:
--- bit offset ---> --- bit offset --->
skipping to change at page 20, line 27 skipping to change at page 20, line 27
is not authorized to connect. is not authorized to connect.
7.4. Protected Data 7.4. Protected Data
The protected data blocks are a generic mechanism for the peer and The protected data blocks are a generic mechanism for the peer and
server to securely exchange data. If the specified ciphersuite has a server to securely exchange data. If the specified ciphersuite has a
NULL encryption primitive, then this channel only offers NULL encryption primitive, then this channel only offers
authenticity, and not confidentiality. authenticity, and not confidentiality.
These payloads are encoded as the concatenation of type-length-value These payloads are encoded as the concatenation of type-length-value
(TLV) tripples called PD_Payloads. (TLV) triples called PD_Payloads.
Type values are encoded as a 6-octet string and represented by a Type values are encoded as a 6-octet string and represented by a
3-octet vendor and 3-octet specifier field. The vendor field 3-octet vendor and 3-octet specifier field. The vendor field
indicates the type as either standards-specified or vendor-specific. indicates the type as either standards-specified or vendor-specific.
If these three octets are 0x000000, then the value is standards- If these three octets are 0x000000, then the value is standards-
specified, and any other value represents a vendor-specific OID. specified, and any other value represents a vendor-specific OID.
The specifier field indicates the actual type. For vendor field The specifier field indicates the actual type. For vendor field
0x000000, the specifier field is maintained by IANA. For any other 0x000000, the specifier field is maintained by IANA. For any other
vendor field, the specifier field is maintained by the vendor. vendor field, the specifier field is maintained by the vendor.
skipping to change at page 22, line 12 skipping to change at page 22, line 12
The Initialization Vector is a randomly chosen value whose length is The Initialization Vector is a randomly chosen value whose length is
equal to the block length of the underlying encryption algorithm. equal to the block length of the underlying encryption algorithm.
Recipients MUST accept any value. Senders SHOULD either pick this Recipients MUST accept any value. Senders SHOULD either pick this
value pseudo-randomly and independently for each message or use the value pseudo-randomly and independently for each message or use the
final ciphertext block of the previous message sent. Senders MUST final ciphertext block of the previous message sent. Senders MUST
NOT use the same value for each message, use a sequence of values NOT use the same value for each message, use a sequence of values
with low hamming distance (e.g., a sequence number), or use with low hamming distance (e.g., a sequence number), or use
ciphertext from a received message. ciphertext from a received message.
The concatination of PD_Payloads along with the padding and padding The concatenation of PD_Payloads along with the padding and padding
length are all encrypted using the negotiated block cipher. If no length are all encrypted using the negotiated block cipher. If no
block cipher is specified, then these fields are not encrypted. block cipher is specified, then these fields are not encrypted.
The Padding field MAY contain any value chosen by the sender, and The Padding field MAY contain any value chosen by the sender, and
MUST have a length that makes the combination of the concatination of MUST have a length that makes the combination of the concatenation of
PD_Payloads, the Padding, and the Pad Length to be a multiple of the PD_Payloads, the Padding, and the Pad Length to be a multiple of the
encryption block size. encryption block size.
The Pad Length field is the length of the Padding field. The sender The Pad Length field is the length of the Padding field. The sender
SHOULD set the Pad Length to the minimum value that makes the SHOULD set the Pad Length to the minimum value that makes the
combination of the PD_Payloads, the Padding, and the Pad Length a combination of the PD_Payloads, the Padding, and the Pad Length a
multiple of the block size, but the recipient MUST accept any length multiple of the block size, but the recipient MUST accept any length
that results in proper alignment. This field is encrypted with the that results in proper alignment. This field is encrypted with the
negotiated cipher. negotiated cipher.
skipping to change at page 24, line 5 skipping to change at page 24, line 5
before receiving GPSK-1 or before transmitting GPSK-2) MUST silently before receiving GPSK-1 or before transmitting GPSK-2) MUST silently
discard the packet. discard the packet.
GPSK-1 contains no MAC protection, so provided it properly parses, it GPSK-1 contains no MAC protection, so provided it properly parses, it
MUST be accepted by the peer. Note that the ciphersuite list MUST be accepted by the peer. Note that the ciphersuite list
provided by the EAP server in CSuite_List MUST always include the provided by the EAP server in CSuite_List MUST always include the
mandatory-to-implement ciphersuite defined in this document. Hence, mandatory-to-implement ciphersuite defined in this document. Hence,
there is always at least one ciphersuite in common between the EAP there is always at least one ciphersuite in common between the EAP
peer and the EAP server. If the EAP peer decides the ID_Server is peer and the EAP server. If the EAP peer decides the ID_Server is
that of a AAA server to which it does not wish to authenticate, the that of a AAA server to which it does not wish to authenticate, the
EAP peer should respond with an EAP-Nak. EAP peer should respond with an EAP-NAK.
For GPSK-2, if ID_Peer is for an unknown user, the EAP server MUST For GPSK-2, if ID_Peer is for an unknown user, the EAP server MUST
send either a "PSK Not Found" GPSK-Fail message, or an send either a "PSK Not Found" GPSK-Fail message, or an
"Authentication Failure" GPSK-Fail, depending on its policy, and "Authentication Failure" GPSK-Fail, depending on its policy, and
discard the received packet. If the MAC validation fails, the server discard the received packet. If the MAC validation fails, the server
MUST transmit a GPSK-Fail message specifying "Authentication Failure" MUST transmit a GPSK-Fail message specifying "Authentication Failure"
and discard the received packet. If the RAND_Server or CSuite_List and discard the received packet. If the RAND_Server or CSuite_List
field in GPSK-2 does not match the values in GPSK-1, the server MUST field in GPSK-2 does not match the values in GPSK-1, the server MUST
silently discard the packet. If server policy determines the peer is silently discard the packet. If server policy determines the peer is
not authorized and the MAC is correct, the server MUST transmit a not authorized and the MAC is correct, the server MUST transmit a
skipping to change at page 25, line 15 skipping to change at page 25, line 15
+--------+ +--------+ +--------+ +--------+
| | EAP-Request/Identity | | | | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP | | EAP |<------------------------------------| EAP |
| peer | | server | | peer | | server |
| | EAP-Response/Identity | | | | EAP-Response/Identity | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-1 | | | | EAP-Request/GPSK-1 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/EAP-Nak | | | | EAP-Response/EAP-NAK | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Failure | | | | EAP-Failure | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Unacceptable AAA server identity; EAP-GPSK: Unsuccessful Exchange (Unacceptable AAA server identity;
ID_Server) ID_Server)
+--------+ +--------+ +--------+ +--------+
skipping to change at page 32, line 40 skipping to change at page 32, line 40
o Jouni Malinen for his suggestions regarding the examples and the o Jouni Malinen for his suggestions regarding the examples and the
key derivation function in February 2007. key derivation function in February 2007.
o Bernard Aboba and Jouni Malinen for their review in February 2007. o Bernard Aboba and Jouni Malinen for their review in February 2007.
o Vidya Narayanan for her review in March 2007. o Vidya Narayanan for her review in March 2007.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
14.2. Informative References
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, August 2006. (SHA and HMAC-SHA)", RFC 4634, August 2006.
[CMAC] National Institute of Standards and Technology, [CMAC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: The "Recommendation for Block Cipher Modes of Operation: The
CMAC Mode for Authentication", Special Publication CMAC Mode for Authentication", Special Publication
(SP) 800-38B, May 2005. (SP) 800-38B, May 2005.
[CBC] National Institute of Standards and Technology, [CBC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Encryption. "Recommendation for Block Cipher Modes of Encryption.
Methods and Techniques.", Special Publication (SP) 800- Methods and Techniques.", Special Publication (SP) 800-
38A, December 2001. 38A, December 2001.
14.2. Informative References
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
Authors' Addresses Authors' Addresses
T. Charles Clancy T. Charles Clancy
DoD Laboratory for Telecommunications Sciences DoD Laboratory for Telecommunications Sciences
8080 Greenmead Drive 8080 Greenmead Drive
College Park, MD 20740 College Park, MD 20740
USA USA
Email: clancy@ltsnet.net Email: clancy@ltsnet.net
Hannes Tschofenig Hannes Tschofenig
Siemens Networks GmbH & Co KG Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
 End of changes. 26 change blocks. 
64 lines changed or deleted 53 lines changed or added

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