[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

Network Working Group                                            G. Zorn
Internet-Draft                                               Network Zen
Intended status: Standards Track                                 H. Zhou
Expires: May 1, 2009                                          J. Salowey
                                                           Cisco Systems
                                                        October 28, 2008


                Transmitting Confidential Data in RADIUS
                    draft-zorn-radius-encattr-15.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 1, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   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.





Zorn, et al.               Expires May 1, 2009                  [Page 1]


Internet-Draft            Encrypted Attributes              October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Specification of Requirements  . . . . . . . . . . . . . . . .  4
   3.  Type-Length-Value Definitions  . . . . . . . . . . . . . . . .  4
     3.1.  Encryption-Type  . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Application-Id . . . . . . . . . . . . . . . . . . . . . .  6
     3.3.  Encrypting-Key-Id  . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Key-Id . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.5.  Key-Lifetime . . . . . . . . . . . . . . . . . . . . . . .  9
     3.6.  Initialization-Vector  . . . . . . . . . . . . . . . . . . 10
     3.7.  Encrypted-Data . . . . . . . . . . . . . . . . . . . . . . 11
     3.8.  Message-Authentication-Code  . . . . . . . . . . . . . . . 12
       3.8.1.  Protecting Entire RADIUS Messages  . . . . . . . . . . 13
       3.8.2.  Protecting a Subset of the Attributes in a Message . . 15
     3.9.  MAC-Randomizer . . . . . . . . . . . . . . . . . . . . . . 16
     3.10. MAC-Key-Id . . . . . . . . . . . . . . . . . . . . . . . . 17
     3.11. MAC-Type . . . . . . . . . . . . . . . . . . . . . . . . . 18
   4.  Diameter Considerations  . . . . . . . . . . . . . . . . . . . 19
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
     5.1.  TLV Types  . . . . . . . . . . . . . . . . . . . . . . . . 19
     5.2.  TLV Values . . . . . . . . . . . . . . . . . . . . . . . . 20
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 25





















Zorn, et al.               Expires May 1, 2009                  [Page 2]


Internet-Draft            Encrypted Attributes              October 2008


1.  Introduction

   Certain applications of the RADIUS protocol [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 [RFC2865] or CoA-Request [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.

   Currently, this type of transfer is usually accomplished using either
   the Tunnel-Password Attribute [RFC2868] or vendor-specific RADIUS
   attributes.  However, there are several issues with these techniques:

   o  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.

   o  The security properties and strength of the encryption method used
      to hide the contents of the Tunnel-Password Attribute are unknown.

   o  Due to its dependency upon the random Request Authenticator in the
      Access-Request message [RFC2865], the Tunnel-Password Attribute
      cannot be used in messages other than Access-Accept.

   o  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.

   Similarly, encryption keys such as those derived as a side-effect of
   some EAP [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.

   This document defines a set of Type-Length-Value (TLV) tuples which,
   when encapsulated in RADIUS Extended Attributes
   [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, algorithmically agile authentication for any



Zorn, et al.               Expires May 1, 2009                  [Page 3]


Internet-Draft            Encrypted Attributes              October 2008


   RADIUS message, including those used for accounting and dynamic
   authorization.

   Discussion of this draft may be directed to the authors.


2.  Specification of Requirements

   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 [RFC2119].


3.  Type-Length-Value Definitions

   The following subsections describe the TLVs defined by this document.
   This specification concerns the following values:

      <TBD1> Encryption-Type

      <TBD2> Application-Id

      <TBD3> Encrypting-Key-Id

      <TBD4> Key-Id

      <TBD5> Key-Lifetime

      <TBD6> Initialization-Vector

      <TBD7> Encrypted-Data

      <TBD8> Message-Authentication-Code

      <TBD9> MAC-Randomizer

      <TBD10> MAC-Key-Id

      <TBD11> MAC-Type

   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
   [I-D.ietf-radext-extended-attributes].







Zorn, et al.               Expires May 1, 2009                  [Page 4]


Internet-Draft            Encrypted Attributes              October 2008


3.1.  Encryption-Type

   Description

      The Encryption-Type TLV is used to specify the cryptographic
      algorithm used to protect the Encrypted-Data TLV (Section 3.7)

      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 (Section 3.7).  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
      [I-D.ietf-radext-extended-attributes].


   A summary of the Encryption-Type TLV format is shown below.  The
   fields are transmitted from left to right.

                        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     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Ext-Type

      <TBD1> for Encryption-Type

   Ext-Len

      4

   Value

      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:

         0 NULL

         1 AES-CBC-128 [FIPS-197-2001]

         2 AES-CBC-192 [FIPS-197-2001]







Zorn, et al.               Expires May 1, 2009                  [Page 5]


Internet-Draft            Encrypted Attributes              October 2008


         3 AES-CBC-256 [FIPS-197-2001]

         4 AES Key Wrap with 128-bit KEK [RFC3394]

         5 AEAD_AES_SIV_CMAC_256 [RFC5297]

         6 AEAD_AES_SIV_CMAC_384 [RFC5297]

         7 AEAD_AES_SIV_CMAC_512 [RFC5297]

         8 RSAES-OAEP [PKCS.1.1998]

      Other values are to be assigned by IANA.

      Implementations MUST support encryption types 0 (NULL), 1 (AES-
      CBC-128) and 4 (AES Key Wrap).

3.2.  Application-Id

   Description

      The Application-Id TLV is 7 octets in length.  If the Encrypted-
      Data TLV (Section 3.7) 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.

      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 (Section 3.7).  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
      [I-D.ietf-radext-extended-attributes].


   A summary of the Application-Id TLV format is shown below.  The
   fields are transmitted from left to right.

                        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                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Zorn, et al.               Expires May 1, 2009                  [Page 6]


Internet-Draft            Encrypted Attributes              October 2008


   Ext-Type

      <TBD2> for Application-Id

   Ext-Len

      7

   Value

      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:

         0 Unspecified

         1 EAP MSK [RFC3748]

         2 EAP USRK [RFC5295]

         3 PKMv1 AUTH Key [IEEE.802.16-2004]

      Other values are to be assigned by IANA.

3.3.  Encrypting-Key-Id

   Description

      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 (Section 3.7).  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 (Section 3.1).  Further specification of the
      content of this TLV is outside the scope of this document.

      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 (Section 3.7).
      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
      [I-D.ietf-radext-extended-attributes].


   A summary of the Encrypting-Key-Id TLV format is shown below.  The
   fields are transmitted from left to right.



Zorn, et al.               Expires May 1, 2009                  [Page 7]


Internet-Draft            Encrypted Attributes              October 2008


                        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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Ext-Type

      <TBD3> for Encrypting-Key-Id

   Ext-Len

      >= 4

   Value

      The Value field is variable length and MAY be used to identify the
      shared cryptographic key used to protect the Encrypted-Data TLV.

3.4.  Key-Id

   Description

      The Key-Id TLV is variable length.  If the Encrypted-Data TLV
      (Section 3.7) 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.

      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 (Section 3.7).  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
      [I-D.ietf-radext-extended-attributes].


   A summary of the Key-Id TLV format is shown below.  The fields are
   transmitted from left to right.

                        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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Zorn, et al.               Expires May 1, 2009                  [Page 8]


Internet-Draft            Encrypted Attributes              October 2008


   Ext-Type

      <TBD4> for Key-Id

   Ext-Len

      >= 4

   Value

      The Value field is variable length and MAY be used to identify the
      key encapsulated in the Encrypted-Data TLV.

3.5.  Key-Lifetime

   Description

      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.

      NOTE: Applications using this value SHOULD consider the beginning
      of the lifetime to be the point in time when the key is first
      used.

      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 (Section 3.7).  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
      [I-D.ietf-radext-extended-attributes].


   A summary of the Key-Lifetime TLV format is shown below.  The fields
   are transmitted from left to right.

                        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                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Zorn, et al.               Expires May 1, 2009                  [Page 9]


Internet-Draft            Encrypted Attributes              October 2008


   Ext-Type

      <TBD5> for Key-Lifetime

   Ext-Len

      7

   Value

      The Value field is a 32-bit integer [RFC2865] and MAY be used to
      specify the length of time (in seconds) that the key is valid.

3.6.  Initialization-Vector

   Description

      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.

      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 (Section 3.7).
      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
      [I-D.ietf-radext-extended-attributes].


   A summary of the Initialization-Vector TLV format is shown below.
   The fields are transmitted from left to right.

                        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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Ext-Type

      <TBD6> for Initialization-Vector







Zorn, et al.               Expires May 1, 2009                 [Page 10]


Internet-Draft            Encrypted Attributes              October 2008


   Ext-Len

      >= 4

   Value

      The length of the Value field depends upon the value of the
      Encryption-Type TLV, but is fixed for any given value thereof.

3.7.  Encrypted-Data

   Description

      This TLV MAY be used to carry one or more encrypted TLVs or
      Attributes (traditional, extended or a mixture thereof) in a
      RADIUS message.

      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
      (Section 3.8) and MAC-Type (Section 3.11) 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
      [I-D.ietf-radext-extended-attributes].

      The encryption of the Attribute(s) MUST be performed by the sender
      according to the following algorithm:

         Concatenate the Attributes to be encrypted.  If the algorithm
         specified by the associated Encryption-Type TLV (Section 3.1)
         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 (Section 3.6).

         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.

      The receiver MUST recover the plaintext Attribute(s) using the
      following algorithm:





Zorn, et al.               Expires May 1, 2009                 [Page 11]


Internet-Draft            Encrypted Attributes              October 2008


         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 into
         Attributes, discarding the padding (if any).


      Type-Length-Value tuples may be encrypted using the same algorithm
      as Attributes.

      A summary of the Encrypted-Data TLV format is shown below.  The
      fields are transmitted from left to right.


                        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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



      Ext-Type

         <TBD7> for Encrypted-Data

      Ext-Length

         >= 4

      String

         The String field is variable length and contains the actual
         encrypted data (see above).

3.8.  Message-Authentication-Code

   Description

      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 as a hint that the sender
      prefers the use of this Attribute for message authentication; the
      receiver is not obligated to do so, however.






Zorn, et al.               Expires May 1, 2009                 [Page 12]


Internet-Draft            Encrypted Attributes              October 2008


3.8.1.  Protecting Entire RADIUS Messages

      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
      (Section 3.11), MAC-Randomizer (Section 3.9) and MAC-Key-Id
      (Section 3.10) may be present in the Extended Attribute.

      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).

      In addition, the message SHOULD NOT also contain an instance of
      the Message-Authenticator Attribute [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.

      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.

      If a received message contains an instance of the MAC-Randomizer
      TLV (Section 3.9), the received MAC-Randomizer TLV SHOULD be
      included in the computation of the Message-Authentication-Code TLV
      sent in the response, as described below.

      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.

3.8.1.1.  Request Messages


   For requests (e.g., CoA-Request [RFC5176], Accounting-Request
   [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



Zorn, et al.               Expires May 1, 2009                 [Page 13]


Internet-Draft            Encrypted Attributes              October 2008


   packet, using a shared secret as the key, as follows.

   MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes) where '+'
   represents concatenation

   The MAC-Randomizer TLV (Section 3.9) 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.

   If the Message-Authenticator-Code TLV is included in a client
   request, the server SHOULD ignore the contents of the Request
   Authenticator.

   Implementation Notes

      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.

      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.

3.8.1.2.  Response Messages


   For responses (e.g., CoA-ACK [RFC5176], Accounting-Response
   [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.

   MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes) where
   '+' represents concatenation

   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.

   If the Message-Authenticator-Code TLV is included in a server
   response, the client SHOULD ignore the contents of the Response
   Authenticator.






Zorn, et al.               Expires May 1, 2009                 [Page 14]


Internet-Draft            Encrypted Attributes              October 2008


   Implementation Notes

      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.

      The Message-Authentication-Code TLV MUST be created and inserted
      in the packet before the Response Authenticator is calculated.

      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.

3.8.2.  Protecting a Subset of the Attributes in a Message

   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 placed in a separate TLV and
   the TAG method used to associate the Extended Attributes.

   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 placed in a separate TLV and
   the TAG method used to associate the Extended Attributes.

   A summary of the Message-Authentication-Code TLV format is shown
   below.  The fields are transmitted from left to right.

                        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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Zorn, et al.               Expires May 1, 2009                 [Page 15]


Internet-Draft            Encrypted Attributes              October 2008




      Ext-Type

         <TBD8> for Message-Authentication-Code

      Ext-Length

         >4

      MAC

         Both the length and value of the MAC field depend upon the
         algorithm specified by the value of the MAC-Type TLV
         (Section 3.11).  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.

3.9.  MAC-Randomizer

   Description

      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 [RFC4086].

      Implementation Note

         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.

   A summary of the MAC-Randomizer attribute format is shown below.  The
   fields are transmitted from left to right.














Zorn, et al.               Expires May 1, 2009                 [Page 16]


Internet-Draft            Encrypted Attributes              October 2008


                        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)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




      Type

         >TBD9< for MAC-Randomizer

      Length

         35

      Random

         This field MUST contain a 32 octet random number which SHOULD
         satisfy the requirements of [RFC4086].

3.10.  MAC-Key-Id

   Description

      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 (Section 3.11).
      Further specification of the content of this field is outside the



Zorn, et al.               Expires May 1, 2009                 [Page 17]


Internet-Draft            Encrypted Attributes              October 2008


      scope of this document.

   A summary of the MAC-Key-Id TLV format is shown below.  The fields
   are transmitted from left to right.

                        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...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Ext-Type

      <TBD10> for MAC-Key-Id

   Ext-Len

      >= 4

   Value

      The Value field contains an identifier for the key used in the
      calculation of the Message-Authentication-Code TLV

3.11.  MAC-Type

   Description

      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.

   A summary of the MAC-Type TLV format is shown below.  The fields are
   transmitted from left to right.

                        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     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Ext-Type

      <TBD11> for MAC-Type







Zorn, et al.               Expires May 1, 2009                 [Page 18]


Internet-Draft            Encrypted Attributes              October 2008


   Ext-Len

      4

   Value

      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:

         0 HMAC-SHA-1 [FIPS.180-2.2002] [RFC2104]

         1 HMAC-SHA-256 [FIPS.180-2.2002] [RFC4231]

         2 HMAC-SHA-512 [FIPS.180-2.2002] [RFC4231]

         3 CMAC-AES-128 [NIST.SP800-38B]

         4 CMAC-AES-192 [NIST.SP800-38B]

         5 CMAC-AES-256 [NIST.SP800-38B]

      Other values are to be assigned by IANA.

      Implementations MUST support MAC Type 0 (HMAC-SHA-1).


4.  Diameter Considerations

   Since the TLVs defined in this document are designed to be carried by
   Extended Attributes [I-D.ietf-radext-extended-attributes], there are
   no special considerations for interoperation with Diameter.


5.  IANA Considerations

   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 [RFC5226].

5.1.  TLV Types

   Upon publication of this document as an RFC, IANA must assign RADIUS
   Extended Type numbers [I-D.ietf-radext-extended-attributes] to the
   following TLVS:





Zorn, et al.               Expires May 1, 2009                 [Page 19]


Internet-Draft            Encrypted Attributes              October 2008


      <TBD1> Encryption-Type

      <TBD2> Application-Id

      <TBD3> Encrypting-Key-Id

      <TBD4> Key-Id

      <TBD5> Key-Lifetime

      <TBD6> Initialization-Vector

      <TBD7> Encrypted-Data

      <TBD8> Message-Authentication-Code

      <TBD9> MAC-Randomizer

      <TBD10> MAC-Key-Id

      <TBD11> MAC-Type

5.2.  TLV Values

   For three of the above extended attribute types, a sub-registry for
   embedded values is to be created and populated from the tables
   contained in the respective subsections of this document:

   o  As specified in Section 3.1, 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.  Initial
      values for the Encryption-Type TLV are specified in Section 3.1.

   o  As specified in Section 3.11, 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.  Initial values
      for the MAC-Type TLV are specified in Section 3.11.

   o  As specified in Section 3.2, 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.  Initial
      values for the Application-Id TLV are specified in Section 3.2.


6.  Security Considerations

   Although the encryption algorithms specified in this document are
   believed to be strong, ultimately the confidentiality of the



Zorn, et al.               Expires May 1, 2009                 [Page 20]


Internet-Draft            Encrypted Attributes              October 2008


   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.).

   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.

   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.

   Since the successful application of the AES Key Wrap with 128-bit KEK
   (Section 3.1) requires randomness in the quantity to be wrapped, this
   algorithm MUST NOT be used to encrypt non-random data.


7.  Contributors

   Nancy Cam-Winget, Paul Funk, Alfred Hoenes and John Fossaceca all
   contributed to this document.


8.  Acknowledgements

   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.


9.  References

9.1.  Normative References

   [FIPS-197-2001]
              National Institute of Standards and Technology, "Advanced
              Encryption Standard (AES)", FIPS PUB 197, November 2001, <
              http://csrc.nist.gov/publications/fips/fips197/
              fips-197.pdf>.

   [FIPS.180-2.2002]
              National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS PUB 180-2, August 2002, <http://
              .nist.gov/publications/fips/fips180-2/
              fips180-2withchangenotice.pdf>.



Zorn, et al.               Expires May 1, 2009                 [Page 21]


Internet-Draft            Encrypted Attributes              October 2008


   [I-D.ietf-radext-extended-attributes]
              Li, Y., Lior, A., and G. Zorn, "Extended Remote
              Authentication Dial In User Service (RADIUS) Attributes",
              draft-ietf-radext-extended-attributes-04 (work in
              progress), July 2008.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, September 2002.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4231]  Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
              224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
              RFC 4231, December 2005.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5297]  Harkins, D., "Synthetic Initialization Vector (SIV)
              Authenticated Encryption Using the Advanced Encryption
              Standard (AES)", RFC 5297, October 2008.

9.2.  Informative References

   [IEEE.802.16-2004]
              "Information technology -  Telecommunications and
              information exchange between systems -  Local and
              metropolitan area networks -  Specific requirements -
              Part 16: Wireless LAN Medium Access Control (MAC) and
              Physical Layer (PHY) specifications", IEEE Standard
              802.16, 2004, <http://standards.ieee.org/getieee802/
              download/802.16-2004.pdf>.




Zorn, et al.               Expires May 1, 2009                 [Page 22]


Internet-Draft            Encrypted Attributes              October 2008


   [NIST.SP800-38B]
              Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation: The CMAC Mode for Authentication", May 2005, <h
              ttp://csrc.nist.gov/CryptoToolkit/modes/
              800-38_Series_Publications/SP800-38B.pdf>.

   [PKCS.1.1998]
              Kaliski, BK. and JS. Staddon, "RSA Encryption Standard,
              Version 2.0", PKCS 1, October 1998,
              <ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-1v2.asc>.

   [RFC2868]  Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege,
              M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol
              Support", RFC 2868, June 2000.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC5176]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 5176,
              January 2008.

   [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
              "Specification for the Derivation of Root Keys from an
              Extended Master Session Key (EMSK)", RFC 5295,
              August 2008.


Authors' Addresses

   Glen Zorn
   Network Zen
   1463 East Republican Street
   #358
   Seattle, WA  98112
   US

   Phone: +1 (205) 377-9035
   Email: gwz@net-zen.net






Zorn, et al.               Expires May 1, 2009                 [Page 23]


Internet-Draft            Encrypted Attributes              October 2008


   Hao Zhou
   Cisco Systems
   4125 Highlander Parkway
   REQ01/3/
   Richfield, OH  44286
   US

   Phone: +1 (330) 523-2132
   Email: hzhou@cisco.com


   Joseph Salowey
   Cisco Systems
   2901 Third Avenue
   SEA1/6/
   Seattle, WA  98121
   US

   Phone: +1 (206) 256-3380
   Email: jsalowey@cisco.com































Zorn, et al.               Expires May 1, 2009                 [Page 24]


Internet-Draft            Encrypted Attributes              October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Zorn, et al.               Expires May 1, 2009                 [Page 25]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/