One document matched: draft-salowey-eap-protectedtlv-01.txt
Differences from draft-salowey-eap-protectedtlv-00.txt
Network Working Group
Internet Draft J. Salowey
Document:draft-salowey-eap-protectedtlv-01.txt Cisco Systems
Expires: September 2003 March 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 a TLV type that uses 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.
Table of Contents
1. Introduction...................................................2
2. Message protection and validation..............................3
2.1 AES-128-HMAC-SHA1-128......................................3
3. Protected TLV format...........................................3
3.1 Format of Encrypted Data...................................5
4. Key Derivation.................................................6
Salowey Expires - September 2003 [Page 1]
Protected EAP TLV March 2003
Security Considerations...........................................7
References........................................................7
Acknowledgments...................................................8
Author's Addresses................................................8
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 authorization data or status indication. 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.
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.
Extended Master Session Key (EMSK)
Keying material taken from a specific portion of the MSK that is
not used for any other purpose than the derivation of keys for
various EAP applications. It is defined in [6]. Usually bytes 64..N
of MSK.
Application Master Session Key (AMSK)
Keying material used to derive ciphering keys (encryption and MAC)
for the application in an application specific way.
Salowey Expires - September 2003 [Page 2]
Protected EAP TLV March 2003
2. Message protection and validation
In general the method for protecting TLVs is defined by various
cipher suites. This document defines one cipher suite that must be
supported by all implementations: AES-128 with HMAC-SHA1-128. The
protected message also contains a sequence number to be used for
replay detection. The message format is described in section 3.
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.
2.1 AES-128 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 TLV is 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 protected TLV header, IV, 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 format
In the following formats bits are transmitted from left to right.
The format of a protected TLV is as follows:
Salowey Expires - September 2003 [Page 3]
Protected EAP TLV March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| Protected TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher | Seq No | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IV |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted Data... .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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) Encrypted TLV
Length
4 + IV Length + Encrypted Data Length + MAC Length
Cipher
Cipher suite in use, defines both message authentication and
encryption algorithms
(0x0001) AES-128 with HMAC-SHA1-128
SeqNo
Salowey Expires - September 2003 [Page 4]
Protected EAP TLV March 2003
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.
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 is the
encapsulated protected TLV. The format of the encrypted data is
described in section 3.1.
MAC Data
MAC of fixed length depending on Cipher suite in use. The MAC is
calculated over the all above fields and a zeroed out MAC field.
The MAC is treated as a bit string, most significant bit first.
This includes the header fields such as type, length, cipher and
sequence number as well as the encrypted data and IV.
For HMAC-SHA1-128 the MAC is 16 bytes (128 bits).
3.1 Format of Encrypted Data
The format of the encrypted data is the unprotected TLV plus 0
padding if required. AES-128 requires padding to a 16 byte boundary.
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| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 0 Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 if Mandatory (See [2])
Salowey Expires - September 2003 [Page 5]
Protected EAP TLV March 2003
R
Reserved, set to 0 (see [2])
TLV Type
Type of TLV (see [2])
Length
Length of TLV (see [2])
Value
TLV value (see [2])
0 Padding
0 are appended to the value to pad the TLV to multiple of 16
bytes.
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:
Encryption Key = HMAC-SHA1 (PMK,"protected TLV encryption key" +
ciphersuite number)
MAC Key = HMAC-SHA1 (PMK,"protected TLV authentication key" +
ciphersuite number)
For AES-128-HMAC-SHA1-128 the keys are truncated to 128 bits.
Salowey Expires - September 2003 [Page 6]
Protected EAP TLV March 2003
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-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-07.txt, work-in-
progress, October 2002 (NORMATIVE)
[3] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997 (NORMATIVE)
[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)
Salowey Expires - September 2003 [Page 7]
Protected EAP TLV March 2003
[6] P. Eronen and J. Salowey, "EAP Key Derivation for Multiple
Application", draft-salowey-eap-key-deriv-00.txt, work-in-progress,
February 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 - September 2003 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 01:13:01 |