draft-ietf-emu-eap-gpsk-05.txt   draft-ietf-emu-eap-gpsk-06.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: October 7, 2007 Nokia Siemens Networks Expires: January 7, 2008 Nokia Siemens Networks
April 5, 2007 July 6, 2007
EAP Generalized Pre-Shared Key (EAP-GPSK) EAP Generalized Pre-Shared Key (EAP-GPSK)
draft-ietf-emu-eap-gpsk-05 draft-ietf-emu-eap-gpsk-06
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 October 7, 2007. This Internet-Draft will expire on January 7, 2008.
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 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 12 6. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 12
6.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 12 6.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 15 7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16
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 3, line 10 skipping to change at page 3, line 10
10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 30 10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 30
10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30 10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30
10.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 30 10.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 30
10.14. Identity Protection . . . . . . . . . . . . . . . . . . . 30 10.14. Identity Protection . . . . . . . . . . . . . . . . . . . 30
10.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 30 10.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 30
10.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30 10.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30
10.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 30 10.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . 32 14.1. Normative References . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . 33 14.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . . . 35
1. Introduction 1. Introduction
EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a
generalized pre-shared key authentication technique. Mutual generalized pre-shared key authentication technique. Mutual
authentication is achieved through a nonce-based exchange that is authentication is achieved through a nonce-based exchange that is
secured by a pre-shared key. secured by a pre-shared key.
EAP-GPSK addresses a large number of design goals with the intention EAP-GPSK addresses a large number of design goals with the intention
of being applicable in a broad range of usage scenarios. of being applicable in a broad range of usage scenarios.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
PL: Integer representing the length of the PSK in octets (2 octets) PL: Integer representing the length of the PSK in octets (2 octets)
RAND_Peer: Random integer generated by the peer (32 octets) RAND_Peer: Random integer generated by the peer (32 octets)
RAND_Server: Random integer generated by the server (32 octets) RAND_Server: Random integer generated by the server (32 octets)
Operations: Operations:
A || B: Concatenation of octet strings A and B A || B: Concatenation of octet strings A and B
A**B: Integer exponentiation
truncate(A,B): Returns the first B octets of A
ENC_X(Y): Encryption of message Y with a symmetric key X, using a ENC_X(Y): Encryption of message Y with a symmetric key X, using a
defined block cipher defined block cipher
KDF_X(Y): Key Derivation Function that generates an arbitrary number KDF_X(Y): Key Derivation Function that generates an arbitrary number
of octets of output using secret X and seed Y of octets of output using secret X and seed Y
length(X): Function that returns the length of input X in octets, length(X): Function that returns the length of input X in octets,
encoded as a 2-octet integer in network byte order encoded as a 2-octet integer in network byte order
MAC_X(Y): Keyed message authentication code computed over Y with MAC_X(Y): Keyed message authentication code computed over Y with
symmetric key X symmetric key X
SEC_X(Y): SEC is a function that provides integrity protection based SEC_X(Y): SEC is a function that provides integrity protection based
skipping to change at page 7, line 46 skipping to change at page 8, line 4
| | EAP-Response/GPSK-4 | | | | EAP-Response/GPSK-4 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Success | | | | EAP-Success | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
Figure 1: EAP-GPSK: Successful Exchange Figure 1: EAP-GPSK: Successful Exchange
The full EAP-GPSK protocol is as follows: The full EAP-GPSK protocol is as follows:
GPSK-1: GPSK-1:
ID_Server, RAND_Server, CSuite_List ID_Server, RAND_Server, CSuite_List
GPSK-2: GPSK-2:
SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List, SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List,
CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] ) CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )
GPSK-3 GPSK-3:
SEC_SK(RAND_Peer, RAND_Server, CSuite_Sel, [ SEC_SK(RAND_Peer, RAND_Server, CSuite_Sel, [
ENC_PK(PD_Payload_Block) ] ) ENC_PK(PD_Payload_Block) ] )
GPSK-4: GPSK-4:
SEC_SK( [ ENC_PK(PD_Payload_Block) ] ) SEC_SK( [ ENC_PK(PD_Payload_Block) ] )
The EAP server begins EAP-GPSK by selecting a random number The EAP server begins EAP-GPSK by selecting a random number
RAND_Server and by encoding the supported ciphersuites into RAND_Server and by encoding the supported ciphersuites into
skipping to change at page 9, line 39 skipping to change at page 9, line 40
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 octets starting with octet A finishing [A..B] extracts the string of octets starting with octet A 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 zero = 0x00 || 0x00 || ... || 0x00 (KS times)
o MK = KDF-KS(zero, 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
an encrypting ciphersuite) an encrypting ciphersuite)
Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires
the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID.
These values are defined as: These values are defined as:
o Method-ID = KDF-16(0x00, "Method ID" || EAP_Method_Type || o zero = 0x00 || 0x00 || ... || 0x00 (KS times)
o Method-ID = KDF-16(zero, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString)[0..15] CSuite_Sel || inputString)[0..15]
o Session-ID = Type_Code || Method_ID o Session-ID = Type_Code || Method_ID
o Peer-ID = ID_Peer o Peer-ID = ID_Peer
o Server-ID = ID_Server o Server-ID = ID_Server
EAP_Method_Type refers to the integer value of the IANA allocated EAP EAP_Method_Type refers to the integer value of the IANA allocated EAP
Type code. Type code.
Figure 2 depicts the key derivation procedure of EAP-GPSK. Figure 2 depicts the key derivation procedure of EAP-GPSK.
skipping to change at page 11, line 10 skipping to change at page 11, line 15
5. Ciphersuites 5. Ciphersuites
The design of EAP-GPSK allows cryptographic algorithms and key sizes, The design of EAP-GPSK allows cryptographic algorithms and key sizes,
called ciphersuites, to be negotiated during the protocol run. The called ciphersuites, to be negotiated during the protocol run. The
ability to specify block-based and hash-based ciphersuites is ability to specify block-based and hash-based ciphersuites is
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 Object Identifier (OID) contains the IANA assigned
for the specific ciphersuite. "SMI Network Management Private Enterprise Codes" value (see
[RFC3232]), encoded in network byte order. The last three octets are
vendor assigned 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 | | | KDF MAC | Function | | Specifier | | | KDF MAC | Function |
+-----------+----+-------------+--------------+----------------+ +-----------+----+-------------+--------------+----------------+
| 0x000001 | 16 | AES-CBC-128 | AES_CMAC_128 | GKDF | | 0x000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF |
+-----------+----+-------------+--------------+----------------+ +-----------+----+-------------+--------------+----------------+
| 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF | | 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.
skipping to change at page 11, line 40 skipping to change at page 12, line 4
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) which utilizes the MAC function defined Distribution Function (GKDF) which utilizes the MAC function defined
in the ciphersuite. Future ciphersuites can use any other formally in the ciphersuite. Future ciphersuites can use any other formally
specified KDF that takes as arguments a key and a seed value, and specified KDF that takes as arguments a key and a seed value, and
produces at least 128+2*KS octets of output. 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
GKDF-X (Y, Z) {
GKDF-X (Y, Z)
{
n = ceiling integer of ( X / KS ); 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 = MAC_Y (i || Z); M_i = MAC_Y (i || Z);
result = result || M_i; result = result || M_i;
} }
return truncate (result) return truncate(result, X)
} }
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
6.1. Ciphersuite #1 6.1. Ciphersuite #1
6.1.1. Encryption 6.1.1. Encryption
With this ciphersuite all cryptography is built around a single With this ciphersuite all cryptography is built around a single
cryptographic primitive, AES-128. Within the protected data frames, cryptographic primitive, AES-128 ([AES]). Within the protected data
AES-128 is used in Cipher Block Chaining (CBC) mode of operation (see frames, AES-128 is used in Cipher Block Chaining (CBC) mode of
[CBC]). This EAP method uses encryption in a single payload, in the operation (see [CBC]). This EAP method uses encryption in a single
protected data payload (see Section 7.4). payload, in the protected data payload (see Section 7.4).
In a nutshell, the CBC mode proceeds as follows. The IV is XORed In a nutshell, the CBC mode proceeds as follows. The IV is XORed
with the first plaintext block before it is encrypted. Then for with the first plaintext block before it is encrypted. Then for
successive blocks, the previous ciphertext block is XORed with the successive blocks, the previous ciphertext block is XORed with the
current plaintext, before it is encrypted. current plaintext, before it is encrypted.
6.1.2. Integrity 6.1.2. Integrity
Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is
recommended by NIST. Among its advantages, CMAC is capable to work recommended by NIST. Among its advantages, CMAC is capable to work
with messages of arbitrary length. A detailed description of CMAC with messages of arbitrary length. A detailed description of CMAC
can be found in [CMAC]. can be found in [CMAC].
The following instantiation is used: AES-128-CMAC(SK, Input) denotes The following instantiation is used: AES-CMAC-128(SK, Input) denotes
the MAC of Input under the key SK. 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.1.3. Key Derivation 6.1.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) zero = 0x00 || 0x00 || ... || 0x00 (16 times)
MK = GKDF-16 (zero, 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]
Method-ID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString) CSuite_Sel || inputString)
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
skipping to change at page 14, line 15 skipping to change at page 14, line 20
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) zero = 0x00 || 0x00 || ... || 0x00 (32 times)
MK = GKDF-32 (zero, 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..159] SK = GKDF-160 (MK, inputString)[128..159]
Method-ID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString) 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:
skipping to change at page 15, line 13 skipping to change at page 15, line 32
XX for EAP-GPSK, thus the Type field in the EAP header MUST be XX. XX for EAP-GPSK, thus the Type field in the EAP header MUST be XX.
The OP-Code field is one of four values: The OP-Code field is one of four values:
o 0x01 : GPSK-1 o 0x01 : GPSK-1
o 0x02 : GPSK-2 o 0x02 : GPSK-2
o 0x03 : GPSK-3 o 0x03 : GPSK-3
o 0x04 : GPSK-4 o 0x04 : GPSK-4
o 0x05 : GPSK-Fail o 0x05 : GPSK-Fail
o 0x06 : GPSK-Protected-Fail o 0x06 : GPSK-Protected-Fail
All other values of this OP-Code field are available via IANA
registration.
7.2. Ciphersuite Formatting 7.2. Ciphersuite Formatting
Ciphersuites are encoded as 6-octet arrays. The first three octets Ciphersuites are encoded as 6-octet arrays. The first four octets
indicate the CSuite/Vendor field. For vendor-specific ciphersuites, indicate the CSuite/Vendor field. For vendor-specific ciphersuites,
this represents the vendor OID. The last three octets indicate the this represents the vendor Object Identifier (OID) contains the IANA
CSuite/Specifier field, which identifies the particular ciphersuite. assigned "SMI Network Management Private Enterprise Codes" value (see
The 3-octet CSuite/Vendor value 0x000000 indicates ciphersuites [RFC3232]), encoded in network byte order. The last two octets
allocated by the IETF. indicate the CSuite/Specifier field, which identifies the particular
ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates
ciphersuites allocated by the IETF.
Graphically, they are represented as Graphically, they are represented as
--- bit offset ---> --- bit offset --->
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Vendor = 0x000000 or OID | | CSuite/Vendor = 0x00000000 or OID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CSuite / Specifier | | CSuite/Specifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Figure 6
CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and
CSuite/Specifier pair. CSuite/Specifier pair.
CSuite_List is a variable-length octet array of ciphersuites. It is CSuite_List is a variable-length octet array of ciphersuites. It is
encoded by concatenating encoded ciphersuite values. Its length in encoded by concatenating encoded ciphersuite values. Its length in
octets MUST be a multiple of 6. octets MUST be a multiple of 6.
skipping to change at page 20, line 11 skipping to change at page 20, line 11
... KS-octet payload MAC ... ... KS-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: GPSK-Protected-Fail Payload Figure 12: GPSK-Protected-Fail Payload
The Failure-Code field is one of three values, but can be extended: The Failure-Code field is one of three values, but can be extended:
o 0x00000001: PSK Not Found o 0x00000001: PSK Not Found
o 0x00000002: Authentication Failure o 0x00000002: Authentication Failure
o 0x00000003: Authorization Failure o 0x00000003: Authorization Failure
o 0x00000004 through 0xFFFFFFFF : Unallocated All other values of this field are available via IANA registration.
"PSK Not Found" indicates a key for a particular user could not be "PSK Not Found" indicates a key for a particular user could not be
located, making authentication impossible. "Authentication Failure" located, making authentication impossible. "Authentication Failure"
indicates a MAC failure due to a PSK mismatch. "Authorization indicates a MAC failure due to a PSK mismatch. "Authorization
Failure" indicates that while the PSK being used is correct, the user Failure" indicates that while the PSK being used is correct, the user
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) triples 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 4-octet vendor and 2-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 0x00000000, then the value is standards-
specified, and any other value represents a vendor-specific OID. specified, and any other value represents a vendor-specific Object
Identifier (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 0x00000000, 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.
Length fields are specified as 2-octet integers in network byte Length fields are specified as 2-octet integers in network byte
order, and reflect only the length of the value, and do not include order, and reflect only the length of the value, and do not include
the length of the type and length fields. the length of the type and length fields.
Graphically, this can be depicted as follows: Graphically, this can be depicted as follows:
--- bit offset ---> --- bit offset --->
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PData/Vendor | | PData/Vendor | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PData/Specifier | PData/Length | PData/Specifier | PData/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... PData/Value ... ... PData/Value ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protected Data Payload (PD_Payload) Formatting Protected Data Payload (PD_Payload) Formatting
skipping to change at page 23, line 7 skipping to change at page 23, line 7
| | 0x00 | | | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protected Data Block (PD_Payload_Block) Formatting Without Encryption Protected Data Block (PD_Payload_Block) Formatting Without Encryption
For PData/Vendor field 0x000000, the following PData/Specifier fields For PData/Vendor field 0x000000, the following PData/Specifier fields
are defined: are defined:
o 0x000000 : Reserved o 0x000000 : Reserved
o 0x000001 : Protected Results Indication o 0x000001 : Protected Results Indication
o 0x000002 through 0xFFFFFF : Unallocated All other values of this field are available via IANA registration.
7.4.1. Protected Results Indication 7.4.1. Protected Results Indication
Based on the PData/Specifier allocation the following 8-bit payload Based on the PData/Specifier allocation the following 8-bit payload
is specified to be placed in the PD_Payload Value to provide the is specified to be placed in the PD_Payload Value to provide the
functionality of protected results indication. functionality of protected results indication.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 25, line 39 skipping to change at page 25, line 39
| | EAP-Response/Identity | | | | EAP-Response/Identity | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-1 | | | | EAP-Request/GPSK-1 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-2 | | | | EAP-Response/GPSK-2 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-3 (GPSK-Fail | | | | EAP-Request/GPSK-3 (GPSK-Fail | |
| | (PSK Not Found or AuthenFail) | | | | (PSK Not Found or Authentication | |
| | Failure)) | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-4 (GPSK-Fail) | | | | EAP-Response/GPSK-4 (GPSK-Fail | |
| | (PSK Not Found or AuthenFail) | | | | (PSK Not Found or Authentication | |
| | Failure)) | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Failure | | | | EAP-Failure | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Unknown user) EAP-GPSK: Unsuccessful Exchange (Unknown user)
+--------+ +--------+ +--------+ +--------+
| | 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 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
skipping to change at page 26, line 18 skipping to change at page 26, line 20
| | EAP-Response/Identity | | | | EAP-Response/Identity | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-1 | | | | EAP-Request/GPSK-1 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-2 | | | | EAP-Response/GPSK-2 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-3 (GPSK-Fail | | | | EAP-Request/GPSK-3 (GPSK-Fail | |
| | (AuthenFail) | | | | (Authentication Failure)) | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-4 (GPSK-Fail) | | | | EAP-Response/GPSK-4 (GPSK-Fail | |
| | (AuthenFail) | | | | (Authentication Failure)) | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Failure | | | | EAP-Failure | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2) EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2)
+--------+ +--------+ +--------+ +--------+
| | EAP-Request/Identity | | | | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP | | EAP |<------------------------------------| EAP |
skipping to change at page 28, line 5 skipping to change at page 28, line 5
10.1. Mutual Authentication 10.1. Mutual Authentication
EAP-GPSK provides mutual authentication. EAP-GPSK provides mutual authentication.
The server believes that the peer is authentic because it can The server believes that the peer is authentic because it can
calculate a valid MAC and the peer believes that the server is calculate a valid MAC and the peer believes that the server is
authentic because it can calculate another valid MAC. authentic because it can calculate another valid MAC.
The key used for mutual authentication is computed again based on the The key used for mutual authentication is computed again based on the
long-term secret PSK that has to provide sufficient entropy and long-term secret PSK that has to provide sufficient entropy and
therefore sufficient strength. In this way EAP-GPSK is no different therefore sufficient strength. In this way EAP-GPSK is not different
than other authentication protocols based on pre-shared keys. than other authentication protocols based on pre-shared keys.
10.2. Protected Result Indications 10.2. Protected Result Indications
EAP-GPSK offers the capability to exchange protected result EAP-GPSK offers the capability to exchange protected result
indications using the protected data payloads. indications using the protected data payloads.
10.3. Integrity Protection 10.3. Integrity Protection
EAP-GPSK provides integrity protection based on the ciphersuites EAP-GPSK provides integrity protection based on the ciphersuites
skipping to change at page 31, line 4 skipping to change at page 31, line 4
10.17. Cryptographic Binding 10.17. Cryptographic Binding
Since EAP-GPSK does not tunnel another EAP method, it does not Since EAP-GPSK does not tunnel another EAP method, it does not
implement cryptographic binding. implement cryptographic binding.
11. IANA Considerations 11. IANA Considerations
This document requires IANA to allocate a new EAP Type for EAP-GPSK. This document requires IANA to allocate a new EAP Type for EAP-GPSK.
This document requires IANA to create a new registry for This document requires IANA to create a new registry for
ciphersuites, protected data types, and failure codes. IANA is ciphersuites, protected data types, failure codes and op-codes. IANA
furthermore instructed to add the specified ciphersuites, protected is furthermore instructed to add the specified ciphersuites,
data types, and failure codes to this registry as defined in this protected data types, failure codes and op-codes to these registries
document. Values can be added or modified with informational RFCs as defined in this document. Values can be added or modified with
defining either block-based or hash-based ciphersuites, protected informational RFCs defining either block-based or hash-based
data payloads, or failure codes. Each ciphersuite needs to provide ciphersuites, protected data payloads, failure codes and op-codes.
processing rules and needs to specify how the following algorithms Each ciphersuite needs to provide processing rules and needs to
are instantiated: Encryption, Integrity and Key Derivation. specify how the following algorithms are instantiated: encryption,
Additionally, the preferred key size needs to be specified. integrity, key derivation and key length.
The following layout represents the initial ciphersuite CSuite/
Specifier registry setup:
o 0x000000 : Reserved Figure 3 represents the initial ciphersuite CSuite/Specifier registry
o 0x000001 : AES-CBC-128, AES-CMAC-128, GKDF-128 setup. The CSuite/Specifier field is 16 bits long. All other values
o 0x000002 : NULL, HMAC-SHA256, GKDF-256 are available via IANA registration.
o 0x000003 through 0xFFFFFF : Unallocated
The following is the initial protected data PData/Specifier registry The following is the initial protected data PData/Specifier registry
setup: setup:
o 0x000000 : Reserved o 0x000000 : Reserved
o 0x000001 : Protected Results Indication o 0x000001 : Protected Results Indication
o 0x000002 through 0xFFFFFF : Unallocated
The PData/Specifier field is 24 bits long and all other values are
available via IANA registration.
The following layout represents the initial Failure-Code registry The following layout represents the initial Failure-Code registry
setup: setup:
o 0x00000001: PSK Not Found o 0x00000001: PSK Not Found
o 0x00000002: Authentication Failure o 0x00000002: Authentication Failure
o 0x00000003: Authorization Failure o 0x00000003: Authorization Failure
o 0x00000004 through 0xFFFFFFFF : Unallocated
The Failure-Code field is 32 bits long and all other values are
available via IANA registration.
The following layout represents the initial OP-Code registry setup:
o 0x01 : GPSK-1
o 0x02 : GPSK-2
o 0x03 : GPSK-3
o 0x04 : GPSK-4
o 0x05 : GPSK-Fail
o 0x06 : GPSK-Protected-Fail
The OP-Code field is 8 bits long and all other values are available
via IANA registration.
12. Contributors 12. Contributors
This work is a joint effort of the EAP Method Update (EMU) design This work is a joint effort of the EAP Method Update (EMU) design
team of the EMU Working Group that was created to develop a mechanism team of the EMU Working Group that was created to develop a mechanism
based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC
4017 [RFC4017] requirements. The design team members (in 4017 [RFC4017] requirements. The design team members (in
alphabetical order) were: alphabetical order) were:
o Jari Arkko o Jari Arkko
skipping to change at page 32, line 34 skipping to change at page 32, line 47
discussions between July and August 2006. discussions between July and August 2006.
o Lakshminath Dondeti for his detailed draft review (sent to the EMU o Lakshminath Dondeti for his detailed draft review (sent to the EMU
ML on the 12th July 2006). ML on the 12th July 2006).
o Based on a review requested from NIST Quynh Dang suggested changes o Based on a review requested from NIST Quynh Dang suggested changes
to the GKDF function (December 2006). to the GKDF function (December 2006).
o Jouni Malinen and Victor Fajardo for their review in January 2007. o Jouni Malinen and Victor Fajardo for their review in January 2007.
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.
o
o Joe Salowey, the EMU working group chair, provided a document
review in April 2007. Jouni Malinen also reviewed the document
during the same month.
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", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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)",
skipping to change at page 33, line 17 skipping to change at page 33, line 31
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007. progress), February 2007.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005. 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, July 2006.
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard
(AES)", Federal Information Processing Standards
(FIPS) 197, November 2001.
[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.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
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
Nokia Siemens Networks 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@nsn.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).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 54 change blocks. 
72 lines changed or deleted 119 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/