One document matched: draft-zorn-radius-pkmv1-12.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2459 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2459.xml">
<!ENTITY RFC2437 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2437.xml">
<!ENTITY RFC2548 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2548.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC3579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-zorn-radius-pkmv1-12" ipr="pre5378Trust200902">
<!-- category values: std, bcp, info, exp, and historic -->
<front>
<title abbrev="RADIUS Attributes for PKMv1">
RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support
</title>
<author fullname="Glen Zorn" initials="G.Z." surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>1463 East Republican Street </street>
<street>#358</street>
<city>Seattle</city>
<region>WA</region>
<code>98112</code>
<country>US</country>
</postal>
<email>gwz@net-zen.net</email>
</address>
</author>
<date year="2010"/>
<keyword>RADIUS</keyword>
<keyword>AAA</keyword>
<keyword>IEEE</keyword>
<keyword>802.16</keyword>
<abstract>
<t>
This document defines a set of RADIUS Attributes which are designed
to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Privacy Key Management Version 1 (PKMv1) <xref target="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 <xref target="RFC2459"/>,
RSA encryption <xref target="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.
<vspace blankLines="1"/>
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 <xref target="RFC2865"/> and
the IEEE 802.16-2004 standard is assumed.
<vspace blankLines="1"/>
Discussion of this draft may be directed to the author.
</t>
</section>
<section title="Acronyms">
<t>
<list style="hanging" hangIndent="2">
<t hangText="CA">
<vspace blankLines="0"/>
Certification Authority; a trusted party issuing and signing X.509 certificates.
</t>
</list>
For further information on the following terms, please see Section 7 of <xref target="IEEE.802.16-2004"/>.
<list style="hanging" hangIndent="2">
<t hangText="SA">
<vspace blankLines="0"/>
Security Association
</t>
<t hangText="SAID">
<vspace blankLines="0"/>
Security Association Identifier
</t>
<t hangText="TEK">
<vspace blankLines="0"/>
Traffic Encryption Key
</t>
</list>
</t>
</section>
<section title="Attributes">
<t>
The following subsections describe the Attributes defined by this document.
This specification concerns the following values:
<list>
<t><TBD1> PKM-SS-Cert</t>
<t><TBD2> PKM-CA-Cert</t>
<t><TBD3> PKM-Config-Settings</t>
<t><TBD4> PKM-Cryptosuite-List</t>
<t><TBD5> PKM-SAID</t>
<t><TBD6> PKM-SA-Descriptor</t>
<t><TBD7> PKM-Auth-Key</t>
</list>
</t>
<section title="PKM-SS-Cert" anchor="SSC">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
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 <xref target="RFC2459"/>
binding a public key to the identifier of the Subscriber Station.
<vspace blankLines="1"/>
The minimum size of a 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.
</t>
</list>
A summary of the PKM-SS-Cert Attribute format is shown below. The fields are transmitted from left to right.
<figure>
<artwork> <![CDATA[
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
</figure>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
<TBD1> for PKM-SS-Cert
</t>
<t hangText="Len">
<vspace blankLines="1"/>
> 2
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The Value field is variable length and contains a (possibly complete) portion of an X.509 certificate.
</t>
</list>
</t>
</section>
<section title="PKM-CA-Cert" anchor="CAC">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
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 <xref target="RFC2459"/>
used by
the CA to sign the SS certificate carried in the PKM-SS-Cert
attribute (<xref target="SSC"/>)
in the same message.
<vspace blankLines="1"/>
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.
</t>
</list>
A summary of the PKM-CA-Cert Attribute format is shown below.
The fields are transmitted from left to right.
<figure>
<artwork> <![CDATA[
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
</figure>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
<TBD2> for PKM-CA-Cert
</t>
<t hangText="Len">
<vspace blankLines="1"/>
> 2
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The Value field is variable length and contains a (possibly complete) portion of an X.509 certificate.
</t>
</list>
</t>
</section>
<section title="PKM-Config-Settings">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The PKM-Config-Settings Attribute is of type "string" <xref target="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 <xref target="IEEE.802.16-2004"/>
One instance of the PKM-Config-Settings Attribute MAY be included in the Access-Accept message.
</t>
</list>
A summary of the PKM-Config-Settings Attribute format is shown below.
The fields are transmitted from left to right.
<figure>
<artwork> <![CDATA[
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.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
</figure>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
<TBD3> for PKM-Config-Settings
</t>
<t hangText="Len">
<vspace blankLines="1"/>
30
</t>
<t hangText="Auth Wait Timeout">
<vspace blankLines="1"/>
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
</t>
<t hangText="Reauth Wait Timeout">
<vspace blankLines="1"/>
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
</t>
<t hangText="Auth Grace Time">
<vspace blankLines="1"/>
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
</t>
<t hangText="Op Wait Timeout">
<vspace blankLines="1"/>
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
</t>
<t hangText="Rekey Wait Timeout">
<vspace blankLines="1"/>
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
</t>
<t hangText="TEK Grace Time">
<vspace blankLines="1"/>
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
</t>
<t hangText="Auth Rej Wait Timeout">
<vspace blankLines="1"/>
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
</t>
</list>
</t>
</section>
<section title="PKM-Cryptosuite-List">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
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 <xref target="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.
<vspace blankLines="1"/>
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 <xref target="RFC3579"/>.
<list style="hanging">
<t hangText="Implementation Note">
<vspace blankLines="1"/>
The PKM-Cryptosuite-List Attribute is used as a building block
to create the 802.16 "Security-Capabilities" attribute (<xref target="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.
</t>
</list>
</t>
</list>
A summary of the PKM-Cryptosuite-List Attribute format is shown below. The fields are transmitted from left to right.
<figure>
<artwork> <![CDATA[
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
</figure>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
<TBD4> for PKM-Cryptosuite-List
</t>
<t hangText="Len">
<vspace blankLines="1"/>
2 + 3n < 39, where 'n' is the number of cryptosuite identifiers in the list.
</t>
<t hangText="Value">
<vspace blankLines="1"/>
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
</t>
</list>
</t>
</section>
<section title="PKM-SAID" anchor="SAID">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
The PKM-SAID Attribute is of type "string" <xref target="RFC2865"/>.
It is 4 octets in
length and contains a PKM Security Association Identifier
(<xref target="IEEE.802.16-2004"/>, Section 11.9.7).
It MAY be included in an Access-Request message.
</t>
</list>
A summary of the PKM-SAID Attribute format is shown below. The
fields are transmitted from left to right.
<figure>
<artwork> <![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
</figure>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
<TBD5> for PKM-SAID
</t>
<t hangText="Len">
<vspace blankLines="1"/>
4
</t>
<t hangText="SAID">
<vspace blankLines="1"/>
The SAID field is two octets in length and corresponds to the Value field of the 802.16 PKM SAID attribute
</t>
</list>
</t>
</section>
<section title="PKM-SA-Descriptor">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
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.
</t>
</list>
A summary of the PKM-SA-Descriptor Attribute format is shown below.
The fields are transmitted from left to right.
<figure>
<artwork> <![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
</figure>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
<TBD6> for PKM-SA-Descriptor
</t>
<t hangText="Len">
<vspace blankLines="1"/>
8
</t>
<t hangText="SAID">
<vspace blankLines="1"/>
The SAID field is two octets in length and contains a PKM SAID (<xref target="SAID"/>).
</t>
<t hangText="SA Type">
<vspace blankLines="1"/>
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.
</t>
<t hangText="Cryptosuite">
<vspace blankLines="1"/>
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.
</t>
</list>
</t>
</section>
<section title="PKM-AUTH-Key" anchor="P-A-K">
<t>
<list style="hanging">
<t hangText="Description">
<vspace blankLines="1"/>
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 <xref target="RFC3579"/>.
</t>
</list>
A summary of the PKM-AUTH-Key Attribute format is shown below. The fields are transmitted from left to right.
<figure>
<artwork> <![CDATA[
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> </artwork>
</figure>
<list style="hanging">
<t hangText="Type">
<vspace blankLines="1"/>
<TBD7> for PKM-AUTH-Key
</t>
<t hangText="Len">
<vspace blankLines="1"/>
135
</t>
<t hangText="Lifetime">
<vspace blankLines="1"/>
The Lifetime field is 4 octets in length and represents the lifetime, in seconds, of the authorization key.
For more information, see <xref target="IEEE.802.16-2004"> Section 11.9.4 of</xref>.
</t>
<t hangText="Sequence">
<vspace blankLines="1"/>
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 <xref target="IEEE.802.16-2004"/>, Section 11.9.5).
</t>
<t hangText="Key">
<vspace blankLines="1"/>
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 (<xref target="SSC"/>)
using RSA encryption <xref target="RFC2437"/>; see Section 7.5 of <xref target="IEEE.802.16-2004"/>
for further details.
<list style="hanging">
<t hangText="Implementation Note">
<vspace blankLines="1"/>
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.
</t>
</list>
</t>
</list>
</t>
<section title="AUTH-Key Protection" anchor="AKP">
<t>
The PKM-AUTH-Key Attribute <xref target="P-A-K"/>
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.
<vspace blankLines="1"/>
It is RECOMMENDED that the AK is encapsulated in an instance of the
MS-MPPE-Send-Key Attribute <xref target="RFC2548"/>.
However, see Section 4.3.4 of RFC 3579 <xref target="RFC3579"/>
for details regarding weaknesses in the encryption scheme used.
<vspace blankLines="1"/>
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.
</t>
</section>
</section>
</section>
<section title="Table of Attributes">
<t>
The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity.
<figure>
<artwork> <![CDATA[
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
0 0-1 0 0 0 MS-MPPE-Send-Key
[Note 3]
]]> </artwork>
</figure>
<list style="hanging">
<t hangText="[Note 1]">
<vspace blankLines="0"/>
No more than one Subscriber Station Certificate
may be transferred in an Access-Request packet.
</t>
<t hangText="[Note 2]">
<vspace blankLines="0"/>
No more than one CA Certificate
may be transferred in an Access-Request packet.
</t>
<t hangText="[Note 3]">
<vspace blankLines="0"/>
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 <xref target="AKP"/>.
</t>
</list>
The following table defines the meaning of the above table entries.
<figure align="left" >
<artwork> <![CDATA[
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
]]> </artwork>
</figure>
</t>
</section>
<section title="Diameter Considerations">
<t>
Since the Attributes defined in this document are allocated from the standard RADIUS type space
(see <xref target="IANA"/>),
no special handling is required by Diameter nodes.
</t>
</section>
<section title="Security Considerations">
<t>
Section 4 of <xref target="RFC3579">RFC 3579</xref> discusses vulnerabilities of the RADIUS protocol.
<vspace blankLines="1"/>
Section 3 of <xref target="SecEn">the paper "Security Enhancements for Privacy and Key Management Protocol in IEEE 802.16e-2005"</xref>
discusses the operation and vulnerabilities of the PKMv1 protocol.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
See <xref target="AKP"/> for security considerations of sending the authorization key to the BS.
</t>
</section>
<section title="IANA Considerations" anchor="IANA">
<t>
Upon publication of this document as an RFC, IANA must assign numbers for the following Attributes:
<list>
<t><TBD1> PKM-SS-Cert</t>
<t><TBD2> PKM-CA-Cert</t>
<t><TBD3> PKM-Auth-Wait-Timeout</t>
<t><TBD4> PKM-Cryptosuite-List</t>
<t><TBD5> PKM-SAID</t>
<t><TBD6> PKM-SA-Descriptor</t>
<t><TBD7> PKM-Auth-Key</t>
</list>
The Attribute numbers are to be allocated from the standard RADIUS
Attribute type space according to the "IETF Review" policy <xref target="RFC5226"/>.
</t>
</section>
<section title="Contributors">
<t>
Pasi Eronen provided most of the text in <xref target="AKP"/>.
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks (in no particular order) to Bernard Aboba, Donald Eastlake, Dan Romascanu, Avshalom Houri, Juergen Quittek
and Alan DeKok for their mostly useful reviews of this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC5226;
&RFC2865;
&RFC3579;
<reference anchor="IEEE.802.16-2004">
<front>
<title>IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems</title>
<author>
<organization>Institute of Electrical and Electronics Engineers</organization>
</author>
<date month="October" year="2004" />
</front>
<seriesInfo name="IEEE" value="Standard 802.16" />
</reference>
</references>
<references title="Informative References">
&RFC2459;
&RFC2437;
&RFC2548;
<reference anchor="SecEn">
<front>
<title>Security Enhancements for Privacy and Key Management Protocol in IEEE 802.16e-2005</title>
<author fullname="Ayesha Altaf" initials="A.A." surname="Altaf">
<organization>College of Signals, NUST</organization>
<address>
<email>ayeshaaltaf@mcs.edu.pk</email>
</address>
</author>
<author fullname="M. Younus Javed" initials="M.Y.J." surname="Jawad">
<organization>College 0f E&ME, NUST</organization>
<address>
<email>myjaved@ceme.edu.pk</email>
</address>
</author>
<author fullname="Attiq Ahmed" initials="A.A" surname="Ahmed">
<organization>College of Signals, NUST</organization>
<address>
<email>attiq-mcs@nust.edu.pk</email>
</address>
</author>
<date year="2008"/>
</front>
<seriesInfo name="Ninth"
value="ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 07:43:38 |