One document matched: draft-salowey-eap-protectedtlv-02.txt
Differences from draft-salowey-eap-protectedtlv-01.txt
Network Working Group
Internet Draft J. Salowey
Document:draft-salowey-eap-protectedtlv-02.txt Cisco Systems
Expires: December 2003 June 2003
Protected EAP TLV
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [i].
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.
Abstract
EAP type-length-value (TLV) message types provide a mechanism for
encapsulating additional information in an EAP conversation. In some
cases it is useful to cryptographically protect this information to
maintain the integrity and/or privacy of the communication. This
document defines TLV types that provide message authentication to
maintain the integrity of the data, encryption to protect the privacy
of the data and sequence numbers to protect replays or re-sequencing
of the data. Although protected TLVs must be chained after an
authentication mechanism that generates key material the protection
mechanism is independent of any particular authentication mechanism.
This makes them useful for adding generic extensions to EAP methods.
Table of Contents
1. Introduction...................................................2
1.1 Terminology................................................2
1.2 Uses.......................................................3
2. Message protection and validation..............................3
2.1 AES-128-CBC with HMAC-SHA1-128.............................4
Salowey Expires - December 2003 [Page 1]
Protected EAP TLV June 2003
3. Protected TLV formats..........................................4
In the following formats bits are transmitted from left to right..4
3.1 SeqNo-TLV..................................................4
3.2 MAC-TLV....................................................5
3.3 Encrypted-TLV..............................................6
3.4 Format of Encrypted Data...................................7
4. Key Derivation.................................................8
Security Considerations...........................................9
References........................................................9
Acknowledgments..................................................10
Author's Addresses...............................................10
1. Introduction
The EAP-TLV [1] mechanism provides a way to carry various types of
information in an EAP [2] conversation. For example it may be used
to carry protected result indications, secret credential information,
or channel binding information. It is often desirable to protect the
integrity and privacy of this information. This method must be
chained after a previous EAP Authentication exchange that established
an extended master session key, defined in [6] which can be used to
derive a key hierarchy of additional keys. This document describes
the derivation of a portion of the key hierarchy to protect
additional messages, the format of a protected TLV and the
cryptographic operations used to protect and verify the TLV.
Protected TLVs must be chained after an authentication mechanism that
generates key material. A mechanism for the generic chaining of EAP-
TLVs after EAP methods is yet to be defined. Protected TLVs are an
important part of this framework.
1.1 Terminology
EAP Application
A consumer of EAP keying material. Examples include link layer
encryption or a protected EAP-TLV.
Master Session Key (MSK)
Keying material exported by an EAP method for the purpose of link
layer ciphering.
Extended Master Session Key (EMSK)
Keying material separate from the MSK that is not used for any
other purpose than the derivation of keys for various EAP
applications. It is defined in [6].
Salowey Expires - December 2003 [Page 2]
Protected EAP TLV June 2003
Application Master Session Key (AMSK)
Keying material used to derive ciphering keys (encryption and MAC)
for the application in an application specific way.
1.2 Uses
Protected TLVs can be used to add the following features to a wide
variety of EAP mechanisms:
. Protected Acknowledged Success and Failure
An EAP-TLV message with a MAC-TLV can be used to authenticate
the success and in some cases the failure of a mechanism.
. Channel Binding
An EAP-TLV message with a MAC-TLV can be used to communicate
channel binding information such as the MAC addresses of the
802.1x supplicant and authenticator.
. Credential Distribution
An Encrypted TLV main contain credentials that can optimize re-
authentication.
2. Message protection and validation
EAP TLV message authentication is provided by the MAC-TLV, encryption
is provided in the Encrypted-TLV and sequencing is protected by the
SeqNo-TLV. This document defines one cipher and one message
authentication code that must be supported by all implementations:
AES-128 and HMAC-SHA1-128.
Verification involves verifying a sequence number, verifying a MAC
covering the entire protected TLV packet and decrypting the data.
The sequence number is incremented for each message. The exception
to this is re-transmissions in which case the sequence number is not
incremented. If a duplicate or out of order sequence number is
received verification fails and the message is dropped. If the
message MAC validation fails it is also silently dropped.
Every EAP-TLV message that contains a MAC-TLV SHOULD contain a SeqNo-
TLV and every EAP-TLV message that contains an Encrypted TLV SHOULD
contain a MAC-TLV. The MAC-TLV and SeqNo-TLV MAY be omitted if the
Encrypted-TLV uses a mode that provides both message authentication
and sequence protection.
Salowey Expires - December 2003 [Page 3]
Protected EAP TLV June 2003
2.1 AES-128-CBC with HMAC-SHA1-128
First a 128 bit initialization vector (IV) is generated. The IV is
used to along with the encryption key to initialize the AES 128 [4]
cipher in CBC [5]. The encryption key is derived as described in
section 4. The encapsulated TLVs are padded with 0 to a 16 byte
boundary and then encrypted using the cipher. The MAC is calculated
use HMAC-SHA1-128 [3] over the entire EAP-TLV message including
header, unencrypted TLVs such as seqNo-TLV and the encrypted TLV and
the MAC field set to 0.
During validation first the sequence number is checked. If it is a
duplicate or out of sequence message the receiver drops it. Next the
MAC is verified, if the verification fails then the message is
dropped. Finally the TLV is decrypted and the unencrypted TLV
processed.
3. Protected TLV formats
In the following formats bits are transmitted from left to right.
3.1 SeqNo-TLV
The format of a MAC-TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| SeqNo-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
The mandatory bit is always set since the receiver must be able to
verify and decode the packet in order to find out the actual
contents, which may in fact be optional.
R
Reserved, set to 0
Type
(TBD) SeqNo-TLV
Salowey Expires - December 2003 [Page 4]
Protected EAP TLV June 2003
Length
4
Sequence Number
The sequence number starts at 0 for the first protected TLV sent
and is incremented for each subsequent protected TLV. Sequence
numbers must not be repeated.
3.2 MAC-TLV
The format of a MAC-TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| MAC-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
The mandatory bit is always set since the receiver must be able to
verify and decode the packet in order to find out the actual
contents, which may in fact be optional.
R
Reserved, set to 0
Type
(TBD) MAC TLV
Length
4 + MAC Length
MAC Type
Salowey Expires - December 2003 [Page 5]
Protected EAP TLV June 2003
Message authentication algorithm in use.
(0x0001) HMAC-SHA1-128
Reserved
Set to 0
MAC Data
MAC of fixed length depending on the MAC Type. The MAC is
calculated over the entire EAP-TLV message with a zeroed out MAC
field. This includes the header, unencrypted TLVs such as sequence
number, and the encrypted TLV. The MAC is treated as a bit string,
most significant bit first.
For HMAC-SHA1-128 the MAC is 16 bytes (128 bits).
3.3 Encrypted-TLV
The format of a Encrypted-TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| Protected TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IV |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted Data... .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
The mandatory bit is always set since the receiver must be able to
verify and decode the packet in order to find out the actual
contents, which may in fact be optional.
Salowey Expires - December 2003 [Page 6]
Protected EAP TLV June 2003
R
Reserved, set to 0
Type
(TBD) Encrypted TLV
Length
4 + IV Length + Encrypted Data Length
Cipher
Encryption algorithm in use
(0x0001) AES-128-CBC
Reserved
Set to 0
IV
The IV is an Octet string of random bits, most significant bit
first. For AES-128 the IV is 16 bytes (128 bits).
Encrypted Data
Encrypted TLV of variable length. The encrypted data consists of
one or more plaintext TLVs. The format of the encrypted data is
described in section 3.4.
3.4 Format of Encrypted Data
The format of the encrypted data is one or more encrypted TLVs plus 0
padding if required. AES-128 requires padding to a 16 byte boundary.
Salowey Expires - December 2003 [Page 7]
Protected EAP TLV June 2003
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TLV (First TLV) |
| |
. .
. .
. .
| |
| TLV (More TLVs) |
. .
. .
. .
| TLV (Last TLV) |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 0 Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV
One or more TLVs to be encrypted
0 Padding
0 are appended to the value to pad the TLV to cipher block size if
required.
4. Key Derivation
Keys are needed for cryptographic message protection. Keys are
obtained from EAP authentication methods completed before protected
TLVs are sent. A least one previous EAP method must have generated a
extended master session key (EMSK) for application use with the
required amount of entropy. The application master session key (AMSK)
for Protected EAP TLV is derived according to EAP Key Derivation for
multiple applications described in [6].
The key label used for protected TLV is
"Protected EAP TLV Master Session Key"
No application specific data is used in deriving the key. For AES-
128-HMAC-SHA1-128 the AMSK should be 128 bits. The AMSK is then used
to derive the encryption and MAC keys as follows:
Salowey Expires - December 2003 [Page 8]
Protected EAP TLV June 2003
Encryption Key = HMAC-SHA1 (PMK,"protected TLV encryption key" +
cipher number)
MAC Key = HMAC-SHA1 (PMK,"protected TLV authentication key" + MAC
type number)
For AES-128 and HMAC-SHA1-128 the keys are truncated to 128 bits.
If more than one previous authentication method has generated a key
they are combined in a method described in [6].
These keys are derived locally and not exported out side the EAP Peer
or Authenticator.
Security Considerations
The keys used in the message protection rely upon keys generated by
previous EAP authentication mechanism in the same session. One of
the mechanisms must generate a key with the required key strength.
For AES-128 and HMAC-SHA1-128 the required key strength is 128 bits.
A different key must be derived for each new EAP session.
The key derivation for Protected EAP-TLV makes use of the key
derivation in [6]. It should be noted that the keys derived for this
purpose should not be exported outside of the EAP Peer or
Authenticator as they are not needed elsewhere. In addition the
master session key used in deriving these keys should not be exported
since that would result in the same effect as exporting the keys
themselves.
References
[1] Hiller, Palekar, and Zorn "A Container Type for the Extensible
Authentication Protocol (EAP)", draft-hiller-eap-tlv-00.txt, work-in-
progress, October 2002 (NORMATIVE)
[2] L. Blunk, J. Vollbrecht, B. Aboba, "Extensible Authentication
Protocol (EAP)", draft-ietf-pppext-rfc2284bis-04.txt, work-in-
progress, June 2003 (NORMATIVE)
[3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997 (NORMATIVE)
Salowey Expires - December 2003 [Page 9]
Protected EAP TLV June 2003
[4] Federal Information Processing Standard (FIPS) draft standard,
"Advanced Encryption Standard (AES)",
http://csrc.nist.gov/publications/drafts/dfips-AES.pdf, September
2001 (NORMATIVE)
[5] US National Bureau of Standards, "DES Modes of Operation",
Federal Information Processing Standard (FIPS) Publication 81,
December 1980 (NORMATIVE)
[6] P. Eronen and J. Salowey, "EAP Key Derivation for Multiple
Application", draft-salowey-eap-key-deriv-01.txt, work-in-progress,
June 2003 (NORMATIVE)
Acknowledgments
Thanks to Glen Zorn for several helpful comments.
Author's Addresses
Joseph Salowey
Cisco Systems
2901 Third Avenue
Seattle, WA 98121
US
E-mail: jsalowey@cisco.com
Phone: +1 206 256 3380
Salowey Expires - December 2003 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 01:13:42 |