One document matched: draft-zorn-radius-keywrap-15.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v2004 rel. 3 U (http://www.xmlspy.com) by Glen Zorn (Cisco Systems) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2548 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2548.xml'>
<!ENTITY rfc3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY rfc2865 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
<!ENTITY rfc2866 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2866.xml'>
<!ENTITY rfc2868 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2868.xml'>
<!ENTITY rfc3078 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3078.xml'>
<!ENTITY rfc1321 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1321.xml'>
<!ENTITY rfc4086 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml'>
<!ENTITY rfc2104 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3394 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3394.xml'>
<!ENTITY rfc3575 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3575.xml'>
<!ENTITY rfc5176 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5176.xml'>
<!ENTITY rfc3579 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml'>
<!ENTITY rfc2434 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml'>
<!ENTITY rfc4231 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4231.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="compact" ?>
<!--
<rfc category="info" ipr="full3978" updates="2865, 2866, 3576, 3579" docName="draft-zorn-radius-keywrap-14.txt">
-->
<rfc category="info" ipr="pre5378Trust200902" docName="draft-zorn-radius-keywrap-15.txt">
<front>
<title abbrev="RADIUS Keying Material Transfer VSA"> Vendor Specific RADIUS Attributes for the Delivery of Keying Material</title>
<author fullname="Glen Zorn" initials="G.Z.." surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>1463 East Republican Street </street>
<street>#358</street>
<city>Seattle</city>
<region>WA</region>
<code>98112</code>
<country>US</country>
</postal>
<email>gwz@net-zen.net</email>
</address>
</author>
<author initials="T." surname="Zhang" fullname="Tiebing Zhang">
<organization>Advista Technologies</organization>
<address>
<postal>
<street>5252 Orange Ave, Suite 108</street>
<city>Cypress</city>
<region>CA</region>
<code>90630</code>
<country>US</country>
</postal>
<phone>+1 (949) 242 0391</phone>
<email>tzhang@advistatech.com</email>
</address>
</author>
<author initials="J." surname="Walker" fullname="Jesse Walker">
<organization>Intel Corporation</organization>
<address>
<postal>
<street>JF3-206</street>
<street>2111 N.E. 25th Ave</street>
<city>Hillsboro</city>
<region>OR</region>
<code>97214-5961</code>
<country>US</country>
</postal>
<phone>+1 (503) 712-1849</phone>
<email>jesse.walker@intel.com</email>
</address>
</author>
<author initials="J." surname="Salowey" fullname="Joseph Salowey">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>2901 Third Avenue</street>
<street>SEA1/6/</street>
<city>Seattle</city>
<region>WA</region>
<code>98121</code>
<country>US</country>
</postal>
<phone>+1 (206) 256-3380</phone>
<email>jsalowey@cisco.com</email>
</address>
</author>
<date year="2010"/>
<keyword>RADIUS</keyword>
<keyword>Security</keyword>
<abstract>
<t>
This document defines a set of RADIUS Attributes designed to allow both
the secure transmission of cryptographic keying material and strong authentication of any RADIUS message.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Many remote access deployments
(for example, deployments utilizing wireless LAN technology)
require the secure
transmission of cryptographic keying material from a RADIUS <xref target="RFC2865"/> server to
a network access point. Typically, this material is produced as a by-product of an EAP <xref target="RFC3748"/> authentication
and is of a form that may be used in virtually any cryptographic algorithm after appropriate processing.
<!--
Currently, this transfer is most often accomplished using vendor-specific RADIUS attributes
<xref target="RFC2548"/>, with the integrity of the message protected by the RADIUS Response Authenticator
<xref target="RFC2865"/>, the Request and Response Authenticators (in the cases of RADIUS Accounting
<xref target="RFC2866"/> and Dynamic Authorization <xref target="RFC3576"/>)
or the Message-Authenticator Attribute <xref target="RFC3579"/>.
However, there are several issues with these techniques:
<list style="symbols">
<t>The key transport attributes were designed for use with a specific, proprietary protocol
<xref target="RFC3078"/> and may be inappropriate for other uses
</t>
<t>The security properties and strength of the encryption method used to hide the keys are unknown
</t>
<t>The hash function (<xref target="RFC1321"/>) used
in the construction of the Response Authenticator is proprietary and the construct itself
is weaker than more modern methods (e.g., HMAC <xref target="RFC2104"/>)
</t>
<t>The Message-Authenticator Attribute is unusable in some situations where strong
message authentication might be required</t>
</list>
-->
</t>
<t>
This document defines a set of RADIUS Attributes that can be used to securely transfer cryptographic keying material
using
standard techniques with well understood security properties.
In addition, the Message-Authentication-Code Attribute may be used to provide strong
authentication for any RADIUS message, including
those used for accounting and dynamic authorization.
</t>
<t>
Discussion of this draft may be directed to the authors.
</t>
</section>
<section title="Specification of Requirements">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.
</t>
</section>
<section title="Attributes">
<t>
The following subsections describe sub-attributes which are transmitted in one or more RADIUS attributes of type Vendor-Specific <xref target="RFC2865" />. The Vendor-ID field of the Vendor-Specific Attribute(s) MUST be set to decimal 9 (Cisco). The general format of the attributes is: </t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="empty">
<t>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
26 for vendor specific
</t>
<t hangText="Length">
<vspace blankLines="1"/>
Length of entire attribute including type and length field
</t>
<t hangText="Vendor ID">
<vspace blankLines="1"/>
4 octets encoding the Cisco Vendor ID of 9
</t>
<t hangText="Sub-type">
<vspace blankLines="1"/>
Attribute sub-type of 1
</t>
<t hangText="Sub-length">
<vspace blankLines="1"/>
Length of the sub attribute including the sub-type and sub-length fields
</t>
<t hangText="Value">
<vspace blankLines="1"/>
Value of the sub attribute.
</t>
</list>
</t>
</list>
</t>
<t></t>
<t>This specification concerns the following sub-attributes:
<list style="symbols">
<t>Keying-Material</t>
<t>MAC-Randomizer</t>
<t>Message-Authentication-Code</t>
</list>
</t>
<t></t>
<section title="Keying-Material">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
This Attribute MAY be used
to transfer cryptographic keying material from a RADIUS server to a client.
<vspace blankLines="1"/>
It MAY be sent in request messages (e.g., Access-Request, etc.),
as well; if the Keying-Material Attribute is present in a request,
it SHOULD be
taken as a hint by the server that the client prefers this method of key delivery over others,
the server is not obligated to honor the hint, however.
When the Keying-Material Attribute is included in a request message the Key ID,
Lifetime, IV and Key Material
fields MAY be omitted.
<vspace blankLines="1"/>
If the client requires the use of the Keying-Material Attribute
for keying material delivery and it is not present in the Access-Accept or Access-Challenge message,
the client MAY ignore the message in question and end the user session.
<vspace blankLines="1"/>
Any packet
that contains a Keying-Material Attribute MUST also include the Message-Authentication-Code Attribute.
<vspace blankLines="1"/>
Any packet that contains an instance of the Keying-Material Attribute MUST NOT contain an instance of any other
attribute (e.g., MS-CHAP-MPPE-Keys <xref target="RFC2548"/>, Tunnel-Password <xref target="RFC2868"/>, etc.)
encapsulating identical keying material.
<vspace blankLines="1"/>
The Keying-Material Attribute MUST NOT be used to transfer long-lived keys (i.e., passwords)
between RADIUS servers and clients.
<vspace blankLines="1"/>
A summary of the Keying-Material attribute format is shown below. The fields are transmitted from left to right.
</t>
</list>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:app-key=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) | Enc Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEK ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KM ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IV (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="empty">
<t>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
26 for vendor specific
</t>
<t hangText="Length">
<vspace blankLines="1"/>
Length of entire attribute including type and length field
</t>
<t hangText="Vendor ID">
<vspace blankLines="1"/>
4 octets encoding the Cisco Vendor ID of 9
</t>
<t hangText="Sub-type">
<vspace blankLines="1"/>
Attribute sub-type of 1
</t>
<t hangText="Sub-length">
<vspace blankLines="1"/>
Length of the sub attribute including the sub-type and sub-length fields
</t>
<t hangText="String-ID">
<vspace blankLines="1"/>
The ASCII characters "radius:app-key=" without quotes or null termination.
</t>
<t hangText="Enc Type">
<vspace blankLines="1"/>
The Enc Type field indicates the method used to encrypt the contents of the Data field.
This document defines only one value (decimal) for this field:
<list>
<t>
0 AES Key Wrap with 128-bit KEK <xref target="RFC3394"/>
</t>
</list>
Implementations MUST support Enc Type 0 (AES Key Wrap with 128-bit KEK).
<list style="hanging">
<t hangText="Implementation Note">
<vspace blankLines="1"/>
A shared secret is used as the key-encrypting-key (KEK)
for the AES key wrap algorithm.
Implementations SHOULD provide a means to provision a key
(cryptographically separate from the normal RADIUS shared secret)
to be used exclusively as a KEK.
</t>
</list>
</t>
<t hangText="App ID">
<vspace blankLines="1"/>
The App ID field is 4 octets in length and identifies the type of application
for which the key material is to be used. This allows for multiple keys for different purposes to be present in the same message.
This document defines two values for the App ID:
<list>
<t>
0 Unspecified
</t><t>
1 EAP MSK
</t>
</list>
further specification of the content of this field is outside the scope
of this document.
</t>
<t hangText="KEK ID">
<vspace blankLines="1"/>
The KEK ID field is 16 octets in length and contains an identifier for the KEK.
The KEK ID MUST refer to an encryption key of a type and length appropriate
for use with the algorithm specified by the Enc Type field (see above). This key is used to protect the contents of
the Data field (below).
Further specification of the content of this field is outside the scope
of this document.
</t>
<t hangText="KM ID">
<vspace blankLines="1"/>
The KM ID field is 16 octets in length and contains an identifier for the contents of the Data field.
The KM ID MAY be used by communicating parties to identify the material being transmitted.
The combination of App ID and KM ID MUST uniquely identify the keying material between the parties utilizing it.
The KM ID is assumed to be known to the parties that derived the keying material. If the KM ID is not used it is set to 0.
Further specification of the content of this field is outside the scope
of this document.
</t>
<t hangText="Lifetime">
<vspace blankLines="1"/>
The Lifetime field is an integer <xref target="RFC2865"/> representing
the period of time (in seconds) for which the keying material is valid.
<vspace blankLines="1"/>
Note: Applications using this value SHOULD consider the beginning of
the lifetime to be
the point in time when the keying material is first used.
</t>
<t hangText="IV">
<vspace blankLines="1"/>
The length of the IV field depends upon the value of the Enc Type field,
but is fixed for any given value thereof.
When the value of the Enc Type field is 0 (decimal), the IV field MUST be
8 octets in length (as illustrated above) and the value of the IV
field MUST be as specified in <xref target="RFC3394"/>.
</t>
<t hangText="Data">
<vspace blankLines="1"/>
The Data field is variable length and contains the actual encrypted
keying material.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="MAC-Randomizer">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The MAC-Randomizer Attribute MUST be present
in any message that includes an instance of the Message-Authentication-Code Attribute.
The Random field MUST contain a 32 octet random number which
SHOULD satisfy the requirements of <xref target="RFC4086"/>.
<list>
<t hangText="Implementation Note">
<vspace blankLines="1"/>
The Random field MUST be filled in before the MAC is computed.
The MAC-Randomizer Attribute SHOULD be placed at the beginning of the RADIUS message if possible.</t>
</list>
A summary of the MAC-Randomizer attribute format is shown
below. The fields are transmitted from left to right.
</t>
</list>
</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:random-nonce=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="empty">
<t>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
26 for vendor specific
</t>
<t hangText="Length">
<vspace blankLines="1"/>
Length of entire attribute including type and length field
</t>
<t hangText="Vendor ID">
<vspace blankLines="1"/>
4 octets encoding the Cisco Vendor ID of 9
</t>
<t hangText="Sub-type">
<vspace blankLines="1"/>
Attribute sub-type of 1
</t>
<t hangText="Sub-length">
<vspace blankLines="1"/>
Length of the sub attribute including the sub-type and sub-length fields
</t>
<t hangText="String-ID">
<vspace blankLines="1"/>
The ASCII characters "radius:random-nonce=" without quotes or null termination.
</t>
<t hangText="Random">
<vspace blankLines="1"/>
This field MUST contain a 32 octet random number which SHOULD satisfy the requirements of
<xref target="RFC4086"/>.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Message-Authentication-Code">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
This Attribute MAY be used to "sign" messages to prevent
spoofing. If it is present in a request, the receiver should take this a hint that the sender
prefers the use of this Attribute for message authentication; the receiver is not obligated to do so, however.
<vspace blankLines="1"/>
The Message-Authentication-Code Attribute MUST be included
in any message
that contains a Keying-Material attribute.
<vspace blankLines="1"/>
Any packet that contains an instance of the Message-Authentication-Code Attribute SHOULD NOT contain an instance of the
Message-Authenticator Attribute <xref target="RFC3579"/>.
If both attributes are to be included in a message (e.g., for backward compatibility in a network containing both old and new clients),
the value of the
Message-Authentication-Code Attribute MUST be computed first.
<vspace blankLines="1"/>
If any message is received containing an instance of the Message-Authentication-Code Attribute,
the receiver MUST calculate the correct value
of the Message-Authentication-Code and silently discard the packet if the computed value
does not match the value received.
<vspace blankLines="1"/>
If a received message contains an instance of the MAC-Randomizer Attribute (Section 3.2),
the received MAC-Randomizer Attribute SHOULD
be included in the computation of the Message-Authentication-Code Attribute sent in the response, as described below.
<vspace blankLines="1"/>
A summary of the Message-Authentication-Code attribute format is shown
below. The fields are transmitted from left to right.
</t>
</list>
</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:message-authenticator-code=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) | MAC Type | MAC Key ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd) | MAC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (cont'd) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="empty">
<t>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
26 for vendor specific
</t>
<t hangText="Length">
<vspace blankLines="1"/>
Length of entire attribute including type and length field
</t>
<t hangText="Vendor ID">
<vspace blankLines="1"/>
4 octets encoding the Cisco Vendor ID of 9
</t>
<t hangText="Sub-type">
<vspace blankLines="1"/>
Attribute sub-type of 1
</t>
<t hangText="Sub-length">
<vspace blankLines="1"/>
Length of the sub attribute including the sub-type and sub-length fields
</t>
<t hangText="String-ID">
<vspace blankLines="1"/>
The ASCII characters "radius:message-authenticator-code=" without quotes or null termination.
</t>
<t hangText="MAC Type">
<vspace blankLines="1"/>
The MAC Type field specifies the algorithm used to create the
value in the MAC field. This document defines six values for the
MAC Type field:
<list>
<t>
0 HMAC-SHA-1 <xref target="FIPS.180-2.2002"/> <xref target="RFC2104"/>
</t>
<t>
1 HMAC-SHA-256 <xref target="FIPS.180-2.2002"/> <xref target="RFC4231"/>
</t>
<t>
2 HMAC-SHA-512 <xref target="FIPS.180-2.2002"/> <xref target="RFC4231"/>
</t>
<t>
3 CMAC-AES-128 <xref target="NIST.SP800-38B"/>
</t>
<t>
4 CMAC-AES-192 <xref target="NIST.SP800-38B"/>
</t>
<t>
5 CMAC-AES-256 <xref target="NIST.SP800-38B"/>
</t>
</list>
Implementations MUST support MAC Type 0 (HMAC-SHA-1).
</t>
<t hangText="MAC Key ID">
<vspace blankLines="1"/>
The MAC Key ID field is 16 octets in length and contains an identifier for the key.
The MAC Key ID MUST refer to a key of a type and length appropriate for use with the
algorithm specified by the MAC Type field (see above).
Further specification of the content of this field is outside the scope
of this document.
</t>
<t hangText="MAC">
<vspace blankLines="1"/>
Both the length and value of the MAC field depend upon the algorithm specified
by the value of the MAC Type field. If the algorithm specified is HMAC-SHA-1, HMAC-SHA-256 or HMAC-SHA-512, the MAC field MUST be 20,
32 or 64 octets in length, respectively.
If the algorithm specified is CMAC-AES-128, CMAC-AES-192 or CMAC-AES-256, the MAC field SHOULD be 64 octets in length.
The derivation of the MAC field value
for all the algorithms specified in this document is identical, except for the algorithm used.
There are differences, however, depending upon whether the MAC is being computed for a request message or
a response. These differences are detailed below, with the free variable HASH-ALG representing the actual algorithm used.
<list style="hanging">
<t hangText="Request Messages">
<vspace blankLines="1"/>
For requests (e.g., CoA-Request <xref target="RFC5176"/>, Accounting-Request <xref target="RFC2866"/>, etc.),
the value
of the MAC field is a hash of the entire packet
except the Request Authenticator in the header of the RADIUS packet,
using a shared secret as the key, as follows.
<list style="hanging">
<t hangText="MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes) where '+' represents concatenation"/>
</list>
The MAC-Randomizer Attribute (Section 3.2) MUST be included in any request in which the Message-Authentication-Code
Attribute is used.
The Random field of the MAC-Randomizer Attribute MUST be filled in before the value of the MAC field is computed.
<vspace blankLines="1"/>
If the Message-Authenticator-Code Attribute is included in a client request, the server SHOULD ignore the contents of
the Request Authenticator.
<list style="hanging">
<t hangText="Implementation Notes">
<vspace blankLines="1"/>
When the hash is calculated, both the MAC field of the Message-Authenticator-Code attribute
and the String field of the Message-Authenticator Attribute (if any) MUST be considered to be zero-filled.
<vspace blankLines="1"/>
Implementations SHOULD provide a means to provision a key
(cryptographically separate from the normal RADIUS shared secret)
to be used exclusively in the generation of the
Message-Authentication-Code. </t>
</list> </t>
<t hangText="Response Messages">
<vspace blankLines="1"/>
For responses (e.g., CoA-ACK <xref target="RFC5176"/>, Accounting-Response <xref target="RFC2866"/>, etc.),
the value
of the MAC field is a hash of the entire packet
except the Response Authenticator in the header of the RADIUS packet
using a shared secret as the key, as follows.
<list style="hanging">
<t hangText="MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes) where '+
' represents concatenation" />
</list>
If the request contained an instance of the MAC-Randomizer Attribute and the responder
wishes to include an instance of the Message-Authentication-Code Attribute in the corresponding
response,
then the MAC-Randomizer Attribute from the request MUST
be included in the response.
<vspace blankLines="1"/>
If the Message-Authenticator-Code Attribute is included in a server response, the client SHOULD ignore the contents of
the Response Authenticator.
<list style="hanging">
<t hangText="Implementation Notes">
<vspace blankLines="1"/>
When the hash is calculated, both the MAC field of the Message-Authenticator-Code attribute
and the String field of the Message-Authenticator Attribute (if any) MUST be considered to be zero-filled.
<vspace blankLines="1"/>
The Message-Authentication-Code Attribute MUST be created
and inserted in the packet
before the Response Authenticator is calculated.
<vspace blankLines="1"/>
Implementations SHOULD provide a means to provision a key
(cryptographically separate from the normal RADIUS shared secret)
to be used exclusively in the
generation of the Message-Authentication-Code.
</t>
</list>
</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="IANA Considerations">
<t>This document does not define any actions for IANA.</t>
<!-- This section explains the criteria to be used by the IANA for
assignment of numbers within namespaces defined within this document.
The "Specification Required" policy is used here with the meaning defined in BCP 26
<xref target="RFC2434"/>.
</t>
<section title="Attribute Values">
<t>
As defined in Section 3.1, numbers may need to be assigned for future values of the Enc Type
field of the Keying-Material attribute.
These numbers may be assigned by applying the "Specification Required" policy.
In particular, specifications MUST define the length of the IV field for the algorithm used.
</t>
<t>
As defined in Section 3.2, numbers may need to be assigned for future values of the MAC Type
field of the Message-Authentication-Code attribute.
These numbers may be assigned by applying the "Specification Required" policy.
</t>
<t>
As defined in Section 3.2, numbers may need to be assigned for future values of the App ID
field of the Keying-Material attribute.
These numbers may be assigned by applying the "First Come First Served" policy.
</t>
</section>
-->
</section>
<section title="Security Considerations">
<t>
It is RECOMMENDED in this memo that
two new keys, a key encrypting key and a message authentication key, be shared by the RADIUS client and server.
If implemented, these two keys MUST be different from each other
and SHOULD NOT be based on a password.
These two keys SHOULD be cryptographically
independent of the RADIUS shared secret used in
calculating the Response Authenticator <xref target="RFC2865"/>,
Request Authenticator <xref target="RFC2866"/> <xref target="RFC5176"/>
and Message-Authenticator Attribute <xref target="RFC3579"/>; otherwise if the shared secret is broken, all is lost.
<vspace blankLines="1"/>
To avoid the possibility of collisions, the same MAC key SHOULD NOT be used with more than 2^(n/2) messages, where 'n' is the length of the MAC value in octets.
<vspace blankLines="1"/>
If a packet that contains an instance of the Keying-Material Attribute also contains an instance of another, weaker key transport
attribute (e.g., MS-MPPE-Recv-Key <xref target="RFC2548"/>)
encapsulating identical keying material, then breaking the weaker attribute
might facilitate a known-plaintext attack against the KEK.
</t>
</section>
<section title="Contributors">
<t>
Hao Zhou, Nancy Cam-Winget, Alex Lam, Paul Funk and
John Fossaceca all contributed to this document.
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks (in no particular order) to Keith McCloghrie, Kaushik Narayan, Murtaza Chiba, Bill Burr, Russ Housley, David McGrew,
Pat Calhoun, Joel Halpern, Jim Schaad and Greg Weber for useful feedback.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2865;
&rfc4086;
&rfc2866;
&rfc2868;
&rfc2104;
&rfc4231;
&rfc2119;
&rfc3394;
&rfc5176;
&rfc3579;
<reference anchor="FIPS.180-2.2002">
<front>
<title>Secure Hash Standard</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="August" year="2002"/>
</front>
<seriesInfo name="FIPS" value="PUB 180-2"/>
<format type="PDF" target="http://.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf"/>
</reference>
<reference anchor="NIST.SP800-38B">
<front>
<title>Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication</title>
<author initials="M." surname="Dworkin" fullname="Morris Dworkin">
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="May" year="2005"/>
</front>
<format type="PDF" target="http://csrc.nist.gov/CryptoToolkit/modes/800-38_Series_Publications/SP800-38B.pdf"/>
</reference>
</references>
<references title="Informative References">
&rfc2548;
&rfc3748;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 07:33:57 |