| [Issue 277] key draft re-organization strawman | <– Date –> <– Thread –> |
From: Joseph Salowey (jsalowey cisco.com)
|
|
| Date: Tue, 9 Nov 2004 21:32:46 -0500 (EST) | |
Attached is a strawman for a reorganization of the keying draft. This only covers the initial section about general requirements associated with EAP and keying. Joe
Network Working Group J. Salowey
Internet-Draft Cisco Systems
Expires: May 10, 2005 November 9, 2004
EAP Method Keying Requirements
draft-jsalowey-eap-key
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo defines requirements for the keying material exported from
EAP methods. It contains recommendations for key generation, key
export, key naming, key derivation for applications and key lifecycle
management.
Salowey Expires May 10, 2005 [Page 1]
Internet-Draft EAP Method Keying Requirements November 2004
Table of Contents
1. Expected behavior of EAP Methods and Frameworks . . . . . . . 3
1.1 Generation of key material . . . . . . . . . . . . . . . . 3
1.2 Exported Key Material . . . . . . . . . . . . . . . . . . 3
1.3 AMSK Derivation . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Key Derivation Function . . . . . . . . . . . . . . . 4
1.3.2 HMAC-SHA1 derivation . . . . . . . . . . . . . . . . . 4
1.4 Naming and Identification . . . . . . . . . . . . . . . . 5
1.5 Key Lifetime . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Key Request Considerations . . . . . . . . . . . . . . . . 6
2. Security Considerations . . . . . . . . . . . . . . . . . . . 6
3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Salowey Expires May 10, 2005 [Page 2]
Internet-Draft EAP Method Keying Requirements November 2004
1. Expected behavior of EAP Methods and Frameworks
This section defines the external behavior of and EAP method and
framework. RFC 3748 [RFC3748] specifies that EAP methods may
generate and export key material. This document defines requirements
expectations around how the key material is derived and how its use
is coordinated between different consumers.
1.1 Generation of key material
RFC 3748 [RFC3748] requires that EAP methods that generate keys MUST
generate two quantities at least 64 bytes in length called the MSK
and the EMSK. In addition to the requirements defined in RFC 3748
this document specifies some additional requirements for the
generation of keying material:
o If a method specification does not define the length of these
quantities it MUST generate and EMSK and an MSK of 64 bytes. If a
method specification supports other key lengths then it MUST
ensure that both the EAP peer and EAP server derive keys of the
same length.
o It MUST be computationally infeasible to derive keys used
internally to the EAP method from the MSK or the EMSK.
o It MUST be computationally infeasible to derive the MSK from the
EMSK or vice versa.
1.2 Exported Key Material
EAP methods export two types of keying material; the MSK and the
EMSK. The MSK has traditionally been used to derive the AAA-Key
which has been used in lower layer cryptographic data protection.
This document updates RFC 3748 and specifies a way that EMSK and MSK
usage can be coordinated. Requirements on the usage of the MSK and
EMSK are listed below.
o The EMSK MSUT be maintained within the EAP server. Only keys
(AMSKs) derived according to this specification may be exported
from the EAP server.
o The application MAY use the MSK transmitted to the NAS in any way
it chooses. This is required for backward compatibility. New
applications following this specification SHOULD NOT use the MSK.
If more than one application uses the MSK, then the cryptographic
separation is not achieved. Implementations SHOULD prevent such
combinations.
Salowey Expires May 10, 2005 [Page 3]
o The application or EAP Server MUST NOT use the EMSK in any other
way except to derive Application Master Session Keys (AMSK) using
the key derivation specified in section 3 this document. It MUST
NOT use the EMSK directly.
o Applications MUST define distinct key labels and application
specific data used in the key derivation described in section 3.
o Applications MUST define how they use their AMSK to derive TSKs
for their use.
1.3 AMSK Derivation
Application master session keys (AMSK) are derived from the EMSK for
use in different applications. Since it is possible that more than
one application will require key material it is necessary to
coordinate the derivation of key material from the EMSK. A EAP
method MAY specify a key derivation function for use in deriving
keys. If a method does not specify a key derivation function then it
MUST use HMAC-SHA1 derivation specified in this document. If an EAP
method specifies a different KDF then it must be selected from the
list of EAP key derivation algorithms maintained by the IANA registry
specified in this document.
1.3.1 Key Derivation Function
The EAP EMSK usage guidelines AMSK key derivation function (KDF)
derives an AMSK from the Extended Master Session Key (EMSK) described
above, an application key label, optional application data, and
output length.
AMSK = KDF(EMSK, key label, optional application data, length)
The key labels are printable ASCII strings unique for each
application (see Section 5 for IANA Considerations).
Additional ciphering keys (TSKs) can be derived from the AMSK using
an application specific key derivation mechanism. In many cases,
this AMSK toTSK derivation can simply split the AMSK to pieces of
correct length. In particular, it is not necessary to use a
cryptographic one-way function. Note that the length of the AMSK
must be specified by the application.
1.3.2 HMAC-SHA1 derivation
The EAP key derivation function is taken from the PRF+ key expansion
PRF from [IKEv2]. This KDF takes 4 parameters as input: secret,
label, application data, and output length. It is only defined for
255 iterations so it may produce up to 5100 bytes of key material.
Salowey Expires May 10, 2005 [Page 4]
Internet-Draft EAP Method Keying Requirements November 2004
For the purposes of this specification the secret is taken as the
EMSK, the label is the key label described above concatenated with a
NUL byte, the application data is also described above and the output
length is two bytes. The application data is optional and may not be
used by some applications. The KDF is based on HMAC-SHA1 [RFC2104]
[SHA1]. For this specification we have:
KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...
where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
prf = HMAC-SHA1
K = EMSK
L = key label
D = application data
O = OutputLength (2 bytes)
S = L | "\0" | D | O
The prf+ construction was chosen because of its simplicity and
efficiency over other PRFs such as those used in [TLS]. The
motivation for the design of this PRF is described in [SIGMA].
The NUL byte after the key label is used to avoid collisions if one
key label is a prefix of another label (e.g. "foobar" and
"foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from
occurring.
1.4 Naming and Identification
EAP methods MUST provide a means to identify a particular instance of
an execution of the method. To do this an EAP method should export a
method identifier. This identifier consists of 8 bytes that identify
the EAP method followed by 20 bytes which are extracted from the EAP
method operation which uniquely identify the instance of the method.
It is RECOMMENDED that this quantity be derived from the following
values where they are available: EAP peer name, EAP server name, and
nonces exchanged during the method execution. The name must not
reveal any secret information internal to the EAP method or any
information that could lead to the disclosure of the MSK or EMSK.
Names for the MSK and AMSK SHOULD be derived from this name.
Salowey Expires May 10, 2005 [Page 5]
Internet-Draft EAP Method Keying Requirements November 2004
1.5 Key Lifetime
The MSK SHOULD be deleted after it is transported out of the EAP
server. The EMSK SHOULD be deleted after all required AMSKs are
derived from it. Ideally, the requsts for AMSKs SHOULD occur
simultaneously with the completion of the EAP method. In cases where
this is not possible the request should be made shortly after the
completion of the EAP method as possible.
1.6 Key Request Considerations
2. Security Considerations
3 References
[RFC3748] "".
Author's Address
Joseph Salowey
Cisco Systems
2901 3rd Ave
Seattle, WA 98121
US
EMail: jsalowey [at] cisco.com
Salowey Expires May 10, 2005 [Page 6]
Internet-Draft EAP Method Keying Requirements November 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr [at] ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Salowey Expires May 10, 2005 [Page 7]
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc ipr="full3667" docName="draft-jsalowey-eap-key">
<front>
<title >EAP Method Keying Requirements</title>
<author initials = "J" surname = "Salowey" fullname = "Joseph
Salowey">
<organization abbrev = "">Cisco Systems</organization>
<address>
<postal>
<street>2901 3rd Ave</street>
<city>Seattle</city>
<country>US</country>
<code>98121</code>
<region>WA</region>
</postal>
<email>jsalowey [at] cisco.com</email>
</address>
</author>
<date month="November" year="2004" />
<workgroup>Network Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract><t>This memo defines requirements for the keying material exported
from EAP methods. It contains recommendations for key generation, key export,
key naming, key derivation for applications and key lifecycle management.
</t></abstract>
</front>
<middle>
<section title="Expected behavior of EAP Methods and Frameworks">
<t>This section defines the external behavior of and EAP method and framework.
<xref target="RFC3748">RFC 3748</xref> specifies that EAP methods may generate
and export key material. This document defines requirements expectations around
how the key material is derived and how its use is coordinated between
different consumers.
</t>
<section title="Generation of key material">
<t><xref target="RFC3748">RFC 3748</xref> requires that EAP methods that
generate keys MUST generate two quantities at least 64 bytes in length called
the MSK and the EMSK. In addition to the requirements defined in RFC 3748 this
document specifies some additional requirements for the generation of keying
material:
<vspace blankLines="1"></vspace>
<list style="symbols">
<t>
If a method specification does not define the length of these quantities it
MUST generate and EMSK and an MSK of 64 bytes. If a method specification
supports other key lengths then it MUST ensure that both the EAP peer and EAP
server derive keys of the same length.
<vspace blankLines="1"></vspace> </t>
<t>
It MUST be computationally infeasible to derive keys used internally to the EAP
method from the MSK or the EMSK.
<vspace blankLines="1"></vspace> </t>
<t>
It MUST be computationally infeasible to derive the MSK from the EMSK or vice
versa.
<vspace blankLines="1"></vspace> </t>
</list>
</t>
</section>
<section title="Exported Key Material">
<t>EAP methods export two types of keying material; the MSK and the EMSK. The
MSK has traditionally been used to derive the AAA-Key which has been used in
lower layer cryptographic data protection. This document updates RFC 3748 and
specifies a way that EMSK and MSK usage can be coordinated. Requirements on
the usage of the MSK and EMSK are listed below.
<vspace blankLines="1"></vspace>
<list style="symbols">
<t>The EMSK MSUT be maintained within the EAP server. Only keys
(AMSKs) derived according to this specification may be exported from the EAP
server.
<vspace blankLines="1"></vspace></t>
<t>The application MAY use the MSK transmitted to the NAS in any way it
chooses. This is required for backward compatibility. New applications
following this specification SHOULD NOT use the MSK. If more than one
application uses the MSK, then the cryptographic separation is not achieved.
Implementations SHOULD prevent such combinations. <vspace blankLines="1"
></vspace> </t>
<t>The application or EAP Server MUST NOT use the EMSK in any other way
except to derive Application Master Session Keys (AMSK) using the key
derivation specified in section 3 this document. It MUST NOT use the EMSK
directly.<vspace blankLines="1" ></vspace> </t>
<t>Applications MUST define distinct key labels and application
specific data used in the key derivation described in section 3.
<vspace blankLines="1"></vspace> </t>
<t>Applications MUST define how they use their AMSK to derive TSKs for
their use.</t>
</list>
</t>
</section>
<section title="AMSK Derivation">
<t>Application master session keys (AMSK) are derived from the EMSK for use in
different applications. Since it is possible that more than one application
will require key material it is necessary to coordinate the derivation of key
material from the EMSK. A EAP method MAY specify a key derivation function for
use in deriving keys. If a method does not specify a key derivation function
then it MUST use HMAC-SHA1 derivation specified in this document. If an EAP
method specifies a different KDF then it must be selected from the list of EAP
key derivation algorithms maintained by the IANA registry specified in this
document. </t>
<section title="Key Derivation Function">
<t>
The EAP EMSK usage guidelines AMSK key derivation function (KDF)
derives an AMSK from the Extended Master Session Key (EMSK) described
above, an application key label, optional application data, and
output length.
<vspace blankLines="1" ></vspace>
<list style="hanging">
<t> AMSK = KDF(EMSK, key label, optional application data, length) </t>
</list>
<vspace blankLines="1" ></vspace>
The key labels are printable ASCII strings unique for each
application (see Section 5 for IANA Considerations).
</t>
<t>
Additional ciphering keys (TSKs) can be derived from the AMSK using
an application specific key derivation mechanism. In many cases, this
AMSK toTSK derivation can simply split the AMSK to pieces of correct
length. In particular, it is not necessary to use a cryptographic
one-way function. Note that the length of the AMSK must be specified
by the application.
</t>
</section>
<section title="HMAC-SHA1 derivation">
<t>The EAP key derivation function is taken from the PRF+ key expansion
PRF from [IKEv2]. This KDF takes 4 parameters as input: secret,
label, application data, and output length. It is only defined for
255 iterations so it may produce up to 5100 bytes of key material.
</t>
<t>
For the purposes of this specification the secret is taken as the
EMSK, the label is the key label described above concatenated with a
NUL byte, the application data is also described above and the output
length is two bytes. The application data is optional and may not be
used by some applications. The KDF is based on HMAC-SHA1 [RFC2104]
[SHA1]. For this specification we have:
</t>
<figure>
<preamble >
KDF (K,L,D,O) = T1 | T2 | T3 | T4 | ...
</preamble>
<artwork >
where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)
prf = HMAC-SHA1
K = EMSK
L = key label
D = application data
O = OutputLength (2 bytes)
S = L | "\0" | D | O
</artwork>
</figure>
<t>
The prf+ construction was chosen because of its simplicity and
efficiency over other PRFs such as those used in [TLS]. The
motivation for the design of this PRF is described in [SIGMA].
</t><t>
The NUL byte after the key label is used to avoid collisions if one
key label is a prefix of another label (e.g. "foobar" and
"foobarExtendedV2"). This is considered a simpler solution than
requiring a key label assignment policy that prevents prefixes from
occurring.
</t>
</section>
</section>
<section title="Naming and Identification">
<t>
EAP methods MUST provide a means to identify a particular instance of an
execution of the method. To do this an EAP method should export a method
identifier. This identifier consists of 8 bytes that identify the EAP method
followed by 20 bytes which are extracted from the EAP method operation which
uniquely identify the instance of the method. It is RECOMMENDED that this
quantity be derived from the following values where they are available: EAP
peer name, EAP server name, and nonces exchanged during the method execution.
The name must not reveal any secret information internal to the EAP method or
any information that could lead to the disclosure of the MSK or EMSK. Names
for the MSK and AMSK SHOULD be derived from this name.
</t>
<t></t>
</section>
<section title="Key Lifetime">
<t>The MSK SHOULD be deleted after it is transported out of the EAP server.
The EMSK SHOULD be deleted after all required AMSKs are derived from it.
Ideally, the requsts for AMSKs SHOULD occur simultaneously with the completion
of the EAP method. In cases where this is not possible the request should be
made shortly after the completion of the EAP method as possible.</t>
</section>
<section title="Key Request Considerations">
<t></t>
</section>
</section>
<section title="Security Considerations">
</section>
</middle>
<back>
<references>
<reference anchor="RFC3748">
<front>
<title></title>
<author>
<organization></organization>
</author>
<date year=""></date>
</front>
</reference>
</references>
</back>
</rfc>
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.