One document matched: draft-manner-nsis-nslp-auth-04.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY qosnslp PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-qos-nslp.xml'>
<!ENTITY natfwnslp PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-nslp-natfw.xml'>
<!ENTITY ntlp PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-ntlp.xml'>
<!ENTITY rfc3520 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3520.xml'>
<!ENTITY rfc3521 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3521.xml'>
<!ENTITY rfc2104 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml'>
<!ENTITY rfc1321 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1321.xml'>
<!ENTITY rfc4080 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4080.xml'>
<!ENTITY rfc4081 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4081.xml'>
<!ENTITY rfc3852 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3852.xml'>
<!ENTITY rfc3447 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3447.xml'>
<!ENTITY rfc4306 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
]>
<rfc category="std" ipr="full3978" docName="draft-manner-nsis-nslp-auth-04.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev='NSLP AUTH'>
Authorization for NSIS Signaling Layer Protocols
</title>
<author initials='J.' surname="Manner" fullname='Jukka Manner'>
<organization abbrev='TKK'>Helsinki University of Technology (TKK)</organization>
<address>
<postal>
<street>P.O. Box 3000</street>
<city>Espoo</city> <code>FI-02015 TKK</code>
<country>Finland</country>
</postal>
<phone>+358 9 451 2481</phone>
<email>jukka.manner@tkk.fi</email>
</address>
</author>
<author initials="M." surname="Stiemerling" fullname="Martin
Stiemerling">
<organization abbrev="NEC">Network Laboratories, NEC Europe
Ltd.</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<phone>+49 (0) 6221 4342 113</phone>
<email>stiemerling@nw.neclab.eu</email>
<uri> http://www.stiemerling.org </uri>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="R." surname="Bless" fullname="Roland Bless">
<organization abbrev="Univ. of Karlsruhe">
Institute of Telematics, Universitaet Karlsruhe (TH)
</organization>
<address>
<postal>
<street>Zirkel 2, Building 20.20</street>
<city>Karlsruhe</city>
<code>76131</code>
<country>Germany</country>
</postal>
<phone>+49 721 608 6413</phone>
<email>bless@tm.uka.de</email>
<uri>http://www.tm.uka.de/~bless</uri>
</address>
</author>
<date month="July" year="2008"/>
<abstract>
<t>
Signaling layer protocols in the NSIS working group may rely on GIST
to handle authorization. Still, the signaling layer
protocol itself may require separate authorization to be performed when a
node receives a request for a certain kind of service or resources.
This draft presents a generic model and object formats for session
authorization within the NSIS Signaling Layer Protocols. The goal of
session authorization is to allow the exchange of information between
network elements in order to authorize the use of resources for a
service and to coordinate actions between the signaling and
transport planes.
</t>
</abstract>
</front>
<middle>
<section title="Conventions used in this document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
<xref target="RFC2119" />.
</t>
<t>
The term "NSLP node" (NN) is used to refer to an NSIS node running an
NSLP protocol that can make use of the authorization object discussed in
this document. Currently, this node would run either the QoS or the
NAT/FW NSLP service.
</t>
</section>
<section title="Introduction">
<t>
The NSIS working group is specifying a suite of protocols for the next
generation in Internet signaling <xref target="RFC4080" />. The design
is based on a generalized transport protocol for signaling applications,
the General Internet Signaling Transport (GIST) <xref
target="I-D.ietf-nsis-ntlp" />, and various kinds of signaling
applications. Two signaling applications and their NSIS Signaling Layer
Protocol (NSLP) have been designed, a Quality of Service application
(QoS NSLP) <xref target="I-D.ietf-nsis-qos-nslp" /> and a NAT/firewall
application (NAT/FW) <xref target="I-D.ietf-nsis-nslp-natfw" />.
</t>
<t>
The security architecture is based on a chain-of-trust model, where
each GIST hop may chose the appropriate security protocol, taking
into account the signaling application requirements. This model is
appropriate for a number of different use cases, and allows the
signaling applications to leave the handling of security to GIST.
</t>
<t>
Yet, in order to allow for finer-grain per-session or per-user admission control,
it is necessary to provide a mechanism for ensuring that the use of
resources by a host has been properly authorized before allowing the
signaling application to commit the resource request, e.g., a QoS
reservation or mappings for NAT traversal. In order to meet this
requirement,there must be information in the NSLP message which may
be used to verify the validity of the request. This can be done by
providing the host with a session authorization policy element which
is inserted into the message and verified by the network.
</t>
<t>
This document describes a generic NSLP layer session authorization
policy object (AUTH_SESSION) used to convey authorization information
for the request. The scheme is based on third-party tokens. A trusted
third party provides authentication tokens to clients and allows
verification of the information by the network elements. The requesting
host inserts its authorization information acquired from the trusted
third party into the NSLP message to allow verification of the network
resource request. Network elements verify the request and then process
the resource reservation message based on admission policy. This work is
based on RFC 3520 <xref target="RFC3520" /> and RFC 3521 <xref
target="RFC3521" />.
</t>
<t>
The default operation of the authorization is to add one authorization
policy object. Yet, in order to support end-to-end signaling and request
authorization from different networks, a host initiating an NSLP
signaling session may add more than one AUTH_SESSION object in the
message. The identifier of the authorizing entity can be used by the
network elements to use the third party they trust to verify the
request.
</t>
</section>
<section title="Session Authorization Object" anchor='sec-session-auth-object-formats'>
<t>
This section presents a new NSLP layer object called session
authorization (AUTH_SESSION). The AUTH_SESSION object can be used in
the currently specified and future NSLP protocols.
</t>
<t>
The authorization attributes follow the format and specification
given in RFC3520 <xref target="RFC3520" />.
</t>
<section title="Session Authorization Object format">
<t>
The AUTH_SESSION object contains a list of fields which describe
the session, along with other attributes. The object header follows
the generic NSLP object header.
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
// Session Authorization Attribute List //
+ +
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
The value for the Type field comes from shared NSLP object type space.
The Length field is given in units of 32 bit words and measures the
length of the Value component of the TLV object (i.e. it does not
include the standard header).
</t>
<t>
The bits marked 'A' and 'B' are extensibility flags, and used to
signal the desired treatment for objects whose treatment has not been
defined in the protocol specification (i.e. whose Type field is
unknown at the receiver). The following four categories of object
have been identified, and are described here.
</t>
<t>
AB=00 ("Mandatory"): If the object is not understood, the entire
message containing it MUST be rejected with a "Object Type Error"
message with subcode 1 ("Unrecognised Object"). In the NATFW NSLP
case it MUST be rejected with an error response of class 'Protocol
error' (0x3) with error code 'Unknown object present' (0x06).
</t>
<t>
AB=01 ("Ignore"): If the object is not understood, it MUST be deleted
and the rest of the message processed as usual.
</t>
<t>
AB=10 ("Forward"): If the object is not understood, it MUST be
retained unchanged in any message forwarded as a result of message
processing, but not stored locally.
</t>
<t>
AB=11 ("Refresh"): If the object is not understood, it should be
incorporated into the locally stored signaling application state for
this flow/session, forwarded in any resulting message, and also used
in any refresh or repair message which is generated locally. In the
NATFW NSLP this combination AB=11 MUST NOT be used and an error
response of class 'Protocol error' (0x3) with error code 'Invalid
Flag-Field combination' (0x09) MUST be generated.
</t>
<t>
The remaining bits marked 'r' are reserved. The extensibility flags
follow the definition in the GIST specification. The AUTH_SESSION object
defines in this specification MUST have the AB-bits set to "10". An NN
may use the authorization information if it is configured to do so, but
may also just skip the object.
</t>
<t>
Type: 0x0a (TBD by IANA)
</t>
<t>
Length: Variable
</t>
<t>
Session Authorization Attribute List: variable length
</t>
<t>
<list style="empty">
<t>
The session authorization attribute list is a collection of objects
which describes the session and provides other information necessary
to verify the resource reservation request. An initial set of valid
objects is described in Section 3.2.
</t>
</list>
</t>
</section>
<section title="Session Authorization Attributes">
<t>
A session authorization attribute may contain a variety of information
and has both an attribute type and subtype. The attribute itself MUST be
a multiple of 4 octets in length, and any attributes that are not a
multiple of 4 octets long MUST be padded to a 4-octet boundary. All
padding bytes MUST have a value of zero.
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value ... //
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
Length: 16 bits
</t>
<t>
<list style="empty">
<t>
The length field is two octets and indicates the actual length of the
attribute (including Length, X-Type and SubType fields) in number of
octets. The length does NOT include any bytes padding to the value field
to make the attribute a multiple of 4 octets long.
</t>
</list>
</t>
<t>
X-Type: 8 bits
</t>
<t>
<list style="empty">
<t>
Session authorization attribute type (X-Type) field is one octet. IANA
acts as a registry for X-Types as described in Section 7, IANA
Considerations. Initially, the registry contains the following X-Types:
</t>
</list>
</t>
<t>
<list style="numbers">
<t>
AUTH_ENT_ID The unique identifier of the entity that
authorized the session.
</t>
<t>
SOURCE_ADDR Address specification for the signaling
session initiator, i.e., the source address
of the signaling message originator.
</t>
<t>
DEST_ADDR Address specification for the signaling
session end-point.
</t>
<t>
START_TIME The starting time for the session.
</t>
<t>
END_TIME The end time for the session.
</t>
<t>
AUTHENTICATION_DATA Authentication data of the session
authorization policy element.
</t>
</list>
</t>
<t>
SubType: 8 bits
</t>
<t>
<list style="empty">
<t>
Session authorization attribute sub-type is one octet in length. The
value of the SubType depends on the X-Type.
</t>
</list>
</t>
<t>
Value: variable length
</t>
<t>
<list style="empty">
<t>
The attribute specific information.
</t>
</list>
</t>
<section title="Authorizing Entity Identifier">
<t>
AUTH_ENT_ID is used to identify the entity which authorized the
initial service request and generated the session authorization
policy element. The AUTH_ENT_ID may be represented in various
formats, and the SubType is used to define the format for the ID. The
format for AUTH_ENT_ID is as follows:
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
Length: Length of the attribute, which MUST be > 4.
</t>
<t>
X-Type: AUTH_ENT_ID
</t>
<t>
SubType:
</t>
<t>
<list style="empty">
<t>
The following sub-types for AUTH_ENT_ID are defined. IANA acts as a
registry for AUTH_ENT_ID sub-types as described in Section 7, IANA
Considerations. Initially, the registry contains the following
sub-types of AUTH_ENT_ID:
</t>
</list>
</t>
<t>
<list style="numbers">
<t>
IPV4_ADDRESS IPv4 address represented in 32 bits
</t>
<t>
IPV6_ADDRESS IPv6 address represented in 128 bits
</t>
<t>
FQDN Fully Qualified Domain Name as defined in
RFC 1034 as an ASCII string.
</t>
<t>
ASCII_DN X.500 Distinguished name as defined in RFC
2253 as an ASCII string.
</t>
<t>
UNICODE_DN X.500 Distinguished name as defined in RFC
2253 as a UTF-8 string.
</t>
<t>
URI Universal Resource Identifier, as defined
in RFC 2396.
</t>
<t>
KRB_PRINCIPAL Fully Qualified Kerberos Principal name
represented by the ASCII string of a
principal followed by the @ realm name as
defined in RFC 1510 (e.g.,
johndoe@nowhere).
</t>
<t>
X509_V3_CERT The Distinguished Name of the subject of
the certificate as defined in RFC 2253 as a
UTF-8 string.
</t>
<t>
PGP_CERT The PGP digital certificate of the
authorizing entity as defined in RFC 2440.
</t>
<t>
HMAC_SIGNED Indicates that the AUTHENTICATION_DATA attribute
contains a self-signed HMAC signature <xref target="RFC2104" />
that ensures the integrity of the NSLP message. The HMAC is
calculated over all NSLP objects given in the
NSLP_OBJECT_LIST attribute that MUST also be
present. The AUTH_ENT_ID contains the Hash
Algorithm that is used for calculation of the HMAC
as Transform ID from Transform Type 3 of the IKEv2
registry <xref target="RFC4306" />.
</t>
</list>
</t>
<t>
OctetString: Contains the authorizing entity identifier.
</t>
</section>
<section title="Source Address">
<t>
SOURCE_ADDR is used to identify the source address specification of
the authorized session. This X-Type may be useful in some scenarios
to make sure the resource request has been authorized for that
particular source address and/or port.
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
Length: Length of the attribute, which MUST be > 4.
</t>
<t>
X-Type: SOURCE_ADDR
</t>
<t>
SubType:
</t>
<t>
<list style="empty">
<t>
The following sub types for SOURCE_ADDR are defined. IANA acts as
a registry for SOURCE_ADDR sub-types as described in Section 7,
IANA Considerations. Initially, the registry contains the
following sub types for SOURCE_ADDR:
</t>
</list>
</t>
<t>
<list style="numbers">
<t>
IPV4_ADDRESS IPv4 address represented in 32 bits
</t>
<t>
IPV6_ADDRESS IPv6 address represented in 128 bits
</t>
<t>
UDP_PORT_LIST list of UDP port specifications,
represented as 16 bits per list entry.
</t>
<t>
TCP_PORT_LIST list of TCP port specifications,
represented as 16 bits per list entry.
</t>
<t>
SPI Security Parameter Index represented in 32
bits
</t>
</list>
</t>
<t>
OctetString: The OctetString contains the source address information.
</t>
<t>
In scenarios where a source address is required (see <xref target='sec-framework'></xref>),
at least one of the subtypes 1 or 2 MUST be included in every Session
Authorization Data Policy Element. Multiple SOURCE_ADDR attributes MAY
be included if multiple addresses have been authorized. The source
address of the request (e.g., a QoS NSLP RESERVE) MUST match one of the
SOURCE_ADDR attributes contained in this Session Authorization Data
Policy Element.
</t>
<t>
At most, one instance of subtype 3 MAY be included in every Session
Authorization Data Policy Element. At most, one instance of subtype 4
MAY be included in every Session Authorization Data Policy Element.
Inclusion of a subtype 3 attribute does not prevent inclusion of a
subtype 4 attribute (i.e., both UDP and TCP ports may be authorized).
</t>
<t>
If no PORT attributes are specified, then all ports are considered
valid; otherwise, only the specified ports are authorized for use. Every
source address and port list must be included in a separate SOURCE_ADDR
attribute.
</t>
</section>
<section title="Destination Address">
<t>
DEST_ADDR is used to identify the destination address of the
authorized session. This X-Type may be useful in some scenarios to
make sure the resource request has been authorized for that
particular destination address and/or port.
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
Length: Length of the attribute in number of octects, which MUST be > 4.
</t>
<t>
X-Type: DEST_ADDR
</t>
<t>
SubType:
</t>
<t>
<list style="empty">
<t>
The following sub types for DEST_ADDR are defined. IANA acts as a
registry for DEST_ADDR sub-types as described in Section 7, IANA
Considerations. Initially, the registry contains the following sub
types for DEST_ADDR:
</t>
</list>
</t>
<t>
<list style="numbers">
<t>
IPV4_ADDRESS IPv4 address represented in 32 bits
</t>
<t>
IPV6_ADDRESS IPv6 address represented in 128 bits
</t>
<t>
UDP_PORT_LIST list of UDP port specifications,
represented as 16 bits per list entry.
</t>
<t>
TCP_PORT_LIST list of TCP port specifications,
represented as 16 bits per list entry.
</t>
<t>
SPI Security Parameter Index represented in 32
bits
</t>
</list>
</t>
<t>
OctetString: The OctetString contains the destination address specification.
</t>
<t>
In scenarios where a destination address is required (see <xref target='sec-framework'></xref>),
at least one of the subtypes 1 or 2 MUST be included
in every Session Authorization Data Policy Element. Multiple
DEST_ADDR attributes MAY be included if multiple addresses have been
authorized. The destination address field of the resource reservation
datagram (e.g., QoS NSLP Reserve) MUST match one of the DEST_ADDR attributes
contained in this Session Authorization Data Policy Element.
</t>
<t>
At most, one instance of subtype 3 MAY be included in every Session
Authorization Data Policy Element. At most, one instance of subtype 4
MAY be included in every Session Authorization Data Policy Element.
Inclusion of a subtype 3 attribute does not prevent inclusion of a
subtype 4 attribute (i.e., both UDP and TCP ports may be authorized).
</t>
<t>
If no PORT attributes are specified, then all ports are considered
valid; otherwise, only the specified ports are authorized for use.
</t>
<t>
Every destination address and port list must be included in a
separate DEST_ADDR attribute.
</t>
</section>
<section title="Start time">
<t>
START_TIME is used to identify the start time of the authorized session
and can be used to prevent replay attacks. If the AUTH_SESSION policy
element is presented in a resource request, the network SHOULD reject
the request if it is not received within a few seconds of the start time
specified.
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
Length: Length of the attribute, which MUST be > 4.
</t>
<t>
X-Type: START_TIME
</t>
<t>
SubType:
</t>
<t>
The following sub types for START_TIME are defined. IANA acts as a
registry for START_TIME sub-types as described in Section 7, IANA
Considerations. Initially, the registry contains the following sub
types for START_TIME:
</t>
<t>
<list style="numbers">
<t>
1 NTP_TIMESTAMP NTP Timestamp Format as defined in
RFC 1305.
</t>
</list>
</t>
<t>
OctetString: The OctetString contains the start time.
</t>
</section>
<section title="End time">
<t>
END_TIME is used to identify the end time of the authorized session and
can be used to limit the amount of time that resources are authorized
for use (e.g., in prepaid session scenarios).
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
Length: Length of the attribute, which MUST be > 4.
</t>
<t>
X-Type: END_TIME
</t>
<t>
SubType:
</t>
<t>
The following sub types for END_TIME are defined. IANA acts as a
registry for END_TIME sub-types as described in Section 7, IANA
Considerations. Initially, the registry contains the following sub
types for END_TIME:
</t>
<t>
<list style="numbers">
<t>
NTP_TIMESTAMP NTP Timestamp Format as defined in
RFC 1305.
</t>
</list>
</t>
<t>
OctetString: The OctetString contains the end time.
</t>
</section>
<section title="NSLP Object List">
<t>
The NSLP_OBJECT_LIST attribute contains a list of NSLP objects
types that are used in the keyed-hash computation whose result is
given in the AUTHENTICATION_DATA attribute. This allows for an
integrity protection of NSLP PDUs. If an NSLP_OBJECT_LIST
attribute has been included in the AUTH_SESSION policy element, an
AUTHENTICATION_DATA attribute MUST also be present.
</t>
<t>
The creator of the this attribute lists every NSLP object type
whose NSLP PDU object was included in the computation of the
hash. The receiver can verify the integrity of the NSLP PDU
by computing a hash over all NSLP objects that are listed
in this attribute including all the attributes
of the authorization object. Since all NSLP object types
are unique over all different NSLPs, this will work
for any NSLP.
</t>
<t>
Basic NTLP/NSLP objects like the session ID, the NSLPID and
the MRI MUST be always included in the HMAC. Since they
are not carried within the NSLP itself, but only within GIST,
they must be delivered via the GIST API and normalized to
their network representation from <xref target="I-D.ietf-nsis-ntlp" />
again before calculating the hash. These values are hashed first, before
any other NSLP object values that are included in the hash computation.
</t>
<t>
A summary of the NSLP_OBJECT_LIST attribute format is described below.
</t>
<figure>
<artwork><![CDATA[
0 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
+---------------+---------------+---------------+---------------+
| Length | NSLP_OBJ_LIST | zero |
+---------------+---------------+-------+-------+---------------+
| No of signed NSLP objects = n | rsv | NSLP object type (1) |
+-------+-------+---------------+-------+-------+---------------+
| rsv | NSLP object type (2) | ..... //
+-------+-------+---------------+---------------+---------------+
| rsv | NSLP object type (n) | (padding if required) |
+--------------+----------------+---------------+---------------+
]]></artwork>
</figure>
<t>
Length: Length of the attribute, which MUST be > 4.
</t>
<t>
X-Type: NSLP_OBJECT_LIST
</t>
<t>
SubType: No sub types for NSLP_OBJECT_LIST are currently defined.
This field MUST be set to 0.
</t>
<t>
OctetString: The OctetString contains the authentication data of the
AUTH_SESSION.
</t>
<t>
No of signed NSLP objects: The number n of NSLP object types
that follow. n=0 is allowed, i.e., only a padding field is contained
then.
</t>
<t>
rsv: reserved bits and must be set to 0 (zero).
</t>
<t>
NSLP object type: the NSLP 12-bit object type identifier
of the object that was included in the hash calculation.
The NSLP object type values comprise only 12 bit, so four
bits per type value are currently not used within the
list. Depending on the number of signed objects, a
corresponding padding word of 16 bit must be supplied.</t>
<t>
padding: padding is required if the number of NSLP objects
is even. The padding field MUST be 16 bit set to 0.
</t>
</section>
<section title="Authentication data">
<t>
The AUTHENTICATION_DATA attribute contains the authentication data of
the AUTH_SESSION policy element and signs all the data in the policy
element up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA
attribute has been included in the AUTH_SESSION policy element, it
MUST be the last attribute in the list. The algorithm used to compute
the authentication data depends on the AUTH_ENT_ID SubType field. See
<xref target='sec-session-auth-integrity'></xref>
entitled Integrity of the AUTH_SESSION policy element.
</t>
<t>
A summary of AUTHENTICATION_DATA attribute format is described below.
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | X-Type | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
]]></artwork>
</figure>
<t>
Length: Length of the attribute, which MUST be > 4.
</t>
<t>
X-Type: AUTHENTICATION_DATA
</t>
<t>
SubType: No sub types for AUTHENTICATION_DATA are currently defined.
This field MUST be set to 0.
</t>
<t>
OctetString: The OctetString contains the authentication data of the
AUTH_SESSION.
</t>
</section>
</section>
</section>
<section title="Integrity of the AUTH_SESSION policy element" anchor="sec-session-auth-integrity">
<t>
This section describes how to ensure the integrity of the policy element
is preserved.
</t>
<section title="Shared symmetric keys">
<t>
In shared symmetric key environments, the AUTH_ENT_ID MUST be of
subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or
URI. An example AUTH_SESSION object is shown below.
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = AUTH_SESSION |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | IPV4_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (The authorizing entity's Identifier) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
]]></artwork>
</figure>
<section title="Operational Setting using shared symmetric keys">
<t>
This assumes both the Authorizing Entity and the Network router/PDP are
provisioned with shared symmetric keys and with policies detailing which
algorithm to be used for computing the authentication data along with
the expected length of the authentication data for that particular
algorithm.
</t>
<t>
Key maintenance is outside the scope of this document, but AUTH_SESSION
implementations MUST at least provide the ability to manually configure
keys and their parameters. The key used to produce the authentication
data is identified by the AUTH_ENT_ID field. Since multiple keys may be
configured for a particular AUTH_ENT_ID value, the first 32 bits of the
AUTH_DATA field MUST be a key ID to be used to identify the appropriate
key. Each key must also be configured with lifetime parameters for the
time period within which it is valid as well as an associated
cryptographic algorithm parameter specifying the algorithm to be used
with the key. At a minimum, all AUTH_SESSION implementations MUST
support the HMAC-MD5-128 <xref target="RFC1321" /> <xref
target="RFC2104" /> cryptographic algorithm for computing the
authentication data.
</t>
<t>
It is good practice to regularly change keys. Keys MUST be configurable
such that their lifetimes overlap allowing smooth transitions between
keys. At the midpoint of the lifetime overlap between two keys, senders
should transition from using the current key to the next/longer-lived
key. Meanwhile, receivers simply accept any identified key received
within its configured lifetime and reject those that are not.
</t>
</section>
</section>
<section title="Kerberos">
<t>
RFC 3520 provides a mechanism to secure the authorization token using
Kerberos. Kerberos, however, has not seen deployment in this context
and is not well applicable for this particular usage scenario. Hence,
Kerberos support will not be provided by this specification.
</t>
</section>
<section title="Public Key">
<t>
In a public key environment, the AUTH_ENT_ID MUST be of the subtypes:
X509_V3_CERT or PGP_CERT. The authentication data is used for
authenticating the authorizing entity. An example of the public key
AUTH_SESSION policy element is shown below.
</t>
<figure>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = AUTH_SESSION |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | PGP_CERT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authorizing entity Digital Certificate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
]]></artwork>
</figure>
<section title="Operational Setting for public key based authentication">
<t>
Public key based authentication assumes the following:
</t>
<t>
<list style="symbols">
<t>
Authorizing entities have a pair of keys (private key and
public key).
</t>
<t>
Private key is secured with the authorizing entity.
</t>
<t>
Public keys are stored in digital certificates and a trusted
party, certificate authority (CA) issues these digital
certificates.
</t>
<t>
The verifier (PDP or router) has the ability to verify the
digital certificate.
</t>
</list>
</t>
<t>
Authorizing entity uses its private key to generate AUTHENTICATION_DATA.
Authenticators (router, PDP) use the authorizing entity's public key
(stored in the digital certificate) to verify and authenticate the
policy element.
</t>
<section title="X.509 V3 digital certificates">
<t>
When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA
MUST be generated following these steps:
</t>
<t>
<list style="symbols">
<t>
A Signed-data is constructed as defined in RFC3852 <xref
target="RFC3852" /> . A digest is computed on the content (as specified
in Section 6.1) with a signer-specific message-digest algorithm. The
certificates field contains the chain of authorizing entity's X.509 V3
digital certificates. The certificate revocation list is defined in the
crls field. The digest output is digitally signed following Section 8 of
RFC 3447 <xref target="RFC3447" />, using the signer's private key.
</t>
</list>
</t>
<t>
When the AUTH_ENT_ID is of type X509_V3_CERT, verification MUST be
done following these steps:
</t>
<t>
<list style="symbols">
<t>
Parse the X.509 V3 certificate to extract the distinguished name
of the issuer of the certificate.
</t>
<t>
Certification Path Validation is performed as defined in Section 6
of RFC 3280.
</t>
<t>
Parse through the Certificate Revocation list to verify that the
received certificate is not listed.
</t>
<t>
Once the X.509 V3 certificate is validated, the public key of the
authorizing entity can be extracted from the certificate.
</t>
<t>
Extract the digest algorithm and the length of the digested data
by parsing the CMS signed-data.
</t>
<t>
The recipient independently computes the message digest. This
message digest and the signer's public key are used to verify the
signature value.
</t>
</list>
</t>
<t>
This verification ensures integrity, non-repudiation and data origin.
</t>
</section>
<section title="PGP digital certificates">
<t>
When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be
generated following these steps:
</t>
<t>
<list style="symbols">
<t>
AUTHENTICATION_DATA contains a Signature Packet as defined in
Section 5.2.3 of RFC 2440. In summary:
</t>
<t>
Compute the hash of all data in the AUTH_SESSION policy element
up to the AUTHENTICATION_DATA.
</t>
<t>
The hash output is digitally signed following Section 8 of
RFC 3447, using the signer's private key.
</t>
</list>
</t>
<t>
When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done
following these steps:
</t>
<t>
<list style="symbols">
<t>
Validate the certificate.
</t>
<t>
Once the PGP certificate is validated, the public key of the
authorizing entity can be extracted from the certificate.
</t>
<t>
Extract the hash algorithm and the length of the hashed data by
parsing the PGP signature packet.
</t>
<t>
The recipient independently computes the message digest. This
message digest and the signer's public key are used to verify the
signature value.
</t>
</list>
</t>
<t>
This verification ensures integrity, non-repudiation and data origin.
</t>
</section>
</section>
</section>
<section title="HMAC Signed" anchor='sec-hmac-signed'>
<t>
An AUTH_SESSION object that carries an AUTH_ENT_ID of HMAC_SIGNED
is used as integrity protection for NSLP messages. The AUTH_SESSION
object MUST contain the following attributes:
</t>
<t>
<list style="symbols">
<t>
SOURCE_ADDR the source address of the entity that created
the HMAC
</t>
<t>
START_TIME the timestamp when the HMAC signature was
calculated. This MUST be different for any
two messages in sequence in order to prevent
replay attacks. Since the NTP timestamp
provides currently a resolution of 200 pico seconds
this should be sufficient.
</t>
<t>
NSLP_OBJECT_LIST this attribute lists all NSLP objects that
are included into HMAC calculation.
</t>
<t>
AUTHENTICATION_DATA this attribute contains the Key-ID
that is used for HMAC calculation
as well as the HMAC data itself <xref target="RFC2104" />.
</t>
</list>
</t>
<t>
The key used for HMAC calculation must be exchanged securely by some
other means, e.g., a Kerberos Ticket or pre-shared manual installation
etc. The Key-ID in the AUTHENTICATION_DATA allows to refer to the
appropriate key and also to change signing keys. The key length MUST
be 64-bit at least, but it is ideally longer in order to defend
against brute force attacks. It is recommended to use a per-user key
for signing NSLP messages.
</t>
<t>
<xref target='fig-hmac-signed-obj'></xref> shows an example of
an object that is used for integrity protection of NSLP messages.
</t>
<t>
<figure anchor='fig-hmac-signed-obj'>
<artwork><![CDATA[
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0| Type = AUTH_SESSION |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | HMAC_SIGNED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SOURCE_ADDR | IPV4_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Source Address of NSLP sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | START_TIME | NTP_TIME_STAMP|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Time Stamp (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Time Stamp (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | NTLP_OBJ_LIST | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| No of signed NSLP objects = n | rsv | NSLP object type (1) |
+-------+-------+---------------+-------+-------+---------------+
| rsv | NSLP object type (2) | ..... //
+-------+-------+---------------+---------------+---------------+
| rsv | NSLP object type (n) | (padding if required) |
+--------------+----------------+---------------+---------------+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code HMAC Data |
+---------------------------------------------------------------+
]]></artwork>
<postamble>Example for an AUTH_SESSION_OBJECT that provides
integrity protection for NSLP messages</postamble>
</figure>
</t>
</section> <!-- HMAC Signed -->
</section>
<section title="Framework" anchor='sec-framework'>
<t>
RFC3521 <xref target="RFC3521" /> describes a framework in which the
AUTH_SESSION policy element may be utilized to transport information
required for authorizing resource reservation for media flows.
RFC3521 introduces 4 different models:
</t>
<t>
<list style="numbers">
<t>
The coupled model
</t>
<t>
The associated model with one policy server
</t>
<t>
The associated model with two policy servers
</t>
<t>
The non-associated model.
</t>
</list>
</t>
<t>
The fields that are required in an AUTH SESSION policy element
dependent on which of the models is used.
</t>
<section title="The Coupled Model">
<t>
In the coupled model, the only information that MUST be included in the
policy element is the SESSION_ID; it is used by the Authorizing Entity
to correlate the resource reservation request with the media authorized
during session set up. Since the End Host is assumed to be untrusted,
the Policy Server SHOULD take measures to ensure that the integrity of
the SESSION_ID is preserved in transit; the exact mechanisms to be used
and the format of the SESSION_ID are implementation dependent.
</t>
</section>
<section title="The associated model with one policy server">
<t>
In this model, the contents of the AUTH_SESSION policy element MUST
include:
</t>
<t>
<list style="symbols">
<t>
A session identifier - SESSION_ID. This is information that the
authorizing entity can use to correlate the resource request with
the media authorized during session set up.
</t>
<t>
The identity of the authorizing entity - AUTH_ENT_ID. This
information is used by an NN to determine which
authorizing entity (Policy Server) should be used to solicit
resource policy decisions.
</t>
</list>
</t>
<t>
In some environments, an NN may have no means for determining
if the identity refers to a legitimate Policy Server within its domain.
In order to protect against redirection of authorization requests to a
bogus authorizing entity, the AUTH_SESSION MUST also include:
</t>
<t>
<list style="empty">
<t>
AUTHENTICATION_DATA. This authentication data is calculated over all
other fields of the AUTH_SESSION policy element.
</t>
</list>
</t>
</section>
<section title="The associated model with two policy servers">
<t>
The content of the AUTH_SESSION Policy Element is identical to the
associated model with one policy server.
</t>
</section>
<section title="The non-associated model">
<t>
In this model, the AUTH_SESSION MUST contain sufficient information
to allow the Policy Server to make resource policy decisions
autonomously from the authorizing entity. The policy element is
created using information about the session by the authorizing
entity. The information in the AUTH_SESSION policy element MUST
include:
</t>
<t>
<list style="symbols">
<t>
Calling party IP address or Identity (e.g., FQDN) - SOURCE_ADDR
X-TYPE
</t>
<t>
Called party IP address or Identity (e.g., FQDN) - DEST_ADDR
X-TYPE
</t>
<t>
The characteristics of (each of) the media stream(s) authorized
for this session - RESOURCES X-TYPE
</t>
<t>
The authorization lifetime - START_TIME X-TYPE
</t>
<t>
The identity of the authorizing entity to allow for validation of
the token in shared symmetric key and Kerberos schemes -
AUTH_ENT_ID X-TYPE
</t>
<t>
The credentials of the authorizing entity in a public-key
scheme - AUTH_ENT_ID X-TYPE
</t>
<t>
Authentication data used to prevent tampering with the
AUTH_SESSION policy element - AUTHENTICATION_DATA
</t>
</list>
</t>
<t>
Furthermore, the AUTH_SESSION policy element MAY contain:
</t>
<t>
<list style="symbols">
<t>
The lifetime of (each of) the media stream(s) - END_TIME X-TYPE
</t>
<t>
Calling party port number - SOURCE_ADDR X-TYPE
</t>
<t>
Called party port number - DEST_ADDR X-TYPE
</t>
</list>
</t>
<t>
All AUTH_SESSION fields MUST match with the resource request. If a
field does not match, the request SHOULD be denied.
</t>
</section>
</section>
<section title="Message Processing Rules">
<t>
This section discusses the message processing related to the
AUTH_SESSION object. We describe the details of the QoS NSLP and NAT/FW
NSLP. New NSLP protocols should use the same logic in making use of the
AUTH_SESSION object.
</t>
<section title="Generation of the AUTH_SESSION by the authorizing entity">
<t>
<list style="numbers">
<t>
Generate the AUTH_SESSION policy element with the appropriate
contents as specified in <xref target='sec-session-auth-object-formats'></xref>.
</t>
<t>
If authentication is needed, the entire AUTH_SESSION policy element is
constructed, excluding the length, type and subtype fields of the
AUTH_SESSION field. Note that the message MUST include a START_TIME to
prevent replay attacks. The output of the authentication algorithm,
plus appropriate header information, is appended as
AUTHENTICATION_DATA attribute to the AUTH_SESSION policy element.
</t>
</list>
</t>
</section>
<section title="Processing within the QoS NSLP">
<t>
The AUTH_SESSION object may be used with QoS NSLP QUERY and RESERVE
messages to authorize the query operation for network resources, and a
resource reservation request, respectively.
</t>
<t>
Moreover, the AUTH_SESSION object may also be used with RESPONSE
messages in order to indicate that the authorizing entity changed the
original request. For example, the session start or end times may have
been modified, or the client may have requested authorization for all
ports, but the authorizing entity only allowed the use of certain ports.
</t>
<t>
If the QoS NSIS Initiator (QNI) receives a RESPONSE message with an
AUTH_SESSION object, the QNI MUST inspect the AUTH_SESSION object to see
what authentication attribute was changed by an authorizing entity. The
QNI SHOULD also silently accept AUTH_SESSION objects in RESPONSE message
which do not indicate any change to the original authorization request.
</t>
<section title="Message Generation">
<t>
A QoS NSLP message is created as specified in <xref target="I-D.ietf-nsis-qos-nslp" />.
</t>
<t>
<list style="numbers">
<t>
The policy element received from the authorizing entity
MUST be copied without modification into the AUTH_SESSION object.
</t>
<t>
The AUTH_SESSION object (containing the policy element) is inserted
in the NSLP message in the appropriate place.
</t>
</list>
</t>
</section>
<section title="Message Reception">
<t>
The QoS NSLP message is processed as specified in <xref target="I-D.ietf-nsis-qos-nslp" /> with
following modifications.
</t>
<t>
<list style="numbers">
<t>
If the QNE is policy aware then it SHOULD use the Diameter QoS
application or the RADIUS QoS protocol to communicate with the PDP. To
construct the AAA message it is necessary to extract the AUTH_SESSION
object and the QoS related objects from the QoS NSLP message and to
craft the respective RADIUS or Diameter message. The message processing
and object format is described in the respective RADIUS or Diameter QoS
protocol, respectively. If the QNE is policy unaware then it ignores
the policy data objects and continues processing the NSLP message.
</t>
<t>
If the response from the PDP is negative the request must be
rejected. A negative response in RADIUS is an Access-Reject and in
Diameter is based on the 'DIAMETER_SUCCESS' value in the Result-Code AVP
of the QoS-Authz-Answer (QAA) message. The QNE must contruct and send a
RESPONSE message with the status of authorization failure as specified
in <xref target="I-D.ietf-nsis-qos-nslp" />.
</t>
<t>
Continue processing the NSIS message.
</t>
</list>
</t>
</section>
<section title="Authorization (QNE/PDP)">
<t>
<list style="numbers">
<t>
Retrieve the policy element from the AUTH_SESSION object. Check the
PE type field and return an error if the identity type is not
supported.
</t>
<t>
Verify the message integrity.
<list style="symbols">
<t>
Shared symmetric key authentication: The QNE/PDP uses the
AUTH_ENT_ID field to consult a table keyed by that field.
The table should identify the cryptographic authentication
algorithm to be used along with the expected length of the
authentication data and the shared symmetric key for the
authorizing entity. Verify that the indicated length of the
authentication data is consistent with the configured table
entry and validate the authentication data.
</t>
<t>
Public Key: Validate the certificate chain against the trusted
Certificate Authority (CA) and validate the message signature
using the public key.
</t>
<t>
Kerberos based usage is not provided by this document.
</t>
</list>
</t>
<t>
Once the identity of the authorizing entity and the validity of
the service request has been established, the authorizing
router/PDP MUST then consult its authorization policy in order to
determine whether or not the specific request is authorized (e.g.,
based on available credits, information in the subscriber's
database). To the extent to which these access control decisions
require supplementary information, routers/PDPs MUST ensure that
supplementary information is obtained securely.
</t>
<t>
Verify the requested resources do not exceed the authorized QoS.
</t>
</list>
</t>
</section>
<section title="Error Signaling">
<t>
When the PDP (e.g., a RADIUS or Diameter server) fails to verify the
policy element then the appropriate actions described the respective AAA
document need to be taken.
</t>
<t>
The QNE node MUST return a RESPONSE message with the INFO_SPEC error
code Authorization Failure as defined in the QoS NSLP specification. The
QNE MAY include an INFO_SPEC Object Value Info to indicate which
AUTH_SESSION attribute created the error.
</t>
</section>
</section>
<section title="Processing with the NAT/FW NSLP">
<t>
This section presents processing rules for the NAT/FW NSLP <xref target="I-D.ietf-nsis-nslp-natfw" />.
</t>
<section title="Message Generation">
<t>
A NAT/FW NSLP message is created as specified in <xref target="I-D.ietf-nsis-nslp-natfw" />.
</t>
<t>
<list style="numbers">
<t>
The policy element received from the authorizing entity MUST be
copied without modification into the AUTH_SESSION object.
</t>
<t>
The AUTH_SESSION object (containing the policy element) is
inserted in the NATFW NSLP message in the appropriate place.
</t>
</list>
</t>
</section>
<section title="Message Reception">
<t>
The NAT/FW NSLP message is processed as specified in <xref target="I-D.ietf-nsis-nslp-natfw" />
with following modifications.
</t>
<t>
<list style="numbers">
<t>
If the router is policy aware then it SHOULD use the Diameter
application or the RADIUS protocol to communicate with the PDP. To
construct the AAA message it is necessary to extract the
AUTH_SESSION element and the NATFW policy rule related objects
from the NSLP message and to craft the respective RADIUS or
Diameter message. The message processing and object format is
described in the respective RADIUS or Diameter protocols,
respectively. If the router is policy unaware then it ignores the
policy data objects and continues processing the NSLP message.
</t>
<t>
Reject the message if the response from the PDP is negative. A
negative response in RADIUS is an Access-Reject and in Diameter is
based on the 'DIAMETER_SUCCESS' value in the Result-Code AVP.
</t>
<t>
Continue processing the NSIS message.
</t>
</list>
</t>
</section>
<section title="Authorization (Router/PDP)">
<t>
<list style="numbers">
<t>
Retrieve the AUTH_SESSION object and the policy element. Check the PE
type field and return an error if the identity type is not supported.
</t>
<t>
Verify the message integrity.
<list style="symbols">
<t>
Shared symmetric key authentication: The Network router/PDP uses the
AUTH_ENT_ID field to consult a table keyed by that field. The table
should identify the cryptographic authentication algorithm to be used
along with the expected length of the authentication data and the shared
symmetric key for the authorizing entity. Verify that the indicated
length of the authentication data is consistent with the configured
table entry and validate the authentication data.
</t>
<t>
Public Key: Validate the certificate chain against the trusted
Certificate Authority (CA) and validate the message signature using the
public key.
</t>
<t>
Kerberos based usage is not provided by this document.
</t>
</list>
</t>
<t>
Once the identity of the authorizing entity and the validity of the
service request has been established, the authorizing router/PDP MUST
then consult its authorization policy in order to deter mine whether or
not the specific request is authorized. To the extent to which these
access control decisions require supplementary information, routers/PDPs
MUST ensure that supplementary information is obtained securely.
</t>
</list>
</t>
</section>
<section title="Error Signaling">
<t>
When the PDP (e.g., a RADIUS or Diameter server) fails to verify the
AUTH_SESSION element then the appropriate actions described the
respective AAA document need to be taken. The NATFW NSLP node MUST
return an error message of class 'Permanent failure' (0x5) with error
code 'Authorization failed' (0x02).
</t>
</section>
</section>
<section title="Integrity Protection of NSLP messages">
<t>
The AUTH_SESSION object can also be used to provide an integrity
protection for every NSLP signaling message, thereby also authorizing
requests or responses. Assume that a user has deposited a shared key
at some NN. This NN can then verify the integrity of every NSLP message
sent by the user to the NN, thereby authorizing actions like resource
reservations or opening firewall pinholes according to policy decisions
earlier made.
</t>
<t>
The sender of an NSLP message creates an AUTH_SESSION object that
contains AUTH_ENT_ID attribute set to HMAC_SIGNED (cf. <xref
target='sec-hmac-signed'/>) and hashes with the shared key over all
NSLP objects that need to be protected and lists them in the
NSLP_OBJECT_LIST. The AUTH_SESSION object itself is also protected by
the HMAC. By inclusion of the AUTH_SESSION object into the NSLP
message, the receiver of this NSLP message can verify its integrity if
it has the suitable shared key for the HMAC. Any response to the
sender should also be protected by inclusion of an AUTH_SESSION object
in order to prevent attackers sending unauthorized responses on behalf
of the real NN.
</t>
<t>
If an AUTH_SESSION object is present that has an AUTH_ENT_ID attribute
set to HMAC_SIGNED, the integrity of all NSLP elements listed in the
NSLP_OBJECT_LIST has to be checked, including the AUTH_SESSION object
contents itself. The key that is used to calculate the HMAC is
referred to by the Key ID included in the AUTH_DATA attribute. If the
provided timestamp in START_TIME is not recent enough or the
calculated HMAC differs from the one provided in AUTH_DATA the message
must be discarded silently and an error should be logged locally.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
This document describes a mechanism for session authorization to prevent
theft of service. There are three types of security issues to consider:
protection against replay attacks, integrity of the AUTH_SESSION
object, and the choice of the authentication algorithms and keys.
</t>
<t>
The first issue, replay attacks, MUST be prevented. In the
non-associated model, the AUTH_SESSION object MUST include a START_TIME
field and the Policy Servers MUST support NTP to ensure proper clock
synchronization. Failure to ensure proper clock synchronization will
allow replay attacks since the clocks of the different network entities
may not be in synch. The start time is used to verify that the request
is not being replayed at a later time. In all other models, the
SESSION_ID is used by the Policy Server to ensure that the resource
request successfully correlates with records of an authorized session.
If a AUTH_SESSION object is replayed, it MUST be detected by the policy
server (using internal algorithms) and the request MUST be rejected.
</t>
<t>
The second issue, the integrity of the policy element, is preserved in
untrusted environments by including the AUTHENTICATION_DATA attribute.
Therefore, this attribute MUST always be included.
</t>
<t>
In environments where shared symmetric keys are possible, they should be
used in order to keep the AUTH_SESSION policy element size to a strict
minimum, e.g., when wireless links are used. A secondary option would be
PKI authentication, which provides a high level of security and good
scalability. However, it requires the presence of credentials in the
AUTH_SESSION policy element which impacts its size.
</t>
<t>
Further security issues are outlined in RFC 4081 <xref target="RFC4081" />.
</t>
</section>
<section title="IANA Considerations">
<t>
This specification makes the following request to IANA:
<list style="numbers">
<t>
Assign a new object value for the AUTH_SESSION object from the shared
NSLP object value space.
</t>
<t>
All AUTH_SESSION object internal values and numbers should be taken from
the allocations already done for RFC 3520 <xref target="RFC3520" />.
Yet, this specification does make use of two X-types introduced by
RFC3520: Session_ID and Resources.
</t>
</list>
</t>
</section>
<section title="Acknowledgments">
<t>
This document is based on the RFC 3520 <xref target="RFC3520" /> and
credit therefore goes to the authors of RFC 3520, namely Louis-Nicolas
Hamer, Brett Kosinski, Bill Gage and Hugh Shieh.
Part of this work was funded by Deutsche Telekom Laboratories
within the context of the ScaleNet project.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&ntlp;
&qosnslp;
&natfwnslp;
&rfc2119;
&rfc3447;
&rfc4306;
</references>
<references title='Informative References'>
&rfc1321;
&rfc2104;
&rfc3852;
&rfc3520;
&rfc3521;
&rfc4080;
&rfc4081;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 02:02:12 |