< draft-manner-nsis-nslp-auth-03.txt   draft-manner-nsis-nslp-auth-04.txt >
Network Working Group J. Manner Network Working Group J. Manner
Internet-Draft TKK Internet-Draft TKK
Intended status: Standards Track M. Stiemerling Intended status: Standards Track M. Stiemerling
Expires: September 4, 2007 NEC Expires: January 3, 2009 NEC
H. Tschofenig H. Tschofenig
Siemens Networks GmbH & Co KG Nokia Siemens Networks
March 3, 2007 R. Bless
Univ. of Karlsruhe
July 2, 2008
Authorization for NSIS Signaling Layer Protocols Authorization for NSIS Signaling Layer Protocols
draft-manner-nsis-nslp-auth-03.txt draft-manner-nsis-nslp-auth-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2007. This Internet-Draft will expire on January 3, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
Signaling layer protocols in the NSIS working group may rely on GIST Signaling layer protocols in the NSIS working group may rely on GIST
to handle authorization. Still, the signaling layer protocol itself to handle authorization. Still, the signaling layer protocol itself
may require separate authorization to be performed when a node may require separate authorization to be performed when a node
receives a request for a certain kind of service or resources. This receives a request for a certain kind of service or resources. This
draft presents a generic model and object formats for session draft presents a generic model and object formats for session
authorization within the NSIS Signaling Layer Protocols. The goal of authorization within the NSIS Signaling Layer Protocols. The goal of
session authorization is to allow the exchange of information between session authorization is to allow the exchange of information between
network elements in order to authorize the use of resources for a network elements in order to authorize the use of resources for a
service and to coordinate actions between the signaling and transport service and to coordinate actions between the signaling and transport
planes. planes.
Table of Contents Table of Contents
1. Conventions used in this document . . . . . . . . . . . . . . 4 1. Conventions used in this document . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Session Authorization Object . . . . . . . . . . . . . . . . . 6 3. Session Authorization Object . . . . . . . . . . . . . . . . . 7
3.1. Session Authorization Object format . . . . . . . . . . . 6 3.1. Session Authorization Object format . . . . . . . . . . . 7
3.2. Session Authorization Attributes . . . . . . . . . . . . . 7 3.2. Session Authorization Attributes . . . . . . . . . . . . . 8
3.2.1. Authorizing Entity Identifier . . . . . . . . . . . . 8 3.2.1. Authorizing Entity Identifier . . . . . . . . . . . . 9
3.2.2. Source Address . . . . . . . . . . . . . . . . . . . . 9 3.2.2. Source Address . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Destination Address . . . . . . . . . . . . . . . . . 11 3.2.3. Destination Address . . . . . . . . . . . . . . . . . 12
3.2.4. Start time . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Start time . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5. End time . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.5. End time . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.6. Authentication data . . . . . . . . . . . . . . . . . 13 3.2.6. NSLP Object List . . . . . . . . . . . . . . . . . . . 15
4. Integrity of the AUTH_SESSION policy element . . . . . . . . . 15 3.2.7. Authentication data . . . . . . . . . . . . . . . . . 16
4.1. Shared symmetric keys . . . . . . . . . . . . . . . . . . 15 4. Integrity of the AUTH_SESSION policy element . . . . . . . . . 18
4.1.1. Operational Setting using shared symmetric keys . . . 15 4.1. Shared symmetric keys . . . . . . . . . . . . . . . . . . 18
4.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.1. Operational Setting using shared symmetric keys . . . 18
4.3. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1. Operational Setting for public key based 4.3.1. Operational Setting for public key based
authentication . . . . . . . . . . . . . . . . . . . . 16 authentication . . . . . . . . . . . . . . . . . . . . 19
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.4. HMAC Signed . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. The Coupled Model . . . . . . . . . . . . . . . . . . . . 19 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2. The associated model with one policy server . . . . . . . 19 5.1. The Coupled Model . . . . . . . . . . . . . . . . . . . . 24
5.3. The associated model with two policy servers . . . . . . . 20 5.2. The associated model with one policy server . . . . . . . 24
5.4. The non-associated model . . . . . . . . . . . . . . . . . 20 5.3. The associated model with two policy servers . . . . . . . 25
6. Message Processing Rules . . . . . . . . . . . . . . . . . . . 21 5.4. The non-associated model . . . . . . . . . . . . . . . . . 25
6. Message Processing Rules . . . . . . . . . . . . . . . . . . . 26
6.1. Generation of the AUTH_SESSION by the authorizing 6.1. Generation of the AUTH_SESSION by the authorizing
entity . . . . . . . . . . . . . . . . . . . . . . . . . . 21 entity . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Processing within the QoS NSLP . . . . . . . . . . . . . . 21 6.2. Processing within the QoS NSLP . . . . . . . . . . . . . . 26
6.2.1. Message Generation . . . . . . . . . . . . . . . . . . 21 6.2.1. Message Generation . . . . . . . . . . . . . . . . . . 26
6.2.2. Message Reception . . . . . . . . . . . . . . . . . . 22 6.2.2. Message Reception . . . . . . . . . . . . . . . . . . 27
6.2.3. Authorization (QNE/PDP) . . . . . . . . . . . . . . . 22 6.2.3. Authorization (QNE/PDP) . . . . . . . . . . . . . . . 27
6.2.4. Error Signaling . . . . . . . . . . . . . . . . . . . 23 6.2.4. Error Signaling . . . . . . . . . . . . . . . . . . . 28
6.3. Processing with the NAT/FW NSLP . . . . . . . . . . . . . 23 6.3. Processing with the NAT/FW NSLP . . . . . . . . . . . . . 28
6.3.1. Message Generation . . . . . . . . . . . . . . . . . . 23 6.3.1. Message Generation . . . . . . . . . . . . . . . . . . 28
6.3.2. Message Reception . . . . . . . . . . . . . . . . . . 23 6.3.2. Message Reception . . . . . . . . . . . . . . . . . . 28
6.3.3. Authorization (Router/PDP) . . . . . . . . . . . . . . 24 6.3.3. Authorization (Router/PDP) . . . . . . . . . . . . . . 29
6.3.4. Error Signaling . . . . . . . . . . . . . . . . . . . 24 6.3.4. Error Signaling . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6.4. Integrity Protection of NSLP messages . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
The term "NSLP node" (NN) is used to refer to an NSIS node running an 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 NSLP protocol that can make use of the authorization object discussed
in this document. Currently, this node would run either the QoS or in this document. Currently, this node would run either the QoS or
the NAT/FW NSLP service. the NAT/FW NSLP service.
2. Introduction 2. Introduction
The NSIS working group is specifying a suite of protocols for the The NSIS working group is specifying a suite of protocols for the
next generation in Internet signaling [RFC4080]. The design is based next generation in Internet signaling [RFC4080]. The design is based
on a generalized transport protocol for signaling applications, the on a generalized transport protocol for signaling applications, the
General Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp], and General Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp], and
various kinds of signaling applications. Two signaling applications various kinds of signaling applications. Two signaling applications
and their NSIS Signaling Layer Protocols (NSLP) have been designed, a and their NSIS Signaling Layer Protocol (NSLP) have been designed, a
Quality of Service application (QoS NSLP) [I-D.ietf-nsis-qos-nslp] Quality of Service application (QoS NSLP) [I-D.ietf-nsis-qos-nslp]
and a NAT/firewall application (NAT/FW) [I-D.ietf-nsis-nslp-natfw]. and a NAT/firewall application (NAT/FW) [I-D.ietf-nsis-nslp-natfw].
The security architecture is based on a chain-of-trust model, where The security architecture is based on a chain-of-trust model, where
each GIST hop may chose the appropriate security protocol, taking each GIST hop may chose the appropriate security protocol, taking
into account the signaling application requirements. This model is into account the signaling application requirements. This model is
appropriate for a number of different use cases, and allows the appropriate for a number of different use cases, and allows the
signaling applications to leave the handling of security to GIST. signaling applications to leave the handling of security to GIST.
Yet, in order to allow for finer-grain per-session admission control, Yet, in order to allow for finer-grain per-session or per-user
it is necessary to provide a mechanism for ensuring that the use of admission control, it is necessary to provide a mechanism for
resources by a host has been properly authorized before allowing the ensuring that the use of resources by a host has been properly
signaling application to commit the resource request, e.g., a QoS authorized before allowing the signaling application to commit the
reservation or mappings for NAT traversal. In order to meet this resource request, e.g., a QoS reservation or mappings for NAT
requirement,there must be information in the NSLP message which may traversal. In order to meet this requirement,there must be
be used to verify the validity of the request. This can be done by information in the NSLP message which may be used to verify the
providing the host with a session authorization policy element which validity of the request. This can be done by providing the host with
is inserted into the message and verified by the network. a session authorization policy element which is inserted into the
message and verified by the network.
This document describes a generic NSLP layer session authorization This document describes a generic NSLP layer session authorization
policy object (AUTH_SESSION) used to convey authorization information policy object (AUTH_SESSION) used to convey authorization information
for the request. The scheme is based on third-party tokens. A for the request. The scheme is based on third-party tokens. A
trusted third party provides authentication tokens to clients and trusted third party provides authentication tokens to clients and
allows verification of the information by the network elements. The allows verification of the information by the network elements. The
requesting host inserts its authorization information acquired from requesting host inserts its authorization information acquired from
the trusted third party into the NSLP message to allow verification the trusted third party into the NSLP message to allow verification
of the network resource request. Network elements verify the request of the network resource request. Network elements verify the request
and then process the resource reservation message based on admission and then process the resource reservation message based on admission
skipping to change at page 7, line 40 skipping to change at page 8, line 40
set of valid objects is described in Section 3.2. set of valid objects is described in Section 3.2.
3.2. Session Authorization Attributes 3.2. Session Authorization Attributes
A session authorization attribute may contain a variety of A session authorization attribute may contain a variety of
information and has both an attribute type and subtype. The information and has both an attribute type and subtype. The
attribute itself MUST be a multiple of 4 octets in length, and any 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 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. a 4-octet boundary. All padding bytes MUST have a value of zero.
+--------+--------+--------+--------+ 0 1 2 3
| Length | X-Type |SubType | 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
+--------+--------+--------+--------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ... | Length | X-Type | SubType |
+--------+--------+--------+--------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value ... //
+---------------------------------------------------------------+
Length: 16 bits Length: 16 bits
The length field is two octets and indicates the actual length of The length field is two octets and indicates the actual length of
the attribute (including Length, X-Type and SubType fields) in the attribute (including Length, X-Type and SubType fields) in
number of octets. The length does NOT include any bytes padding number of octets. The length does NOT include any bytes padding
to the value field to make the attribute a multiple of 4 octets to the value field to make the attribute a multiple of 4 octets
long. long.
X-Type: 8 bits X-Type: 8 bits
Session authorization attribute type (X-Type) field is one octet. Session authorization attribute type (X-Type) field is one octet.
IANA acts as a registry for X-Types as described in Section 7, IANA acts as a registry for X-Types as described in Section 7,
IANA Considerations. Initially, the registry contains the IANA Considerations. Initially, the registry contains the
following X-Types: following X-Types:
1. AUTH_ENT_ID The unique identifier of the entity which authorized 1. AUTH_ENT_ID The unique identifier of the entity that authorized
the session. the session.
2. SOURCE_ADDR Address specification for the session originator. 2. SOURCE_ADDR Address specification for the signaling session
initiator, i.e., the source address of the signaling message
originator.
3. DEST_ADDR Address specification for the session end-point. 3. DEST_ADDR Address specification for the signaling session end-
point.
4. START_TIME The starting time for the session. 4. START_TIME The starting time for the session.
5. END_TIME The end time for the session. 5. END_TIME The end time for the session.
6. AUTHENTICATION_DATA Authentication data of the session 6. AUTHENTICATION_DATA Authentication data of the session
authorization policy element. authorization policy element.
SubType: 8 bits SubType: 8 bits
skipping to change at page 8, line 44 skipping to change at page 10, line 5
The attribute specific information. The attribute specific information.
3.2.1. Authorizing Entity Identifier 3.2.1. Authorizing Entity Identifier
AUTH_ENT_ID is used to identify the entity which authorized the AUTH_ENT_ID is used to identify the entity which authorized the
initial service request and generated the session authorization initial service request and generated the session authorization
policy element. The AUTH_ENT_ID may be represented in various policy element. The AUTH_ENT_ID may be represented in various
formats, and the SubType is used to define the format for the ID. formats, and the SubType is used to define the format for the ID.
The format for AUTH_ENT_ID is as follows: The format for AUTH_ENT_ID is as follows:
+-------+-------+-------+-------+ 0 1 2 3
| Length |X-Type |SubType| 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
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... | Length | X-Type | SubType |
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4. Length: Length of the attribute, which MUST be > 4.
X-Type: AUTH_ENT_ID X-Type: AUTH_ENT_ID
SubType: SubType:
The following sub-types for AUTH_ENT_ID are defined. IANA acts as 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, a registry for AUTH_ENT_ID sub-types as described in Section 7,
IANA Considerations. Initially, the registry contains the IANA Considerations. Initially, the registry contains the
following sub-types of AUTH_ENT_ID: following sub-types of AUTH_ENT_ID:
1. IPV4_ADDRESS IPv4 address represented in 32 bits 1. IPV4_ADDRESS IPv4 address represented in 32 bits
2. IPV6_ADDRESS IPv6 address represented in 128 bits 2. IPV6_ADDRESS IPv6 address represented in 128 bits
3. FQDN Fully Qualified Domain Name as defined in RFC 1034 as an 3. FQDN Fully Qualified Domain Name as defined in RFC 1034 as an
ASCII string. ASCII string.
4. ASCII_DN X.500 Distinguished name as defined in RFC 2253 as an 4. ASCII_DN X.500 Distinguished name as defined in RFC 2253 as an
ASCII string. ASCII string.
5. UNICODE_DN X.500 Distinguished name as defined in RFC 2253 as a 5. UNICODE_DN X.500 Distinguished name as defined in RFC 2253 as a
UTF-8 string. UTF-8 string.
6. URI Universal Resource Identifier, as defined in RFC 2396. 6. URI Universal Resource Identifier, as defined in RFC 2396.
7. KRB_PRINCIPAL Fully Qualified Kerberos Principal name represented 7. KRB_PRINCIPAL Fully Qualified Kerberos Principal name
by the ASCII string of a principal followed by the @ realm name represented by the ASCII string of a principal followed by the @
as defined in RFC 1510 (e.g., johndoe@nowhere). realm name as defined in RFC 1510 (e.g., johndoe@nowhere).
8. X509_V3_CERT The Distinguished Name of the subject of the 8. X509_V3_CERT The Distinguished Name of the subject of the
certificate as defined in RFC 2253 as a UTF-8 string. certificate as defined in RFC 2253 as a UTF-8 string.
9. PGP_CERT The PGP digital certificate of the authorizing entity as 9. PGP_CERT The PGP digital certificate of the authorizing entity
defined in RFC 2440. as defined in RFC 2440.
10. HMAC_SIGNED Indicates that the AUTHENTICATION_DATA attribute
contains a self-signed HMAC signature [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 [RFC4306].
OctetString: Contains the authorizing entity identifier. OctetString: Contains the authorizing entity identifier.
3.2.2. Source Address 3.2.2. Source Address
SOURCE_ADDR is used to identify the source address specification of SOURCE_ADDR is used to identify the source address specification of
the authorized session. This X-Type may be useful in some scenarios the authorized session. This X-Type may be useful in some scenarios
to make sure the resource request has been authorized for that to make sure the resource request has been authorized for that
particular source address and/or port. particular source address and/or port.
+-------+-------+-------+-------+ 0 1 2 3
| Length |X-Type |SubType| 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
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... | Length | X-Type | SubType |
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4. Length: Length of the attribute, which MUST be > 4.
X-Type: SOURCE_ADDR X-Type: SOURCE_ADDR
SubType: SubType:
The following sub types for SOURCE_ADDR are defined. IANA acts as The following sub types for SOURCE_ADDR are defined. IANA acts as
a registry for SOURCE_ADDR sub-types as described in Section 7, a registry for SOURCE_ADDR sub-types as described in Section 7,
IANA Considerations. Initially, the registry contains the IANA Considerations. Initially, the registry contains the
skipping to change at page 11, line 4 skipping to change at page 12, line 21
Authorization Data Policy Element. Authorization Data Policy Element.
At most, one instance of subtype 3 MAY be included in every Session At most, one instance of subtype 3 MAY be included in every Session
Authorization Data Policy Element. At most, one instance of subtype Authorization Data Policy Element. At most, one instance of subtype
4 MAY be included in every Session Authorization Data Policy Element. 4 MAY be included in every Session Authorization Data Policy Element.
Inclusion of a subtype 3 attribute does not prevent inclusion of a 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). subtype 4 attribute (i.e., both UDP and TCP ports may be authorized).
If no PORT attributes are specified, then all ports are considered If no PORT attributes are specified, then all ports are considered
valid; otherwise, only the specified ports are authorized for use. valid; otherwise, only the specified ports are authorized for use.
Every source address and port list must be included in a separate Every source address and port list must be included in a separate
SOURCE_ADDR attribute. SOURCE_ADDR attribute.
3.2.3. Destination Address 3.2.3. Destination Address
DEST_ADDR is used to identify the destination address of the DEST_ADDR is used to identify the destination address of the
authorized session. This X-Type may be useful in some scenarios to authorized session. This X-Type may be useful in some scenarios to
make sure the resource request has been authorized for that make sure the resource request has been authorized for that
particular destination address and/or port. particular destination address and/or port.
+-------+-------+-------+-------+ 0 1 2 3
| Length |X-Type |SubType| 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
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... | Length | X-Type | SubType |
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4. Length: Length of the attribute in number of octects, which MUST be >
4.
X-Type: DEST_ADDR X-Type: DEST_ADDR
SubType: SubType:
The following sub types for DEST_ADDR are defined. IANA acts as a 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 registry for DEST_ADDR sub-types as described in Section 7, IANA
Considerations. Initially, the registry contains the following Considerations. Initially, the registry contains the following
sub types for DEST_ADDR: sub types for DEST_ADDR:
skipping to change at page 12, line 5 skipping to change at page 13, line 25
5. SPI Security Parameter Index represented in 32 bits 5. SPI Security Parameter Index represented in 32 bits
OctetString: The OctetString contains the destination address OctetString: The OctetString contains the destination address
specification. specification.
In scenarios where a destination address is required (see Section 5), In scenarios where a destination address is required (see Section 5),
at least one of the subtypes 1 or 2 MUST be included in every Session at least one of the subtypes 1 or 2 MUST be included in every Session
Authorization Data Policy Element. Multiple DEST_ADDR attributes MAY Authorization Data Policy Element. Multiple DEST_ADDR attributes MAY
be included if multiple addresses have been authorized. The be included if multiple addresses have been authorized. The
destination address field of the resource reservation datagram (e.g., destination address field of the resource reservation datagram (e.g.,
RSVP PATH) MUST match one of the DEST_ADDR attributes contained in QoS NSLP Reserve) MUST match one of the DEST_ADDR attributes
this Session Authorization Data Policy Element. contained in this Session Authorization Data Policy Element.
At most, one instance of subtype 3 MAY be included in every Session At most, one instance of subtype 3 MAY be included in every Session
Authorization Data Policy Element. At most, one instance of subtype Authorization Data Policy Element. At most, one instance of subtype
4 MAY be included in every Session Authorization Data Policy Element. 4 MAY be included in every Session Authorization Data Policy Element.
Inclusion of a subtype 3 attribute does not prevent inclusion of a 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). subtype 4 attribute (i.e., both UDP and TCP ports may be authorized).
If no PORT attributes are specified, then all ports are considered If no PORT attributes are specified, then all ports are considered
valid; otherwise, only the specified ports are authorized for use. valid; otherwise, only the specified ports are authorized for use.
skipping to change at page 12, line 28 skipping to change at page 14, line 5
separate DEST_ADDR attribute. separate DEST_ADDR attribute.
3.2.4. Start time 3.2.4. Start time
START_TIME is used to identify the start time of the authorized START_TIME is used to identify the start time of the authorized
session and can be used to prevent replay attacks. If the session and can be used to prevent replay attacks. If the
AUTH_SESSION policy element is presented in a resource request, 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 network SHOULD reject the request if it is not received within a few
seconds of the start time specified. seconds of the start time specified.
+-------+-------+-------+-------+ 0 1 2 3
| Length |X-Type |SubType| 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
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... | Length | X-Type | SubType |
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4. Length: Length of the attribute, which MUST be > 4.
X-Type: START_TIME X-Type: START_TIME
SubType: SubType:
The following sub types for START_TIME are defined. IANA acts as a 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 registry for START_TIME sub-types as described in Section 7, IANA
Considerations. Initially, the registry contains the following sub Considerations. Initially, the registry contains the following sub
skipping to change at page 13, line 11 skipping to change at page 14, line 34
1. 1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305. 1. 1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305.
OctetString: The OctetString contains the start time. OctetString: The OctetString contains the start time.
3.2.5. End time 3.2.5. End time
END_TIME is used to identify the end time of the authorized session 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 and can be used to limit the amount of time that resources are
authorized for use (e.g., in prepaid session scenarios). authorized for use (e.g., in prepaid session scenarios).
+-------+-------+-------+-------+ 0 1 2 3
| Length |X-Type |SubType| 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
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... | Length | X-Type | SubType |
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4. Length: Length of the attribute, which MUST be > 4.
X-Type: END_TIME X-Type: END_TIME
SubType: SubType:
The following sub types for END_TIME are defined. IANA acts as a 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 registry for END_TIME sub-types as described in Section 7, IANA
Considerations. Initially, the registry contains the following sub Considerations. Initially, the registry contains the following sub
types for END_TIME: types for END_TIME:
1. NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305. 1. NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305.
OctetString: The OctetString contains the end time. OctetString: The OctetString contains the end time.
3.2.6. Authentication data 3.2.6. NSLP Object List
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.
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.
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
[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.
A summary of the NSLP_OBJECT_LIST attribute format is described
below.
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) |
+--------------+----------------+---------------+---------------+
Length: Length of the attribute, which MUST be > 4.
X-Type: NSLP_OBJECT_LIST
SubType: No sub types for NSLP_OBJECT_LIST are currently defined.
This field MUST be set to 0.
OctetString: The OctetString contains the authentication data of the
AUTH_SESSION.
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.
rsv: reserved bits and must be set to 0 (zero).
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.
padding: padding is required if the number of NSLP objects is even.
The padding field MUST be 16 bit set to 0.
3.2.7. Authentication data
The AUTHENTICATION_DATA attribute contains the authentication data of The AUTHENTICATION_DATA attribute contains the authentication data of
the AUTH_SESSION policy element and signs all the data in the policy the AUTH_SESSION policy element and signs all the data in the policy
element up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA element up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA
attribute has been included in the AUTH_SESSION policy element, it attribute has been included in the AUTH_SESSION policy element, it
MUST be the last attribute in the list. The algorithm used to MUST be the last attribute in the list. The algorithm used to
compute the authentication data depends on the AUTH_ENT_ID SubType compute the authentication data depends on the AUTH_ENT_ID SubType
field. See Section 4 entitled Integrity of the AUTH_SESSION policy field. See Section 4 entitled Integrity of the AUTH_SESSION policy
element. element.
A summary of AUTHENTICATION_DATA attribute format is described below. A summary of AUTHENTICATION_DATA attribute format is described below.
+-------+-------+-------+-------+ 0 1 2 3
| Length |X-Type |SubType| 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
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... | Length | X-Type | SubType |
+-------+-------+-------+-------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// OctetString ... //
+---------------------------------------------------------------+
Length: Length of the attribute, which MUST be > 4. Length: Length of the attribute, which MUST be > 4.
X-Type: AUTHENTICATION_DATA X-Type: AUTHENTICATION_DATA
SubType: No sub types for AUTHENTICATION_DATA are currently defined. SubType: No sub types for AUTHENTICATION_DATA are currently defined.
This field MUST be set to 0. This field MUST be set to 0.
OctetString: The OctetString contains the authentication data of the OctetString: The OctetString contains the authentication data of the
AUTH_SESSION. AUTH_SESSION.
skipping to change at page 15, line 16 skipping to change at page 18, line 16
This section describes how to ensure the integrity of the policy This section describes how to ensure the integrity of the policy
element is preserved. element is preserved.
4.1. Shared symmetric keys 4.1. Shared symmetric keys
In shared symmetric key environments, the AUTH_ENT_ID MUST be of In shared symmetric key environments, the AUTH_ENT_ID MUST be of
subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or
URI. An example AUTH_SESSION object is shown below. URI. An example AUTH_SESSION object is shown below.
+--------------+--------------+--------------+--------------+ 0 1 2 3
|1000| Type = AUTH_SESSION |0000| Object length | 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 | AUTH_ENT_ID | IPV4_ADDRESS | |1|0|0|0| Type = AUTH_SESSION |0|0|0|0| Object Length |
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString (The authorizing entity's Identifier) | | Length | AUTH_ENT_ID | IPV4_ADDRESS |
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |AUTH DATA. | zero | | OctetString ... (The authorizing entity's Identifier) |
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY_ID | | Length | AUTH_DATA | zero |
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString (Authentication data) ... | KEY_ID |
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
4.1.1. Operational Setting using shared symmetric keys 4.1.1. Operational Setting using shared symmetric keys
This assumes both the Authorizing Entity and the Network router/PDP This assumes both the Authorizing Entity and the Network router/PDP
are provisioned with shared symmetric keys and with policies are provisioned with shared symmetric keys and with policies
detailing which algorithm to be used for computing the authentication detailing which algorithm to be used for computing the authentication
data along with the expected length of the authentication data for data along with the expected length of the authentication data for
that particular algorithm. that particular algorithm.
Key maintenance is outside the scope of this document, but Key maintenance is outside the scope of this document, but
skipping to change at page 16, line 27 skipping to change at page 19, line 29
and is not well applicable for this particular usage scenario. and is not well applicable for this particular usage scenario.
Hence, Kerberos support will not be provided by this specification. Hence, Kerberos support will not be provided by this specification.
4.3. Public Key 4.3. Public Key
In a public key environment, the AUTH_ENT_ID MUST be of the subtypes: 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 X509_V3_CERT or PGP_CERT. The authentication data is used for
authenticating the authorizing entity. An example of the public key authenticating the authorizing entity. An example of the public key
AUTH_SESSION policy element is shown below. AUTH_SESSION policy element is shown below.
+--------------+--------------+--------------+--------------+ 0 1 2 3
|1000| Type = AUTH_SESSION |0000| Object length | 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 | AUTH_ENT_ID | PGP_CERT | |1|0|0|0| Type = AUTH_SESSION |0|0|0|0| Object Length |
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString (Authorizing entity Digital Certificate) ... | Length | AUTH_ENT_ID | PGP_CERT |
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |AUTH DATA. | zero | | OctetString ... (Authorizing entity Digital Certificate) |
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString (Authentication data) ... | Length | AUTH_DATA | zero |
+--------------+--------------+--------------+--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
4.3.1. Operational Setting for public key based authentication 4.3.1. Operational Setting for public key based authentication
Public key based authentication assumes the following: Public key based authentication assumes the following:
o Authorizing entities have a pair of keys (private key and public o Authorizing entities have a pair of keys (private key and public
key). key).
o Private key is secured with the authorizing entity. o Private key is secured with the authorizing entity.
skipping to change at page 19, line 5 skipping to change at page 21, line 38
o Extract the hash algorithm and the length of the hashed data by o Extract the hash algorithm and the length of the hashed data by
parsing the PGP signature packet. parsing the PGP signature packet.
o The recipient independently computes the message digest. This o The recipient independently computes the message digest. This
message digest and the signer's public key are used to verify the message digest and the signer's public key are used to verify the
signature value. signature value.
This verification ensures integrity, non-repudiation and data origin. This verification ensures integrity, non-repudiation and data origin.
4.4. HMAC Signed
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:
o SOURCE_ADDR the source address of the entity that created the HMAC
o 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.
o NSLP_OBJECT_LIST this attribute lists all NSLP objects that are
included into HMAC calculation.
o AUTHENTICATION_DATA this attribute contains the Key-ID that is
used for HMAC calculation as well as the HMAC data itself
[RFC2104].
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.
Figure 12 shows an example of an object that is used for integrity
protection of NSLP messages.
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 |
+---------------------------------------------------------------+
Example for an AUTH_SESSION_OBJECT that provides integrity protection
for NSLP messages
Figure 12
5. Framework 5. Framework
RFC3521 [RFC3521] describes a framework in which the AUTH_SESSION RFC3521 [RFC3521] describes a framework in which the AUTH_SESSION
policy element may be utilized to transport information required for policy element may be utilized to transport information required for
authorizing resource reservation for media flows. RFC3521 introduces authorizing resource reservation for media flows. RFC3521 introduces
4 different models: 4 different models:
1. The coupled model 1. The coupled model
2. The associated model with one policy server 2. The associated model with one policy server
skipping to change at page 21, line 15 skipping to change at page 26, line 15
6. Message Processing Rules 6. Message Processing Rules
This section discusses the message processing related to the This section discusses the message processing related to the
AUTH_SESSION object. We describe the details of the QoS NSLP and 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 NAT/FW NSLP. New NSLP protocols should use the same logic in making
use of the AUTH_SESSION object. use of the AUTH_SESSION object.
6.1. Generation of the AUTH_SESSION by the authorizing entity 6.1. Generation of the AUTH_SESSION by the authorizing entity
1. Generate the AUTH_SESSION policy element with the appropriate 1. Generate the AUTH_SESSION policy element with the appropriate
contents as specified in Section 5. contents as specified in Section 3.
2. If authentication is needed, the entire AUTH_SESSION policy 2. If authentication is needed, the entire AUTH_SESSION policy
element is constructed, excluding the length, type and subtype element is constructed, excluding the length, type and subtype
fields of the AUTH_SESSION field. Note that the message MUST fields of the AUTH_SESSION field. Note that the message MUST
include either a START_TIME or a SESSION_ID (See Section 9), to include a START_TIME to prevent replay attacks. The output of
prevent replay attacks. The output of the authentication the authentication algorithm, plus appropriate header
algorithm, plus appropriate header information, is appended to information, is appended as AUTHENTICATION_DATA attribute to the
the AUTH_SESSION policy element. AUTH_SESSION policy element.
6.2. Processing within the QoS NSLP 6.2. Processing within the QoS NSLP
The AUTH_SESSION object may be used with QoS NSLP QUERY and RESERVE The AUTH_SESSION object may be used with QoS NSLP QUERY and RESERVE
messages to authorize the query operation for network resources, and messages to authorize the query operation for network resources, and
a resource reservation request, respectively. a resource reservation request, respectively.
Moreover, the AUTH_SESSION object may also be used with RESPONSE Moreover, the AUTH_SESSION object may also be used with RESPONSE
messages in order to indicate that the authorizing entity changed the messages in order to indicate that the authorizing entity changed the
original request. For example, the session start or end times may original request. For example, the session start or end times may
skipping to change at page 21, line 47 skipping to change at page 26, line 47
If the QoS NSIS Initiator (QNI) receives a RESPONSE message with an If the QoS NSIS Initiator (QNI) receives a RESPONSE message with an
AUTH_SESSION object, the QNI MUST inspect the AUTH_SESSION object to AUTH_SESSION object, the QNI MUST inspect the AUTH_SESSION object to
see what authentication attribute was changed by an authorizing see what authentication attribute was changed by an authorizing
entity. The QNI SHOULD also silently accept AUTH_SESSION objects in entity. The QNI SHOULD also silently accept AUTH_SESSION objects in
RESPONSE message which do not indicate any change to the original RESPONSE message which do not indicate any change to the original
authorization request. authorization request.
6.2.1. Message Generation 6.2.1. Message Generation
A QoS NSLP message is created as specified in [QoS NSLP]. A QoS NSLP message is created as specified in
[I-D.ietf-nsis-qos-nslp].
1. The policy element received from the authorizing entity MUST be 1. The policy element received from the authorizing entity MUST be
copied without modification into the AUTH_SESSION object. copied without modification into the AUTH_SESSION object.
2. The AUTH_SESSION object (containing the policy element) is 2. The AUTH_SESSION object (containing the policy element) is
inserted in the NSLP message in the appropriate place. inserted in the NSLP message in the appropriate place.
6.2.2. Message Reception 6.2.2. Message Reception
The QoS NSLP message is processed as specified in [QOS NSLP] with The QoS NSLP message is processed as specified in
following modifications. [I-D.ietf-nsis-qos-nslp] with following modifications.
1. If the QNE is policy aware then it SHOULD use the Diameter QoS 1. If the QNE is policy aware then it SHOULD use the Diameter QoS
application or the RADIUS QoS protocol to communicate with the application or the RADIUS QoS protocol to communicate with the
PDP. To construct the AAA message it is necessary to extract 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 AUTH_SESSION object and the QoS related objects from the QoS NSLP
message and to craft the respective RADIUS or Diameter message. message and to craft the respective RADIUS or Diameter message.
The message processing and object format is described in the The message processing and object format is described in the
respective RADIUS or Diameter QoS protocol, respectively. If the respective RADIUS or Diameter QoS protocol, respectively. If the
QNE is policy unaware then it ignores the policy data objects and QNE is policy unaware then it ignores the policy data objects and
continues processing the NSLP message. continues processing the NSLP message.
2. If the response from the PDP is negative the request must be 2. If the response from the PDP is negative the request must be
rejected. A negative response in RADIUS is an Access-Reject and rejected. A negative response in RADIUS is an Access-Reject and
in Diameter is based on the 'DIAMETER_SUCCESS' value in the in Diameter is based on the 'DIAMETER_SUCCESS' value in the
Result-Code AVP of the QoS-Authz-Answer (QAA) message. The QNE Result-Code AVP of the QoS-Authz-Answer (QAA) message. The QNE
must contruct and send a RESPONSE message with the status of must contruct and send a RESPONSE message with the status of
authorization failure as specified in [QoS NSLP]. authorization failure as specified in [I-D.ietf-nsis-qos-nslp].
3. Continue processing the NSIS message. 3. Continue processing the NSIS message.
6.2.3. Authorization (QNE/PDP) 6.2.3. Authorization (QNE/PDP)
1. Retrieve the policy element from the AUTH_SESSION object. Check 1. Retrieve the policy element from the AUTH_SESSION object. Check
the PE type field and return an error if the identity type is not the PE type field and return an error if the identity type is not
supported. supported.
2. Verify the message integrity. 2. Verify the message integrity.
skipping to change at page 23, line 31 skipping to change at page 28, line 31
policy element then the appropriate actions described the respective policy element then the appropriate actions described the respective
AAA document need to be taken. AAA document need to be taken.
The QNE node MUST return a RESPONSE message with the INFO_SPEC error The QNE node MUST return a RESPONSE message with the INFO_SPEC error
code Authorization Failure as defined in the QoS NSLP specification. code Authorization Failure as defined in the QoS NSLP specification.
The QNE MAY include an INFO_SPEC Object Value Info to indicate which The QNE MAY include an INFO_SPEC Object Value Info to indicate which
AUTH_SESSION attribute created the error. AUTH_SESSION attribute created the error.
6.3. Processing with the NAT/FW NSLP 6.3. Processing with the NAT/FW NSLP
This section presents processing tules for the NAT/FW NSLP. This section presents processing rules for the NAT/FW NSLP
[I-D.ietf-nsis-nslp-natfw].
6.3.1. Message Generation 6.3.1. Message Generation
A NAT/FW NSLP message is created as specified in [NATFW NSLP]. A NAT/FW NSLP message is created as specified in
[I-D.ietf-nsis-nslp-natfw].
1. The policy element received from the authorizing entity MUST be 1. The policy element received from the authorizing entity MUST be
copied without modification into the AUTH_SESSION object. copied without modification into the AUTH_SESSION object.
2. The AUTH_SESSION object (containing the policy element) is 2. The AUTH_SESSION object (containing the policy element) is
inserted in the NATFW NSLP message in the appropriate place. inserted in the NATFW NSLP message in the appropriate place.
6.3.2. Message Reception 6.3.2. Message Reception
The NAT/FW NSLP message is processed as specified in [NATFW NSLP] The NAT/FW NSLP message is processed as specified in
with following modifications. [I-D.ietf-nsis-nslp-natfw] with following modifications.
1. If the router is policy aware then it SHOULD use the Diameter 1. If the router is policy aware then it SHOULD use the Diameter
application or the RADIUS protocol to communicate with the PDP. application or the RADIUS protocol to communicate with the PDP.
To construct the AAA message it is necessary to extract the To construct the AAA message it is necessary to extract the
AUTH_SESSION element and the NATFW policy rule related objects AUTH_SESSION element and the NATFW policy rule related objects
from the NSLP message and to craft the respective RADIUS or from the NSLP message and to craft the respective RADIUS or
Diameter message. The message processing and object format is Diameter message. The message processing and object format is
described in the respective RADIUS or Diameter protocols, described in the respective RADIUS or Diameter protocols,
respectively. If the router is policy unaware then it ignores respectively. If the router is policy unaware then it ignores
the policy data objects and continues processing the NSLP the policy data objects and continues processing the NSLP
skipping to change at page 24, line 37 skipping to change at page 29, line 39
authentication algorithm to be used along with the expected authentication algorithm to be used along with the expected
length of the authentication data and the shared symmetric key length of the authentication data and the shared symmetric key
for the authorizing entity. Verify that the indicated length for the authorizing entity. Verify that the indicated length
of the authentication data is consistent with the configured of the authentication data is consistent with the configured
table entry and validate the authentication data. table entry and validate the authentication data.
* Public Key: Validate the certificate chain against the trusted * Public Key: Validate the certificate chain against the trusted
Certificate Authority (CA) and validate the message signature Certificate Authority (CA) and validate the message signature
using the public key. using the public key.
* - Kerberos based usage is not provided by this document. * Kerberos based usage is not provided by this document.
3. Once the identity of the authorizing entity and the validity of 3. Once the identity of the authorizing entity and the validity of
the service request has been established, the authorizing router/ the service request has been established, the authorizing router/
PDP MUST then consult its authorization policy in order to deter PDP MUST then consult its authorization policy in order to deter
mine whether or not the specific request is authorized. To the mine whether or not the specific request is authorized. To the
extent to which these access control decisions require extent to which these access control decisions require
supplementary information, routers/PDPs MUST ensure that supplementary information, routers/PDPs MUST ensure that
supplementary information is obtained securely. supplementary information is obtained securely.
6.3.4. Error Signaling 6.3.4. Error Signaling
When the PDP (e.g., a RADIUS or Diameter server) fails to verify the When the PDP (e.g., a RADIUS or Diameter server) fails to verify the
AUTH_SESSION element then the appropriate actions described the AUTH_SESSION element then the appropriate actions described the
respective AAA document need to be taken. The NATFW NSLP node MUST respective AAA document need to be taken. The NATFW NSLP node MUST
return an error message of class 'Permanent failure' (0x5) with error return an error message of class 'Permanent failure' (0x5) with error
code 'Authorization failed' (0x02). code 'Authorization failed' (0x02).
6.4. Integrity Protection of NSLP messages
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.
The sender of an NSLP message creates an AUTH_SESSION object that
contains AUTH_ENT_ID attribute set to HMAC_SIGNED (cf. Section 4.4)
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.
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.
7. Security Considerations 7. Security Considerations
This document describes a mechanism for session authorization to This document describes a mechanism for session authorization to
prevent theft of service. There are three types of security issues prevent theft of service. There are three types of security issues
to consider: protectiong against replay attacks, integrity of the to consider: protection against replay attacks, integrity of the
AUTH_SESSION object, and the choice of the authentication algorithms AUTH_SESSION object, and the choice of the authentication algorithms
and keys. and keys.
The first issue, replay attacks, MUST be prevented. In the non- The first issue, replay attacks, MUST be prevented. In the non-
associated model, the AUTH_SESSION object MUST include a START_TIME associated model, the AUTH_SESSION object MUST include a START_TIME
field and the Policy Servers MUST support NTP to ensure proper clock field and the Policy Servers MUST support NTP to ensure proper clock
synchronization. Failure to ensure proper clock synchronization will synchronization. Failure to ensure proper clock synchronization will
allow replay attacks since the clocks of the different network allow replay attacks since the clocks of the different network
entities may not be in synch. The start time is used to verify that 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 the request is not being replayed at a later time. In all other
skipping to change at page 27, line 15 skipping to change at page 32, line 15
8. IANA Considerations 8. IANA Considerations
This specification makes the following request to IANA: This specification makes the following request to IANA:
1. Assign a new object value for the AUTH_SESSION object from the 1. Assign a new object value for the AUTH_SESSION object from the
shared NSLP object value space. shared NSLP object value space.
2. All AUTH_SESSION object internal values and numbers should be 2. All AUTH_SESSION object internal values and numbers should be
taken from the allocations already done for RFC 3520 [RFC3520]. taken from the allocations already done for RFC 3520 [RFC3520].
Yet, this specification does make use of two X-types introduced Yet, this specification does make use of two X-types introduced
by RFC3520: Session ID and Resources. by RFC3520: Session_ID and Resources.
9. Acknowledgements 9. Acknowledgments
This document is based on the RFC 3520 [RFC3520] and credit therefore This document is based on the RFC 3520 [RFC3520] and credit therefore
goes to the authors of RFC 3520, namely Louis-Nicolas Hamer, Brett goes to the authors of RFC 3520, namely Louis-Nicolas Hamer, Brett
Kosinski, Bill Gage and Hugh Shieh. Kosinski, Bill Gage and Hugh Shieh. Part of this work was funded by
Deutsche Telekom Laboratories within the context of the ScaleNet
project.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-nsis-nslp-natfw] [I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-13 (work in "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
progress), October 2006. draft-ietf-nsis-nslp-natfw-18 (work in progress),
February 2008.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-12 (work in Signalling Transport", draft-ietf-nsis-ntlp-15 (work in
progress), March 2007. progress), February 2008.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., "NSLP for Quality-of-Service Signaling", Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
draft-ietf-nsis-qos-nslp-12 (work in progress), Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16
October 2006. (work in progress), February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4306, December 2005.
RFC 4080, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
10.2. Informative References 10.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
skipping to change at page 31, line 5 skipping to change at page 35, line 6
"Session Authorization Policy Element", RFC 3520, "Session Authorization Policy Element", RFC 3520,
April 2003. April 2003.
[RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for
Session Set-up with Media Authorization", RFC 3521, Session Set-up with Media Authorization", RFC 3521,
April 2003. April 2003.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004. RFC 3852, July 2004.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework",
RFC 4080, June 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
Authors' Addresses Authors' Addresses
Jukka Manner Jukka Manner
Helsinki University of Technology (TKK) Helsinki University of Technology (TKK)
P.O. Box 5400 P.O. Box 3000
Espoo FIN-02015 TKK Espoo FI-02015 TKK
Finland Finland
Phone: +358 9 451 4161 Phone: +358 9 451 2481
Email: jmanner@tml.hut.fi Email: jukka.manner@tkk.fi
URI: http://www.tml.tkk.fi/~jmanner/
Martin Stiemerling Martin Stiemerling
Network Laboratories, NEC Europe Ltd. Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 (0) 6221 4342 113 Phone: +49 (0) 6221 4342 113
Email: stiemerling@netlab.nec.de Email: stiemerling@nw.neclab.eu
URI: http://www.stiemerling.org URI: http://www.stiemerling.org
Hannes Tschofenig Hannes Tschofenig
Siemens Networks GmbH & Co KG Nokia Siemens Networks
Otto-Hahn-Ring 6 Linnoitustie 6
Munich, Bavaria 81739 Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Roland Bless
Institute of Telematics, Universitaet Karlsruhe (TH)
Zirkel 2, Building 20.20
Karlsruhe 76131
Germany Germany
Phone: +49 89 636 40390 Phone: +49 721 608 6413
Email: Hannes.Tschofenig@siemens.com Email: bless@tm.uka.de
URI: http://www.tschofenig.com URI: http://www.tm.uka.de/~bless
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 62 change blocks. 
187 lines changed or deleted 406 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/