One document matched: draft-zorn-radius-encattr-13.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 rfc3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY rfc3394 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3394.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 rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2104 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml'>
<!ENTITY rfc5176 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5176.xml'>
<!ENTITY rfc5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY rfc3579 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml'>
<!ENTITY rfc4231 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4231.xml'>
<!ENTITY rfc4086 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml'>
<!ENTITY extattr PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-radext-extended-attributes-04.xml'>
<!ENTITY siv PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-dharkins-siv-aes-05.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= "std" ipr="full3978" docName="draft-zorn-radius-encattr-13.txt">
<front>
<title abbrev="Encrypted Attributes">Transmitting Confential Data in RADIUS</title>
<author fullname="Glen Zorn" initials="G.Z." surname="Zorn">
<organization>NetCube Technologies</organization>
<address>
<postal>
<street>77/440 Soi Phoomjit</street>
<street>Rama IV Road</street>
<street>Phrakanong Klongtoie</street>
<city>Bangkok</city>
<code>10110</code>
<country>Thailand</country>
</postal>
<phone>+66 (0) 6600 6480</phone>
<email>gwz@netcube.com</email>
</address>
</author>
<author initials="H." surname="Zhou" fullname="Hao Zhou">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>4125 Highlander Parkway</street>
<street>REQ01/3/</street>
<city>Richfield</city>
<region>OH</region>
<code>44286</code>
<country>US</country>
</postal>
<phone>+1 (330) 523-2132</phone>
<email>hzhou@cisco.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="2008"/>
<keyword>RADIUS</keyword>
<keyword>Security</keyword>
<keyword>Cryptoagility</keyword>
<abstract>
<t>
This document defines a set of Type-Length-Value (TLV) tuples which, when encapsulated in RADIUS Extended Attributes, are designed to allow
the secure transmission of sensitive or confidential data (including encryption keys) between RADIUS clients and servers.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Certain applications of the RADIUS protocol <xref target="RFC2865"/> require that
the content (at least, if not the type and length) of one or more
Attributes in a message be encrypted. For example, an application enabling the interception of certain packets by law
enforcement agencies might require that it be impossible for an observer to distinguish between sessions which are under
surveillance and those that are not. If packet interception is enabled and disabled using RADIUS (via the Access-Accept <xref target="RFC2865"/>
or CoA-Request
<xref target="RFC5176"/> messages, for example) then the Attributes used to signal this must be encrypted; however, it might be acceptable for the
remainder of the Attributes to be sent in cleartext.
<vspace blankLines="1"/>
Currently, this type of transfer is usually accomplished using either the Tunnel-Password Attribute <xref target="RFC2868"/>
or vendor-specific RADIUS attributes.
However, there are several issues with these techniques:
<list style="symbols">
<t>The Tunnel-Password Attribute was not designed to carry entire RADIUS Attributes and it is not large enough to hold an Attribute
of the maximum size
</t>
<t>The security properties and strength of the encryption method used to hide the contents of the Tunnel-Password Attribute are unknown
</t>
<t>Due to its dependency upon the random Request Authenticator in the Access-Request message <xref target="RFC2865"/>,
the Tunnel-Password Attribute cannot be used in messages other than Access-Accept
</t>
<t>Although vendor-specific Attributes may not share the problems outlined above, a profusion of different attributes used for the same purpose entails
considerable multiplication of effort and makes interoperability difficult to achieve
</t>
</list>
Similarly, encryption keys such as those derived as a side-effect of some EAP <xref target="RFC3748"/> authentication methods are often transported
using RADIUS. These keys must be kept confidential, as well, though the protection of keys may demand different cryptographic qualities then that of other
data.
<vspace blankLines="1"/>
This document defines a set of Type-Length-Value (TLV) tuples which, when encapsulated in RADIUS Extended Attributes
<xref target="I-D.ietf-radext-extended-attributes"/>, are designed to allow
the secure transmission of sensitive or confidential data (including encryption keys) between RADIUS clients and servers
using
non-proprietary techniques with well-understood security properties.
In addition, the Message-Authentication-Code TLV may be used by itself to provide strong, algorithically agile
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="Type-Length-Value Definitions">
<t>
The following subsections describe the TLVs defined by this document.
This specification concerns the following values:
<list>
<t><TBD1> Encryption-Type</t>
<t><TBD2> Application-Id</t>
<t><TBD3> Encrypting-Key-Id</t>
<t><TBD4> Key-Id</t>
<t><TBD5> Key-Lifetime</t>
<t><TBD6> Initialization-Vector</t>
<t><TBD7> Encrypted-Data</t>
<t><TBD8> Message-Authentication-Code</t>
<t><TBD9> MAC-Randomizer</t>
<t><TBD10> MAC-Key-Id</t>
<t><TBD11> MAC-Type</t>
</list>
NOTE: These values do not represent traditional RADIUS Attributes: in order to be included in a RADIUS message, TLVs
MUST be encapsulated in one or more Extended RADIUS Attributes <xref target="I-D.ietf-radext-extended-attributes"/>.
</t>
<section anchor="E-T" title="Encryption-Type">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The Encryption-Type TLV is used to specify the cryptographic algorithm used to protect the Encrypted-Data TLV (<xref target="E-D"/>)
<vspace blankLines="1"/>
Any packet
that contains an Extended Attribute encapsulating an instance of the Encryption-Type TLV MUST also contain
one or more associated instances of the Encrypted-Data TLV (<xref target="E-D"/>).
The TLVs may be associated in two ways: if all of the TLVs can fit into a single
Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method
<xref target="I-D.ietf-radext-extended-attributes"/>.
<vspace blankLines="1"/>
</t>
</list>
A summary of the Encryption-Type TLV format is shown below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD1> for Encryption-Type
</t>
<t hangText="Ext-Len">
<vspace blankLines="1"/>
4
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The Value field is 1 octet in length and serves to identify the encryption
algorithm in use. This document defines the following decimal values for this field:
<list>
<t>0 NULL</t>
<t>1 AES-CBC-128 <xref target="FIPS-197-2001"></xref></t>
<t>2 AES-CBC-192 <xref target="FIPS-197-2001"></xref></t>
<t>3 AES-CBC-256 <xref target="FIPS-197-2001"></xref></t>
<t>4 AES Key Wrap with 128-bit KEK <xref target="RFC3394"/></t>
<t>5 AEAD_AES_SIV_CMAC_256 <xref target="I-D.dharkins-siv-aes"/></t>
<t>6 AEAD_AES_SIV_CMAC_384 <xref target="I-D.dharkins-siv-aes"/></t>
<t>7 AEAD_AES_SIV_CMAC_512 <xref target="I-D.dharkins-siv-aes"/></t>
<t>8 RSAES-OAEP <xref target="PKCS.1.1998"/></t>
</list>
Implementations MUST support encryption types 0 (NULL), 1 (AES-CBC-128) and 4 (AES Key Wrap). Other values are to be assigned by IANA.
</t>
</list>
</t>
</section>
<section anchor="A-I" title="Application-Id">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The Application-Id TLV is 7 octets in length. If the Encrypted-Data TLV (<xref target="E-D"/>)
contains a cryptographic key, the Application-Id TLV MAY
be used to identify 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.
<vspace blankLines="1"/>
Any packet
that contains an Extended Attribute encapsulating an instance of the Application-Id TLV MUST also contain
one or more associated instances of the Encrypted-Data TLV (<xref target="E-D"/>).
The TLVs may be associated in two ways: if all of the TLVs can fit into a single
Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method
<xref target="I-D.ietf-radext-extended-attributes"/>.
<vspace blankLines="1"/>
</t>
</list>
A summary of the Application-Id TLV format is shown below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD2> for Application-Id
</t>
<t hangText="Ext-Len">
<vspace blankLines="1"/>
7
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The Value field is 4 octets in length and identifies the type of application
for which the key encapsulated in the associated Encrypted-Data TLV is to be used.
This document defines the following decimal values for this field:
<list>
<t>0 Unspecified</t>
<t>1 EAP MSK <xref target="RFC3748"></xref></t>
</list>
Other values are to be assigned by IANA.
</t>
</list>
</t>
</section>
<section anchor="E-K-I" title="Encrypting-Key-Id">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The Encrypting-Key-Id TLV is variable length and MAY be used to identify
the shared cryptographic key used to protect the Encrypted-Data TLV (<xref target="E-D"/>).
If present, the Encrypting-Key-Id TLV MUST refer to an encryption key of a type and length appropriate
for use with the algorithm specified by the Encryption-Type TLV (<xref target="E-T"/>).
Further specification of the content of this TLV is outside the scope of this document.
<vspace blankLines="1"/>
Any packet
that contains an Extended Attribute encapsulating an instance of the Encrypting-Key-Id TLV MUST also contain
one or more associated instances of the Encrypted-Data TLV (<xref target="E-D"/>).
The TLVs may be associated in two ways: if all of the TLVs can fit into a single
Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method
<xref target="I-D.ietf-radext-extended-attributes"/>.
<vspace blankLines="1"/>
</t>
</list>
A summary of the Encrypting-Key-Id TLV format is shown below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD3> for Encrypting-Key-Id
</t>
<t hangText="Ext-Len">
<vspace blankLines="1"/>
≥ 4
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The Value field is variable length and MAY be used to identify
the shared cryptographic key used to protect the Encrypted-Data TLV.
</t>
</list>
</t>
</section>
<section anchor="K-I" title="Key-Id">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The Key-Id TLV is variable length. If the Encrypted-Data TLV (<xref target="E-D"/>) contains cryptographic
keying material, the Key-Id TLV MAY be used by the communicating parties to identify the material being transmitted.
The Key-Id is assumed to be known to the parties that derived the keying material.
Further specification of the content of this TLV is outside the scope of this document.
<vspace blankLines="1"/>
Any packet
that contains an Extended Attribute encapsulating an instance of the Key-Id TLV MUST also contain
one or more associated instances of the Encrypted-Data TLV (<xref target="E-D"/>).
The TLVs may be associated in two ways: if all of the TLVs can fit into a single
Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method
<xref target="I-D.ietf-radext-extended-attributes"/>.
<vspace blankLines="1"/>
</t>
</list>
A summary of the Key-Id TLV format is shown below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD4> for Key-Id
</t>
<t hangText="Ext-Len">
<vspace blankLines="1"/>
≥ 4
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The Value field is variable length and MAY be used to identify
the key encapsulated in the Encrypted-Data TLV.
</t>
</list>
</t>
</section>
<section anchor="K-L" title="Key-Lifetime">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
If the data encapsulated in the Encrypted-Data TLV is a cryptographic key,
the value of the Key-Lifetime TLV represents
the period of time (in seconds) for which the key 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 key is first used.
<vspace blankLines="1"/>
Any packet
that contains an Extended Attribute encapsulating an instance of the Key-Lifetime TLV MUST also contain
one or more associated instances of the Encrypted-Data TLV (<xref target="E-D"/>).
The TLVs may be associated in two ways: if all of the TLVs can fit into a single
Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method
<xref target="I-D.ietf-radext-extended-attributes"/>.
<vspace blankLines="1"/>
</t>
</list>
A summary of the Key-Lifetime TLV format is shown below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD5> for Key-Lifetime
</t>
<t hangText="Ext-Len">
<vspace blankLines="1"/>
7
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The Value field is a 32-bit integer <xref target="RFC2865"/> and MAY be used to specify the length of time (in seconds)
that the key is valid.
</t>
</list>
</t>
</section>
<section anchor="I-V" title="Initialization-Vector">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
If the data encapsulated in the Encrypted-Data TLV represents a cryptographic key and the algorithm specified by the Encryption-Type TLV
requires the use of an initialization vector (IV), this TLV may be used to communicate the IV from the RADIUS server to its client.
<vspace blankLines="1"/>
Any packet
that contains an Extended Attribute encapsulating an instance of the Initialization-Vector TLV MUST also contain
one or more associated instances of the Encrypted-Data TLV (<xref target="E-D"/>).
The TLVs may be associated in two ways: if all of the TLVs can fit into a single
Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method
<xref target="I-D.ietf-radext-extended-attributes"/>.
<vspace blankLines="1"/>
</t>
</list>
A summary of the Initialization-Vector TLV format is shown below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD6> for Initialization-Vector
</t>
<t hangText="Ext-Len">
<vspace blankLines="1"/>
≥ 4
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The length of the Value field depends upon the value of the Encryption-Type TLV,
but is fixed for any given value thereof.
</t>
</list>
</t>
</section>
<section anchor="E-D" title="Encrypted-Data">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
This TLV MAY be used
to carry one or more encrypted TLVs or
Attributes (traditional, extended or a mixture thereof)
in a RADIUS message.
<vspace blankLines="1"/>
Any packet
that contains an Encrypted-Data TLV MUST also include an associated instance of the
Encryption-Type TLV and SHOULD
include associated instances of the Message-Authentication-Code (<xref target="M-A-C"/>) and MAC-Type (<xref target="M-T"/>) TLVs.
The TLVs may be associated in two ways: if all of the TLVs can fit into a single
Extended Attribute, that is sufficient to associate them; otherwise, the TLVs MUST be associated using the Tag method
<xref target="I-D.ietf-radext-extended-attributes"/>.
<vspace blankLines="1"/>
The encryption of the Attribute(s) MUST be performed by the sender
according to the following algorithm:
<list style="empty">
<t>
Concatenate the Attributes to be encrypted. If the algorithm specified by the associated
Encryption-Type TLV (<xref target="E-T"/>)
is a block cipher and the length in octets of the result is not an even multiple of the algorithm's
block size, pad the result of the concatenation on the right
with enough zero-value octets to make the resulting string an even multiple of the block size in length.
Encrypt the result using the
algorithm specified by the Encryption-Type and, if
necessary, an initialization vector. If an IV is used, store it in an associated Initialization-Vector TLV
(<xref target="I-V"/>).
<vspace blankLines="1"/>
Split the resulting ciphertext into one or more chunks, each ≤ 243 octets in length.
Encapsulate each chunk in a separate
instance of the Encrypted-Data TLV.
</t>
</list>
The receiver MUST recover the plaintext Attribute(s) using the following algorithm:
<list style="empty">
<t>
Concatenate the String fields of the received Encrypted-Data TLVs in order of reception. Decrypt the result using the
algorithm specified in the associated Encryption-Type TLV and (if necessary)
the IV contained in the associated Initialization-Vector TLV.
Split the resulting cleartext in to Attributes, discarding the padding (if any).
</t>
</list>
<vspace blankLines="1"/>
Type-Length-Value tuples may be encrypted using the same algorithm as Attributes.
<vspace blankLines="1"/>
A summary of the Encrypted-Data TLV format is shown below. The fields are transmitted from left to right.
</t>
</list>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="empty">
<t>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD7> for Encrypted-Data
</t>
<t hangText="Ext-Length">
<vspace blankLines="1"/>
≥ 4
</t>
<t hangText="String">
<vspace blankLines="1"/>
The String field is variable length and contains the actual encrypted
data (see above).
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="M-A-C" title="Message-Authentication-Code">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
This TLV MAY be used to "sign" groups of Attributes or TLVs or whole RADIUS 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.
</t>
</list>
</t>
<section anchor="MAC-Message" title="Protecting Entire RADIUS Messages" >
<t>
<list style="empty">
<t>
If the Message-Authentication-Code TLV is used to protect an entire RADIUS message,
the Extended Attribute in which it is encapsulated MUST NOT contain any TLVs that are not MAC-related;
i.e., only the Message-Authentication-Code,
MAC-Type (<xref target="M-T"/>), MAC-Randomizer (<xref target="M-R"/>) and MAC-Key-Id (<xref target="M-K-I"/>)
may be present in the Extended Attribute.
<vspace blankLines="1"/>
Since in this case the Message-Authentication-Code TLV is not
associated with any particular subset of Attributes in the message,
the Tag field of the encapsulating Extended Attribute MUST be set to 0 (zero).
<vspace blankLines="1"/>
In addition, the message SHOULD NOT also contain an instance of the
Message-Authenticator Attribute <xref target="RFC3579"/>.
If both the Message-Authentication-Code TLV and the Message-Authenticator Attribute
are to be used to protect a message (e.g., for backward compatibility in a network containing both old and new clients),
the value of the
Message-Authentication-Code TLV MUST be computed before that of the Message-Authenticator Attribute.
<vspace blankLines="1"/>
If any message is received that has been protected with the Message-Authentication-Code TLV,
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 TLV (<xref target="M-R"/>),
the received MAC-Randomizer TLV SHOULD
be included in the computation of the Message-Authentication-Code TLV sent in the response, as described below.
<vspace blankLines="1"/>
When an entire message is being protected,
the derivation of the MAC field value of the Message-Authentication-Code TLV (below)
is identical for all the algorithms specified in this document, with the exception of 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.
</t>
</list>
</t>
<section title="Request Messages" anchor="R-M">
<t>
<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 TLV (<xref target="M-R"/>) MUST be included in any request in which the Message-Authentication-Code
TLV is used.
The Random field of the MAC-Randomizer TLV MUST be filled in before the value of the MAC field is computed.
<vspace blankLines="1"/>
If the Message-Authenticator-Code TLV 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 TLV
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>
</section>
<section title="Response Messages">
<t>
<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 TLV and the responder
wishes to include an instance of the Message-Authentication-Code TLV in the corresponding
response,
then the MAC-Randomizer TLV from the request MUST
be included in the response.
<vspace blankLines="1"/>
If the Message-Authenticator-Code TLV 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 TLV
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 TLV 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>
</section>
</section>
<section anchor="P-S-A" title="Protecting a Subset of the Attributes in a Message">
<t>
Authenticating and protecting the integrity of a set of Extended RADIUS Attributes is simple:
simply assemble the Attributes to be protected, choose an appropriate algorithm and run it over the assembled Attributes.
If all the TLVs to be protected will fit in a single Extended Attribute along with the
associated MAC-related TLVs then this is sufficient to associate
the protected TLVs with the MAC; otherwise, the MAC-related TLVs can be place in a separate
TLV and the TAG method used to associate the Extended Attributes.
<vspace blankLines="1"/>
If any traditional RADIUS Attributes are in the set of Attributes to be protected, however, the above technique cannot be used. In this
case, it is necessary to concatenate the Attributes into one or more Encrypted-Data TLVs, setting the associated Encryption-Type
TLV to 0 (zero) for the Null algorithm), the run the selected MAC algorithm over that set of TLVs.
If all the TLVs to be protected will fit in a single Extended Attribute along with the
associated MAC-related TLVs then this is sufficient to associate
the protected TLVs with the MAC; otherwise, the MAC-related TLVs can be place in a separate
TLV and the TAG method used to associate the Extended Attributes.
</t>
</section>
<t>
A summary of the Message-Authentication-Code TLV format is shown
below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | MAC...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="empty">
<t>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD8> for Message-Authentication-Code
</t>
<t hangText="Ext-Length">
<vspace blankLines="1"/>
>4
</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 TLV (<xref target="M-T"/>)
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.
</t>
</list>
</t>
</list>
</t>
</section>
<section anchor="M-R" title="MAC-Randomizer">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The MAC-Randomizer TLV MUST be present
in any message that includes an instance of the Message-Authentication-Code TLV.
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 TLV SHOULD be placed at the beginning of the RADIUS message if possible.</t>
</list>
</t>
</list>
A summary of the MAC-Randomizer attribute format is shown
below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Random...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Random (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Random (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Random (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Random (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Random (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Random (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Random (cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Random (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="empty">
<t>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
>TBD9< for MAC-Randomizer
</t>
<t hangText="Length">
<vspace blankLines="1"/>
35
</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 anchor="M-K-I" title="MAC-Key-Id">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The MAC-Key-Id TLV is variable length and MAY be used to encapsulate
an identifier for the key used in the calculation of the
Message-Authentication-Code TLV.
If present, the MAC-Key-Id TLV MUST refer to a key of a type and length appropriate for use with the
algorithm specified by the MAC-Type TLV (<xref target="M-T"/>).
Further specification of the content of this field is outside the scope of this document.
</t>
</list>
A summary of the MAC-Key-Id TLV format is shown below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD10> for MAC-Key-Id
</t>
<t hangText="Ext-Len">
<vspace blankLines="1"/>
≥ 4
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The Value field contains an identifier for the key used in the calculation of the
Message-Authentication-Code TLV
</t>
</list>
</t>
</section>
<section anchor="M-T" title="MAC-Type">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The MAC-Type TLV is 4 octets in length and MUST be used to specify the algorithm used in the calculation of the
Message-Authentication-Code TLV.
</t>
</list>
A summary of the MAC-Type TLV format is shown below. The fields are transmitted from left to right.
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Type | Ext-Len | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<list style="hanging">
<t hangText="Ext-Type">
<vspace blankLines="1"/>
<TBD11> for MAC-Type
</t>
<t hangText="Ext-Len">
<vspace blankLines="1"/>
4
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The Value field is 1 octet in length and serves to identify the MAC
algorithm in use. This document defines six values for the Value 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); other values are to be assigned by IANA.
</t>
</list>
</t>
</section>
</section>
<section title="Diameter Considerations" anchor="diameter">
<t>>
Since the TLVs defined in this document are designed to be carried by Extended Attributes <xref target="I-D.ietf-radext-extended-attributes"/>,
there are no special considerations for interoperation with Diameter.
</t>
</section>
<section title="IANA Considerations">
<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="RFC5226"/>.
</t>
<section title="TLV Types">
<t>
Upon publication of this document as an RFC, IANA must assign
RADIUS Extended Type numbers <xref target="I-D.ietf-radext-extended-attributes"/>
to the following TLVS:
<list>
<t><TBD1> Encryption-Type</t>
<t><TBD2> Application-Id</t>
<t><TBD3> Encrypting-Key-Id</t>
<t><TBD4> Key-Id</t>
<t><TBD5> Key-Lifetime</t>
<t><TBD6> Initialization-Vector</t>
<t><TBD7> Encrypted-Data</t>
<t><TBD8> Message-Authentication-Code</t>
<t><TBD9> MAC-Randomizer</t>
<t><TBD10> MAC-Key-Id</t>
<t><TBD11> MAC-Type</t>
</list>
</t>
</section>
<section title="TLV Values">
<t>
As defined in <xref target="E-T"/>,
numbers may need to be assigned for future values of the Encryption-Type TLV.
These numbers may be assigned by applying the "Specification Required" policy.
</t>
<t>
As defined in <xref target="M-T"/>, numbers may need to be assigned for future values of the MAC-Type
TLV.
These numbers may be assigned by applying the "Specification Required" policy.
</t>
<t>
As defined in <xref target="A-I"/>, numbers may need to be assigned for future values of the Application-Id
TLV.
These numbers may be assigned by applying the "Specification Required" policy.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
Although the encryption algorithms specified in this document are believed to be strong,
ultimately the confidentiality of the encrypted attributes depends upon the strength of
the keys used to encrypt them. For this reason, implementations SHOULD
use keys with entropy equal to or greater than the strength of the algorithm used (e.g.,
128 bits of entropy for AES-CBC-128, etc.).
<vspace blankLines="1"/>
Given that the secret shared between RADIUS clients and servers
typically has relatively weak entropy, it is NOT RECOMMENDED that implementations use the shared secret
(or a derivative thereof) as a key for attribute encryption.
<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"/>
Since the successful application of the AES Key Wrap with 128-bit KEK <xref target="E-T"/> requires randomness in the quantity to be wrapped,
this algorithm MUST NOT be used to encrypt non-random data.
</t>
</section>
<section title="Contributors">
<t>
Nancy Cam-Winget, 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, Dan Harkins and Greg Weber for review and useful feedback.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&extattr;
&siv;
&rfc2865;
&rfc5226;
&rfc2119;
&rfc2104;
&rfc4231;
&rfc2866;
&rfc3394;
&rfc4086;
<reference anchor="FIPS-197-2001"
target="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf">
<front>
<title>Advanced Encryption Standard (AES)</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="November" year="2001" />
</front>
<seriesInfo name="FIPS" value="PUB 197" />
</reference>
<reference anchor="FIPS.180-2.2002" target="http://.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf">
<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" />
</reference>
</references>
<references title="Informative References">
&rfc2868;
&rfc3748;
&rfc3579;
&rfc5176;
<reference
anchor="NIST.SP800-38B"
target="http://csrc.nist.gov/CryptoToolkit/modes/800-38_Series_Publications/SP800-38B.pdf">
<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>
</reference>
<reference
anchor="PKCS.1.1998"
target="ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-1v2.asc">
<front>
<title>RSA Encryption Standard, Version 2.0</title>
<author initials="BK" surname="Kaliski" fullname="Burt Kaliski">
<organization>RSA Laboratories</organization>
</author>
<author initials="JS" surname="Staddon" fullname="Jessica Staddon">
<organization>RSA Laboratories</organization>
</author>
<date month="October" year="1998" />
</front>
<seriesInfo name="PKCS" value="1" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 07:37:14 |