RFC 5904 INFORMATIONAL AUTHENTICATION · KEY MANAGEMENT · WIRELESS
RADIUS for 802.16 PKMv1: RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support
RADIUS attributes for securing wireless broadband subscriptions
RFC EDITOR
Zorn, G., "RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support", RFC 5904, DOI 10.17487/RFC5904, June 2010, <https://www.rfc-editor.org/info/rfc5904>.
BIBTEX
@misc{rfc5904,
series = {Request for Comments},
number = 5904,
howpublished = {RFC 5904},
publisher = {RFC Editor},
doi = {10.17487/RFC5904},
url = {https://www.rfc-editor.org/info/rfc5904},
author = {G. Zorn},
title = {{RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support}},
pagetotal = 15,
year = 2010,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) G. Zorn
Request for Comments: 5904 Network Zen
Category: Informational June 2010
ISSN: 2070-1721
RADIUS Attributes for IEEE 802.16
Privacy Key Management Version 1 (PKMv1) Protocol Support
Abstract
This document defines a set of Remote Authentication Dial-In User
Service (RADIUS) Attributes that are designed to provide RADIUS
support for IEEE 802.16 Privacy Key Management Version 1.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5904.
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
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 Simplified 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. PKM-SS-Cert . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. PKM-CA-Cert . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. PKM-Config-Settings . . . . . . . . . . . . . . . . . . . 6
3.4. PKM-Cryptosuite-List . . . . . . . . . . . . . . . . . . . 8
3.5. PKM-SAID . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. PKM-SA-Descriptor . . . . . . . . . . . . . . . . . . . . 9
3.7. PKM-AUTH-Key . . . . . . . . . . . . . . . . . . . . . . . 10
3.7.1. AUTH-Key Protection . . . . . . . . . . . . . . . . . 12
4. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 12
5. Diameter Considerations . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. 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 an SS and BS.
This document defines a set of RADIUS Attributes that 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.
Please note that this document relies on IEEE.802.16-2004, which
references RFC 2437 and RFC 2459, rather than any more recent RFCs on
RSA and X.509 certificates (e.g., RFC 3447 and RFC 5280).
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
3. Attributes
The following subsections describe the Attributes defined by this
document. This specification concerns the following values:
137 PKM-SS-Cert
138 PKM-CA-Cert
139 PKM-Config-Settings
140 PKM-Cryptosuite-List
141 PKM-SAID
142 PKM-SA-Descriptor
143 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.
The minimum size of an SS certificate exceeds the maximum size of
a RADIUS attribute. Therefore, 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
137 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.
The minimum size of a CA certificate exceeds the maximum size of a
RADIUS attribute. Therefore, 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
138 for PKM-CA-Cert
Len
> 2
Value
The Value field is variable length and contains a (possibly
complete) portion of an X.509 certificate.
3.3. PKM-Config-Settings
Description
The PKM-Config-Settings Attribute is of type string [RFC2865]. It
is 30 octets in length and consists of seven independent fields,
each of which is conceptually an unsigned integer. Each of the
fields contains a timeout value and corresponds to a Type-Length-
Value (TLV) tuple encapsulated in the IEEE 802.16 "PKM
configuration settings" attribute; for details on the contents of
each field, see Section 11.9.19 of [IEEE.802.16-2004]. One
instance of the PKM-Config-Settings Attribute MAY be included in
the Access-Accept message.
A summary of the PKM-Config-Settings 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 | Auth Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Wait Timeout (cont.) | Reauth Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reauth Wait Timeout (cont.) | Auth Grace Time
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Grace Time (cont.) | Op Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Op Wait Timeout (cont.) | Rekey Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rekey Wait Timeout (cont.) | TEK Grace Time
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TEK Grace Time (cont.) | Auth Rej Wait Timeout
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Auth Rej Wait Timeout (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
139 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
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
140 for PKM-Cryptosuite-List
Len
2 + 3n < 39, where 'n' is the number of cryptosuite identifiers in
the list.
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
141 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.
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
142 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
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
143 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], Section
11.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.
Implementation Note
It is necessary that a plaintext copy of this field be returned
in the Access-Accept message; appropriate precautions MUST be
taken to ensure the confidentiality of the key.
3.7.1. AUTH-Key Protection
The PKM-AUTH-Key Attribute (Section 3.7) contains the AUTH-Key
encrypted with the SS's public key. The BS also needs the AK, so a
second copy of the AK needs to be returned in the Access-Accept
message.
It is RECOMMENDED that the AK is 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.
If better means for protecting the Auth-Key are available (such as
RADIUS key attributes with better security properties, or means of
protecting the whole Access-Accept message), they SHOULD be used
instead of (or in addition to) the MS-MPPE-Send-Key Attribute.
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.
Request Accept Reject Challenge Acct-Req # Attribute
0+ 0 0 0 0 137 PKM-SS-Cert [Note 1]
0+ 0 0 0 0 138 PKM-CA-Cert [Note 2]
0 0-1 0 0 0 139 PKM-Config-Settings
0-1 0 0 0 0 140 PKM-Cryptosuite-List
0-1 0 0 0 0 141 PKM-SAID
0 0+ 0 0 0 142 PKM-SA-Descriptor
0 0-1 0 0 0 143 PKM-Auth-Key
0 0-1 0 0 0 MS-MPPE-Send-Key
[Note 3]
[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.
[Note 3]
MS-MPPE-Send-Key is one possible attribute that can be used to
convey the AK to the BS; other attributes can be used instead (see
Section 3.7.1).
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 7), no special handling is
required by Diameter nodes.
6. Security Considerations
Section 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.
See Section 3.7.1 for security considerations of sending the
authorization key to the BS.
7. IANA Considerations
IANA has assigned numbers for the following Attributes:
137 PKM-SS-Cert
138 PKM-CA-Cert
139 PKM-Config-Settings
140 PKM-Cryptosuite-List
141 PKM-SAID
142 PKM-SA-Descriptor
143 PKM-Auth-Key
The Attribute numbers are to be allocated from the standard RADIUS
Attribute type space according to the "IETF Review" policy [RFC5226].
8. Contributors
Pasi Eronen provided most of the text in Section 3.7.1.
9. Acknowledgements
Thanks (in no particular order) to Bernard Aboba, Donald Eastlake,
Dan Romascanu, Avshalom Houri, Juergen Quittek, Pasi Eronen, and Alan
DeKok for their mostly useful reviews of this document.
10. References
10.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.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, 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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
10.2. Informative References
[RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
[RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[SecEn] Altaf, A., Jawad, M., and A. Ahmed, "Security Enhancements
for Privacy and Key Management Protocol in IEEE 802.16e-
2005", Ninth ACIS International Conference on Software
Engineering, Artificial Intelligence, Networking, and
Parallel/Distributed Computing, 2008.
Author's Address
Glen Zorn
Network Zen
1463 East Republican Street
#358
Seattle, WA 98112
US
EMail: gwz@net-zen.net
AI ELI5
On this page
PROBLEMIEEE 802.16 fixed wireless broadband networks need to authenticate subscriber stations and exchange encryption keys, but RADIUS servers do not have a standard way to carry this key management information.
MECHANISMSeven new RADIUS attributes are defined to carry certificates, configuration settings, cryptographic suites, security association identifiers, and encryption keys between the access network and the authentication server.
INFORMATIONAL SPECIFICATIONThis enables RADIUS servers to manage key establishment and maintenance for 802.16 networks using PKMv1 protocol.
§1Authentication and Keys in Wireless Networks
IEEE 802.16 defines fixed wireless broadband systems where a Base Station communicates with Subscriber Stations. Privacy Key Management Version 1 (PKMv1) is a public-key-based protocol that lets the Base Station authenticate each subscriber and establish encryption keys for their traffic. PKMv1 uses X.509 certificates and RSA encryption to prove the identity of both the Base Station and the subscriber.
In many networks, authentication is delegated to a separate RADIUS server (Remote Authentication Dial-In User Service), which manages user credentials and authorization policies. However, RADIUS was designed for dial-up networks and does not have standard attributes for PKMv1's key management information. This document defines those attributes.
A wireless tower and an office computer with passwords need to talk about who can connect and what secret codes to use. RADIUS is the translator, but it did not have the right words for wireless keys. These are the new words.
§2The Seven RADIUS Attributes
This RFC defines seven new RADIUS attributes, assigned type numbers 137 through 143. The PKM-SS-Cert attribute carries the Subscriber Station's X.509 certificate. Because certificates can exceed RADIUS's maximum attribute size of 255 octets, large certificates are split across multiple attributes and reassembled by the server.
The PKM-CA-Cert attribute similarly carries the Certification Authority's certificate that signed the subscriber's certificate. The PKM-Config-Settings attribute is exactly 30 octets and bundles seven timeout values that control PKMv1 behavior, such as authentication wait times, re-authentication delays, and grace periods.
The PKM-Cryptosuite-List attribute specifies which encryption algorithms are available. The PKM-SAID attribute (4 octets) identifies a Security Association by a numeric identifier. The PKM-SA-Descriptor attribute (8 octets) packages a Security Association identifier with its type and cryptographic suite. Finally, the PKM-AUTH-Key attribute (135 octets) carries the authorization key, encrypted under the subscriber's public key using RSA encryption.
Think of these as seven different envelopes. One holds the subscriber's ID card, one holds the CA's card, one lists what encryption codes are okay, one marks which agreement is which. The last one holds the secret key locked with the subscriber's personal lock.
§3How the Attributes Are Used
When a Subscriber Station requests access, it sends an Access-Request message containing its certificate in one or more PKM-SS-Cert attributes and the CA certificate in PKM-CA-Cert attributes. It may also include the list of supported cryptographic suites and a Security Association identifier.
The RADIUS server processes these attributes, validates the certificates, and generates encryption keys. It responds with an Access-Accept message that includes the PKM-Config-Settings to tell the Base Station what timeouts to use, one or more PKM-SA-Descriptor attributes to describe the security associations, and the encrypted PKM-AUTH-Key. The authorization key itself must also be conveyed to the Base Station; the RFC recommends encapsulating it in the MS-MPPE-Send-Key attribute for protection.
The subscriber station says 'here's my ID and my encryption options.' The RADIUS server checks them and sends back 'okay, here are the timeout rules and your secret key.'
§4Security Concerns
RADIUS as a protocol has known vulnerabilities discussed in RFC 3579. The cryptosuite list is particularly sensitive: if an attacker can modify it without detection, they might force weak encryption or disable encryption entirely. Similarly, if the authorization key attribute is not protected during transmission, an attacker could replace it with a key under their control, compromising the entire session.
The PKM-AUTH-Key attribute must always be accompanied by the Message-Authenticator attribute to ensure its integrity. Additionally, the document recommends that the authorization key sent to the Base Station be protected with strong encryption beyond standard RADIUS protection, noting that the MS-MPPE-Send-Key method has known weaknesses documented in RFC 3579.
Someone on the network could try to swap out the secret key or change the allowed encryption codes. The RADIUS server needs to use special tricks to make sure no one tamperes with these messages.
§5Status Today
RFC 5904 is an Informational specification published in June 2010. It has not been obsoleted or updated, so it remains the standard definition of how to extend RADIUS for IEEE 802.16 PKMv1 support. The attributes are registered with IANA and available for implementation.
This is still the official rulebook for these envelopes. It is not a candidate to become an official Internet Standard, but it is the published answer to the problem.
§6References
[RFC2865]RFC 2865Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.June 2000[RFC3579]RFC 3579Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.September 2003[RFC2459]RFC 2459Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.January 1999[RFC2437]RFC 2437Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.October 1998[RFC2548]RFC 2548Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.March 1999