Network Working Group G. Zorn
Internet-Draft Network Zen
Intended status: Standards Track February 9, 2010
Expires: August 13, 2010
RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1(PKMv1) Protocol Supportdraft-zorn-radius-pkmv1-08
Abstract
This document defines a set of RADIUS Attributes which are designed
to provide RADIUS support for IEEE 802.16 Privacy Key Management
Version 1.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 13, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Zorn Expires August 13, 2010 [Page 1]

Internet-Draft RADIUS Attributes for PKMv1 February 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Zorn Expires August 13, 2010 [Page 2]

Internet-Draft RADIUS Attributes for PKMv1 February 20101. Introduction
Privacy Key Management Version 1 (PKMv1) [IEEE.802.16-2004] is a
public-key based authentication and key establishment protocol
typically used in fixed wireless broadband network deployments. The
protocol utilizes X.509 v3 certificates [RFC2459], RSA encryption
[RFC2437] and a variety of secret key cryptographic methods to allow
an 802.16 Base Station (BS) to authenticate a Subscriber Station (SS)
and perform key establishment and maintenance between a SS and BS.
This document defines a set of RADIUS Attributes which are designed
to provide support for PKMv1. The target audience for this document
consists of those developers implementing RADIUS support for PKMv1;
therefore, familiarity with both RADIUS [RFC2865] and the IEEE
802.16-2004 standard is assumed.
Discussion of this draft may be directed to the author.
2. Terminology2.1. Requirements Language
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 RFC 2119 [RFC2119].
2.2. Acronyms
CA
Certification Authority; a trusted party issuing and signing X.509
certificates.
For further information on the following terms, please see Section 7
of [IEEE.802.16-2004].
SA
Security Association
SAID
Security Association Identifier
TEK
Traffic Encryption Key
Zorn Expires August 13, 2010 [Page 4]

Internet-Draft RADIUS Attributes for PKMv1 February 20103. Attributes
The following subsections describe the Attributes defined by this
document. This specification concerns the following values:
<TBD1> PKM-SS-Cert
<TBD2> PKM-CA-Cert
<TBD3> PKM-Config-Settings
<TBD4> PKM-Cryptosuite-List
<TBD5> PKM-SAID
<TBD6> PKM-SA-Descriptor
<TBD7> PKM-Auth-Key
3.1. PKM-SS-Cert
Description
The PKM-SS-Cert Attribute is variable length and MAY be
transmitted in the Access-Request message. The Value field is of
type String and contains the X.509 certificate [RFC2459] binding a
public key to the identifier of the Subscriber Station.
It is possible that the size of the SS certificate may exceed the
maximum size of a RADIUS attribute; in this case, the client MUST
encapsulate the certificate in the Value fields of two or more
instances of the PKM-SS-Cert Attribute, each (except possibly the
last) having a length of 255 octets. These multiple PKM-SS-Cert
Attributes MUST appear consecutively and in order within the
packet. Upon receipt, the RADIUS server MUST recover the original
certificate by concatenating the Value fields of the received PKM-
SS-Cert Attributes in order.
A summary of the PKM-SS-Cert Attribute format is shown below. The
fields are transmitted from left to right.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Zorn Expires August 13, 2010 [Page 5]

Internet-Draft RADIUS Attributes for PKMv1 February 2010
Type
<TBD1> for PKM-SS-Cert
Len
> 2
Value
The Value field is variable length and contains a (possibly
complete) portion of an X.509 certificate.
3.2. PKM-CA-Cert
Description
The PKM-CA-Cert Attribute is variable length and MAY be
transmitted in the Access-Request message. The Value field is of
type String and contains the X.509 certificate [RFC2459] used by
the CA to sign the SS certificate carried in the PKM-SS-Cert
attribute (Section 3.1) in the same message.
It is possible that the size of the CA certificate may exceed the
maximum size of a RADIUS attribute; in this case, the client MUST
encapsulate the certificate in the Value fields of two or more
instances of the PKM-CA-Cert Attribute, each (except possibly the
last) having a length of 255 octets. These multiple PKM-CA-Cert
Attributes MUST appear consecutively and in order within the
packet. Upon receipt, the RADIUS server MUST recover the original
certificate by concatenating the Value fields of the received PKM-
CA-Cert Attributes in order.
A summary of the PKM-CA-Cert Attribute format is shown below. The
fields are transmitted from left to right.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<TBD2> for PKM-CA-Cert
Zorn Expires August 13, 2010 [Page 6]

Internet-Draft RADIUS Attributes for PKMv1 February 2010
Type
<TBD3> for PKM-Config-Settings
Len
30
Auth Wait Timeout
The Auth Wait Timeout field is 4 octets in length and corresponds
to the "Authorize wait timeout" field of the 802.16 "PKM
configuration settings" attribute
Reauth Wait Timeout
The Reauth Wait Timeout field is 4 octets in length and
corresponds to the "Reauthorize wait timeout" field of the 802.16
"PKM configuration settings" attribute
Auth Grace Time
The Auth Grace Time field is 4 octets in length and corresponds to
the "Authorize grace time" field of the 802.16 "PKM configuration
settings" attribute
Op Wait Timeout
The Op Wait Timeout field is 4 octets in length and corresponds to
the "Operational wait timeout" field of the 802.16 "PKM
configuration settings" attribute
Rekey Wait Timeout
The Rekey Wait Timeout field is 4 octets in length and corresponds
to the "Rekey wait timeout" field of the 802.16 "PKM configuration
settings" attribute
TEK Grace Time
The TEK Grace Time field is 4 octets in length and corresponds to
the "TEK grace time" field of the 802.16 "PKM configuration
settings" attribute
Auth Rej Wait Timeout
The Auth Rej Wait Timeout field is 4 octets in length and
corresponds to the "Authorize reject wait timeout" field of the
Zorn Expires August 13, 2010 [Page 8]

Internet-Draft RADIUS Attributes for PKMv1 February 2010
802.16 "PKM configuration settings" attribute
3.4. PKM-Cryptosuite-List
Description
The PKM-Cryptosuite-List Attribute is of type "string" [RFC2865]
and is variable length; it corresponds roughly to the
"Cryptographic-Suite-List" 802.16 attribute (see Section 11.19.15
of [IEEE.802.16-2004], the difference being that the RADIUS
Attribute contains only the list of 3-octet cryptographic suite
identifiers, omitting the IEEE Type and Length fields.
The PKM-Cryptosuite-List Attribute MAY be present in an Access-
Request message. Any message in which the PKM-Cryptosuite-List
Attribute is present MUST also contain an instance of the Message-
Authenticator Attribute [RFC3579].
Implementation Note
The PKM-Cryptosuite-List Attribute is used as a building block
to create the 802.16 "Security-Capabilities" attribute
([IEEE.802.16-2004], Section 11.9.13); since this document only
pertains to PKM version 1, the "Version" sub-attribute in that
structure MUST be set to 0x01 when the RADIUS client constructs
it.
A summary of the PKM-Cryptosuite-List Attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Len | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<TBD4> for PKM-Cryptosuite-List
Len
2 + 3n < 39, where 'n' is the number of cryptosuite identifiers in
the list.
Zorn Expires August 13, 2010 [Page 9]

Internet-Draft RADIUS Attributes for PKMv1 February 2010
Value
The Value field is variable length and contains a sequence of one
or more cryptosuite identifiers, each of which is 3 octets in
length and corresponds to the Value field of an IEEE 802.16
Cryptographic-Suite attribute
3.5. PKM-SAID
Description
The PKM-SAID Attribute is of type "string" [RFC2865]. It is 4
octets in length and contains a PKM Security Association
Identifier ([IEEE.802.16-2004], Section 11.9.7). It MAY be
included in an Access-Request message.
A summary of the PKM-SAID Attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Len | SAID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<TBD5> for PKM-SAID
Len
4
SAID
The SAID field is two octets in length and corresponds to the
Value field of the 802.16 PKM SAID attribute
3.6. PKM-SA-Descriptor
Description
The PKM-SA-Descriptor Attribute is of type "string" and is 8
octets in length. It contains three fields, described below,
which together specify the characteristics of a PKM security
association. One or more instances of the PKM-SA-Descriptor
Attribute MAY occur in an Access-Accept message.
Zorn Expires August 13, 2010 [Page 10]

Internet-Draft RADIUS Attributes for PKMv1 February 2010
A summary of the PKM-SA-Descriptor Attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Len | SAID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA Type | Cryptosuite |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<TBD6> for PKM-SA-Descriptor
Len
8
SAID
The SAID field is two octets in length and contains a PKM SAID
(Section 3.5).
SA Type
The SA Type field is one octet in length. The contents correspond
to those of the Value field of an IEEE 802.16 SA-Type attribute.
Cryptosuite
The Cryptosuite field is 3 octets in length. The contents
correspond to those of the Value field of an IEEE 802.16
Cryptographic-Suite attribute.
3.7. PKM-AUTH-Key
Description
The PKM-AUTH-Key Attribute is of type "string", 135 octets in
length. It consists of 3 fields, described below, which together
specify the characteristics of a PKM authorization key. The PKM-
AUTH-Key Attribute MAY occur in an Access-Accept message. Any
packet that contains an instance of the PKM-AUTH-Key Attribute
MUST also contain an instance of the Message-Authenticator
Attribute [RFC3579].
A summary of the PKM-AUTH-Key Attribute format is shown below. The
Zorn Expires August 13, 2010 [Page 11]

Internet-Draft RADIUS Attributes for PKMv1 February 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Len | Lifetime
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lifetime (cont.) | Sequence | Key...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<TBD7> for PKM-AUTH-Key
Len
135
Lifetime
The Lifetime field is 4 octets in length and represents the
lifetime, in seconds, of the authorization key. For more
information, see Section 11.9.4 of [IEEE.802.16-2004].
Sequence
The Sequence field is one octet in length. The contents
correspond to those of the Value field of an IEEE 802.16 Key-
Sequence-Number attribute (see [IEEE.802.16-2004], Section11.9.5).
Key
The Key field is 128 octets in length. The contents correspond to
those of the Value field of an IEEE 802.16 AUTH-Key attribute.
The Key field MUST be encrypted under the public key from the
Subscriber Station certificate (Section 3.1) using RSA encryption
[RFC2437]; see Section 7.5 of [IEEE.802.16-2004] for further
details.
4. Table of Attributes
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.
Zorn Expires August 13, 2010 [Page 12]

Internet-Draft RADIUS Attributes for PKMv1 February 2010
Request Accept Reject Challenge Acct-Req # Attribute
0+ 0 0 0 0 TBD1 PKM-SS-Cert [Note 1]
0+ 0 0 0 0 TBD2 PKM-CA-Cert [Note 2]
0 0-1 0 0 0 TBD3 PKM-Config-Settings
0-1 0 0 0 0 TBD4 PKM-Cryptosuite-List
0-1 0 0 0 0 TBD5 PKM-SAID
0 0+ 0 0 0 TBD6 PKM-SA-Descriptor
0 0-1 0 0 0 TBD7 PKM-Auth-Key
[Note 1]
No more than one Subscriber Station Certificate may be transferred
in an Access-Request packet.
[Note 2]
No more than one CA Certificate may be transferred in an Access-
Request packet.
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present in packet
0+ Zero or more instances of this attribute MAY be present in packet
0-1 Zero or one instance of this attribute MAY be present in packet
1 Exactly one instance of this attribute MUST be present in packet
5. Diameter Considerations
Since the Attributes defined in this document are allocated from the
standard RADIUS type space (see Section 6), no special handling is
required by Diameter nodes.
6. IANA Considerations
Upon publication of this document as an RFC, IANA must assign numbers
for the following Attributes:
<TBD1> PKM-SS-Cert
<TBD2> PKM-CA-Cert
<TBD3> PKM-Auth-Wait-Timeout
<TBD4> PKM-Cryptosuite-List
<TBD5> PKM-SAID
Zorn Expires August 13, 2010 [Page 13]

Internet-Draft RADIUS Attributes for PKMv1 February 2010
<TBD6> PKM-SA-Descriptor
<TBD7> PKM-Auth-Key
The Attribute numbers are to be allocated from the standard RADIUS
Attribute type space according to the "IETF Review" policy [RFC5226].
7. Security ConsiderationsSection 4 of RFC 3579 [RFC3579] discusses vulnerabilities of the
RADIUS protocol.
Section 3 of the paper "Security Enhancements for Privacy and Key
Management Protocol in IEEE 802.16e-2005" [SecEn] discusses the
operation and vulnerabilities of the PKMv1 protocol.
If the Access-Request message is not subject to strong integrity
protection, an attacker may be able to modify the contents of the
PKM-Cryptosuite-List Attribute, weakening 802.16 security or
disabling data encryption altogether.
If the Access-Accept message is not subject to strong integrity
protection, an attacker may be able to modify the contents of the
PKM-Auth-Key Attribute. For example, the Key field could be replaced
with a key known to the attacker.
Although it is necessary for a plaintext copy of the Key field in the
PKM-AUTH-Key Attribute to be transmitted in the Access-Accept
message, this document does not define a method for doing so
securely. In order to transfer the key securely, it is RECOMMENDED
that it be encapsulated in an instance of the MS-MPPE-Send-Key
Attribute [RFC2548]; however, see Section 4.3.4 of RFC 3579 [RFC3579]
for details regarding weaknesses in the encryption scheme used.
8. References8.1. Normative References
[IEEE.802.16-2004]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and metropolitan area networks, Part
16: Air Interface for Fixed Broadband Wireless Access
Systems", IEEE Standard 802.16, October 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Zorn Expires August 13, 2010 [Page 14]