< draft-ietf-nsis-nslp-auth-06.txt   draft-ietf-nsis-nslp-auth-07.txt >
Network Working Group J. Manner Network Working Group J. Manner
Internet-Draft Aalto Univ Internet-Draft Aalto Univ
Intended status: Experimental M. Stiemerling Intended status: Experimental M. Stiemerling
Expires: February 3, 2011 NEC Expires: March 26, 2011 NEC
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
R. Bless, Ed. R. Bless, Ed.
KIT KIT
August 02, 2010 September 22, 2010
Authorization for NSIS Signaling Layer Protocols Authorization for NSIS Signaling Layer Protocols
draft-ietf-nsis-nslp-auth-06.txt draft-ietf-nsis-nslp-auth-07.txt
Abstract Abstract
Signaling layer protocols specified within the NSIS framework may Signaling layer protocols specified within the NSIS framework may
rely on the GIST (General Internet Signaling Transport) protocol to rely on the GIST (General Internet Signaling Transport) protocol to
handle authorization. Still, the signaling layer protocol above GIST handle authorization. Still, the signaling layer protocol above GIST
itself may require separate authorization to be performed when a node itself 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
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on February 3, 2011. This Internet-Draft will expire on March 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.2.5. Start time . . . . . . . . . . . . . . . . . . . . . . 14 3.2.5. Start time . . . . . . . . . . . . . . . . . . . . . . 14
3.2.6. End time . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.6. End time . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. NSLP Object List . . . . . . . . . . . . . . . . . . . 15 3.2.7. NSLP Object List . . . . . . . . . . . . . . . . . . . 15
3.2.8. Authentication data . . . . . . . . . . . . . . . . . 17 3.2.8. Authentication data . . . . . . . . . . . . . . . . . 17
4. Integrity of the SESSION_AUTH policy element . . . . . . . . . 18 4. Integrity of the SESSION_AUTH policy element . . . . . . . . . 18
4.1. Shared symmetric keys . . . . . . . . . . . . . . . . . . 18 4.1. Shared symmetric keys . . . . . . . . . . . . . . . . . . 18
4.1.1. Operational Setting using shared symmetric keys . . . 18 4.1.1. Operational Setting using shared symmetric keys . . . 18
4.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.1. Operational Setting for public key based 4.3.1. Operational Setting for public key based
authentication . . . . . . . . . . . . . . . . . . . . 20 authentication . . . . . . . . . . . . . . . . . . . . 21
4.4. HMAC Signed . . . . . . . . . . . . . . . . . . . . . . . 22 4.4. HMAC Signed . . . . . . . . . . . . . . . . . . . . . . . 23
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. The Coupled Model . . . . . . . . . . . . . . . . . . . . 25 5.1. The Coupled Model . . . . . . . . . . . . . . . . . . . . 26
5.2. The associated model with one policy server . . . . . . . 25 5.2. The associated model with one policy server . . . . . . . 26
5.3. The associated model with two policy servers . . . . . . . 26 5.3. The associated model with two policy servers . . . . . . . 27
5.4. The non-associated model . . . . . . . . . . . . . . . . . 26 5.4. The non-associated model . . . . . . . . . . . . . . . . . 27
6. Message Processing Rules . . . . . . . . . . . . . . . . . . . 27 6. Message Processing Rules . . . . . . . . . . . . . . . . . . . 28
6.1. Generation of the SESSION_AUTH by the authorizing 6.1. Generation of the SESSION_AUTH by the authorizing
entity . . . . . . . . . . . . . . . . . . . . . . . . . . 27 entity . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. Processing within the QoS NSLP . . . . . . . . . . . . . . 27 6.2. Processing within the QoS NSLP . . . . . . . . . . . . . . 28
6.2.1. Message Generation . . . . . . . . . . . . . . . . . . 27 6.2.1. Message Generation . . . . . . . . . . . . . . . . . . 28
6.2.2. Message Reception . . . . . . . . . . . . . . . . . . 28 6.2.2. Message Reception . . . . . . . . . . . . . . . . . . 29
6.2.3. Authorization (QNE/PDP) . . . . . . . . . . . . . . . 28 6.2.3. Authorization (QNE or PDP) . . . . . . . . . . . . . . 29
6.2.4. Error Signaling . . . . . . . . . . . . . . . . . . . 29 6.2.4. Error Signaling . . . . . . . . . . . . . . . . . . . 30
6.3. Processing with the NAT/FW NSLP . . . . . . . . . . . . . 29 6.3. Processing with the NAT/FW NSLP . . . . . . . . . . . . . 30
6.3.1. Message Generation . . . . . . . . . . . . . . . . . . 29 6.3.1. Message Generation . . . . . . . . . . . . . . . . . . 31
6.3.2. Message Reception . . . . . . . . . . . . . . . . . . 30 6.3.2. Message Reception . . . . . . . . . . . . . . . . . . 31
6.3.3. Authorization (Router/PDP) . . . . . . . . . . . . . . 30 6.3.3. Authorization (Router/PDP) . . . . . . . . . . . . . . 31
6.3.4. Error Signaling . . . . . . . . . . . . . . . . . . . 31 6.3.4. Error Signaling . . . . . . . . . . . . . . . . . . . 32
6.4. Integrity Protection of NSLP messages . . . . . . . . . . 31 6.4. Integrity Protection of NSLP messages . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . . 40
10.2. Informative References . . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
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
skipping to change at page 5, line 18 skipping to change at page 5, line 18
suite of protocols for the next generation in Internet signaling. suite of protocols for the next generation in Internet signaling.
The design is based on a generalized transport protocol for signaling The design is based on a generalized transport protocol for signaling
applications, the General Internet Signaling Transport (GIST) applications, the General Internet Signaling Transport (GIST)
[I-D.ietf-nsis-ntlp], and various kinds of signaling applications. [I-D.ietf-nsis-ntlp], and various kinds of signaling applications.
Two signaling applications and their NSIS Signaling Layer Protocol Two signaling applications and their NSIS Signaling Layer Protocol
(NSLP) have been designed, a Quality of Service application (QoS (NSLP) have been designed, a Quality of Service application (QoS
NSLP) [I-D.ietf-nsis-qos-nslp] and a NAT/firewall application NSLP) [I-D.ietf-nsis-qos-nslp] and a NAT/firewall application
(NAT/FW) [I-D.ietf-nsis-nslp-natfw]. (NAT/FW) [I-D.ietf-nsis-nslp-natfw].
The basic security architecture for NSIS is based on a chain-of-trust The basic security architecture for NSIS is based on a chain-of-trust
model, where each GIST hop may chose the appropriate security model, where each GIST hop may choose the appropriate security
protocol, taking into account the signaling application requirements. protocol, taking into account the signaling application requirements.
For instance, communication between two directly adjacent GIST peers For instance, communication between two directly adjacent GIST peers
may be secured via TCP/TLS. On the one hand this model is may be secured via TCP/TLS. On the one hand 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. On signaling applications to leave the handling of security to GIST. On
the other hand, several sessions of different signaling applications the other hand, several sessions of different signaling applications
are then multiplexed onto the same GIST TLS connection. are then multiplexed onto the same GIST TLS connection.
Yet, in order to allow for finer-grain per-session or per-user Yet, in order to allow for finer-grain per-session or per-user
admission control, it is necessary to provide a mechanism for admission control, it is necessary to provide a mechanism for
skipping to change at page 5, line 51 skipping to change at page 5, line 51
all NSLPs. The scheme is based on third-party tokens. A trusted all NSLPs. The scheme is based on third-party tokens. A trusted
third party provides authentication tokens to clients and allows third party provides authentication tokens to clients and allows
verification of the information by the network elements. The 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 it based on admission policy (e.g., they perform a and then process it based on admission policy (e.g., they perform a
resource reservation or change bindings or firewall filter). This resource reservation or change bindings or firewall filter). This
work is based on RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. work is based on RFC 3520 [RFC3520] and RFC 3521 [RFC3521].
The default operation of the authorization is to add one The default operation when using NSLP layer session authorization is
authorization policy object. Yet, in order to support end-to-end to add one authorization policy object. Yet, in order to support
signaling and request authorization from different networks, a host end-to-end signaling and request authorization from different
initiating an NSLP signaling session may add more than one networks, a host initiating an NSLP signaling session may add more
SESSION_AUTH object in the message. The identifier of the than one SESSION_AUTH object in the message. The identifier of the
authorizing entity can be used by the network elements to use the authorizing entity can be used by the network elements to use the
third party they trust to verify the request. third party they trust to verify the request.
3. Session Authorization Object 3. Session Authorization Object
This section presents a new NSLP layer object called session This section presents a new NSLP layer object called session
authorization (SESSION_AUTH). The SESSION_AUTH object can be used in authorization (SESSION_AUTH). The SESSION_AUTH object can be used in
the currently specified and future NSLP protocols. the currently specified and future NSLP protocols.
The authorization attributes follow the format and specification The authorization attributes follow the format and specification
skipping to change at page 16, line 8 skipping to change at page 16, line 8
3.2.7. NSLP Object List 3.2.7. NSLP Object List
The NSLP_OBJECT_LIST attribute contains a list of NSLP objects types 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 that are used in the keyed-hash computation whose result is given in
the AUTHENTICATION_DATA attribute. This allows for an integrity the AUTHENTICATION_DATA attribute. This allows for an integrity
protection of NSLP PDUs. If an NSLP_OBJECT_LIST attribute has been protection of NSLP PDUs. If an NSLP_OBJECT_LIST attribute has been
included in the SESSION_AUTH policy element, an AUTHENTICATION_DATA included in the SESSION_AUTH policy element, an AUTHENTICATION_DATA
attribute MUST also be present. attribute MUST also be present.
The creator of this attribute lists every NSLP object type whose NSLP The creator of this attribute lists every NSLP object type whose NSLP
PDU object was included in the computation of the hash. The receiver PDU object was included in the computation of the hash. The hash
can verify the integrity of the NSLP PDU by computing a hash over all computation has to follow the order of the NSLP object types as
NSLP objects that are listed in this attribute including all the specified by the list. The receiver can verify the integrity of the
attributes of the authorization object. Since all NSLP object types NSLP PDU by computing a hash over all NSLP objects that are listed in
are unique over all different NSLPs, this will work for any NSLP. this attribute (in the given order) 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 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 MUST be always included in the HMAC. Since they are not carried
within the NSLP itself, but only within GIST, they must be delivered within the NSLP itself, but only within GIST, they have to be
via the GIST API and normalized to their network representation from provided for HMAC calculation, e.g., they can be delivered via the
[I-D.ietf-nsis-ntlp] again before calculating the hash. These values GIST API. They MUST be normalized to their network representation
are hashed first, before any other NSLP object values that are from [I-D.ietf-nsis-ntlp] again before calculating the hash. These
included in the hash computation. values MUST be hashed first (in order sessionID, NSLPID, MRI), before
any other NSLP object values that are included in the hash
computation.
A summary of the NSLP_OBJECT_LIST attribute format is described A summary of the NSLP_OBJECT_LIST attribute format is described
below. below.
0 1 2 3 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 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 | | Length | NSLP_OBJ_LIST | zero |
+---------------+---------------+-------+-------+---------------+ +---------------+---------------+-------+-------+---------------+
| # of signed NSLP objects = n | rsv | NSLP object type (1) | | # of signed NSLP objects = n | rsv | NSLP object type (1) |
skipping to change at page 16, line 47 skipping to change at page 16, line 51
Length: Length of the attribute, which MUST be > 4. Length: Length of the attribute, which MUST be > 4.
X-Type: NSLP_OBJECT_LIST X-Type: NSLP_OBJECT_LIST
SubType: No sub types for NSLP_OBJECT_LIST are currently defined. SubType: No sub types for NSLP_OBJECT_LIST are currently defined.
This field MUST be set to 0 and ignored upon reception. This field MUST be set to 0 and ignored upon reception.
# of signed NSLP objects: The number n of NSLP object types that # 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. follow. n=0 is allowed, i.e., only a padding field is contained then.
rsv: reserved bits and must be set to 0 (zero) and ignored upon rsv: reserved bits and MUST be set to 0 (zero) and ignored upon
reception. reception.
NSLP object type: the NSLP 12-bit object type identifier of the NSLP object type: the NSLP 12-bit object type identifier of the
object that was included in the hash calculation. The NSLP object object that was included in the hash calculation. The NSLP object
type values comprise only 12 bit, so four bits per type value are type values comprise only 12 bit, so four bits per type value are
currently not used within the list. Depending on the number of currently not used within the list. Depending on the number of
signed objects, a corresponding padding word of 16 bit must be signed objects, a corresponding padding word of 16 bit must be
supplied. supplied.
padding: padding MUST be added if the number of NSLP objects is even padding: padding MUST be added if the number of NSLP objects is even
skipping to change at page 19, line 4 skipping to change at page 19, line 4
SESSION_AUTH implementations MUST at least provide the ability to SESSION_AUTH implementations MUST at least provide the ability to
manually configure keys and their parameters. The key used to manually configure keys and their parameters. The key used to
produce the authentication data is identified by the AUTH_ENT_ID produce the authentication data is identified by the AUTH_ENT_ID
field. Since multiple keys may be configured for a particular 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 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 key ID to be used to identify the appropriate key. Each key must
also be configured with lifetime parameters for the time period also be configured with lifetime parameters for the time period
within which it is valid as well as an associated cryptographic within which it is valid as well as an associated cryptographic
algorithm parameter specifying the algorithm to be used with the key. algorithm parameter specifying the algorithm to be used with the key.
At a minimum, all SESSION_AUTH implementations MUST support the HMAC- At a minimum, all SESSION_AUTH implementations MUST support the HMAC-
MD5-128 [RFC1321] [RFC2104] cryptographic algorithm for computing the SHA2-256 [RFC4868] [RFC2104] cryptographic algorithm for computing
authentication data. the authentication data.
It is good practice to regularly change keys. Keys MUST be It is good practice to regularly change keys. Keys MUST be
configurable such that their lifetimes overlap allowing smooth configurable such that their lifetimes overlap allowing smooth
transitions between keys. At the midpoint of the lifetime overlap transitions between keys. At the midpoint of the lifetime overlap
between two keys, senders should transition from using the current between two keys, senders should transition from using the current
key to the next/longer-lived key. Meanwhile, receivers simply accept key to the next/longer-lived key. Meanwhile, receivers simply accept
any identified key received within its configured lifetime and reject any identified key received within its configured lifetime and reject
those that are not. those that are not.
4.2. Kerberos 4.2. Kerberos
Since Kerberos [RFC4120] is widely used for end-user authorization, Since Kerberos [RFC4120] is widely used for end-user authorization,
e.g., in Windows domains, it is well suited for being used in the e.g., in Windows domains, it is well suited for being used in the
context of user-based authorization for NSIS sessions. For instance, context of user-based authorization for NSIS sessions. For instance,
a user may request a ticket for authorization of installing rules in a user may request a ticket for authorization of installing rules in
an NATFW-capable router. an NATFW-capable router.
In a Kerberos environment, it is assumed that the user of the In a Kerberos environment, it is assumed that the user of the
requesting NSLP host requests a ticket from the (the Kerberos Key requesting NSLP host requests a ticket from the (the Kerberos Key
Distribution Center - KDC) for using the NSLP Node (router) as Distribution Center - KDC) for using the NSLP Node (router) as
resource (target service). The ticket can be presented to the NSLP resource (target service). The NSLP requesting host (client) can
node via Kerberos by sending a KRB_CRED message to the NSLP node present the ticket to the NSLP node via Kerberos by sending a
independently but prior to the NSLP exchange. Thus, the principal KRB_CRED message to the NSLP node independently but prior to the NSLP
name of the service must be known in advance, though the exact IP exchange. Thus, the principal name of the service must be known at
address may not be known in advance. How the name is assigned and the client in advance, though the exact IP address may not be known
made available to the client is implementation specific. The in advance. How the name is assigned and made available to the
extracted common session key can subsequently be used for using the client is implementation specific. The extracted common session key
HMAC_SIGNED variant of the SESSION_AUTH object. can subsequently be used for using the HMAC_SIGNED variant of the
SESSION_AUTH object.
Another option is to encapsulate the credentials in the AUTH_DATA Another option is to encapsulate the credentials in the AUTH_DATA
portion of the SESSION_AUTH object. In this case the AUTH_ENT_ID portion of the SESSION_AUTH object. In this case the AUTH_ENT_ID
MUST be of the subtype KRB_PRINCIPAL. The KRB_PRINCIPAL field is MUST be of the subtype KRB_PRINCIPAL. The KRB_PRINCIPAL field is
defined as the Fully Qualified Kerberos Principal name of the defined as the Fully Qualified Kerberos Principal name of the
authorizing entity. The AUTH_DATA portion of the SESSION_AUTH object authorizing entity. The AUTH_DATA portion of the SESSION_AUTH object
contains the KRB_CRED message that the receiving NSLP node has to contains the KRB_CRED message that the receiving NSLP node has to
extract and verify. A second SESSION_AUTH object of type HMAC_SIGNED extract and verify. A second SESSION_AUTH object of type HMAC_SIGNED
SHOULD protect the integrity of the NSLP message, including the prior SHOULD protect the integrity of the NSLP message, including the prior
SESSION_AUTH object. The session key included in the first SESSION_AUTH object. The session key included in the first
SESSION_AUTH object has to be used for HMAC calculation. SESSION_AUTH object has to be used for HMAC calculation.
An example of the Kerberos AUTH_DATA policy element is shown below. An example of the Kerberos AUTH_DATA policy element is shown below in
Figure 1.
0 1 2 3 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 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 = SESSION_AUTH |0|0|0|0| Object Length | |1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | KERB_P. | | Length | AUTH_ENT_ID | KERB_P. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (The principal@realm name) | | OctetString ... (The principal@realm name) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero | | Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (KRB_CRED Data) | | OctetString ... (KRB_CRED Data) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1
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. Two examples of the public
SESSION_AUTH policy element is shown below. key SESSION_AUTH policy element are shown in Figure 2 and Figure 3.
0 1 2 3 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 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 = SESSION_AUTH |0|0|0|0| Object Length | |1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | PGP_CERT | | Length | AUTH_ENT_ID | PGP_CERT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authorizing entity Digital Certificate) | | OctetString ... (Authorizing entity Digital Certificate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero | | Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) | | OctetString ... (Authentication data) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Example of a SESSION_AUTH_OBJECT using a PGP Certificate
Figure 2
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 = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | X509_V3_CERT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authorizing entity Digital Certificate) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OctetString ... (Authentication data) |
+---------------------------------------------------------------+
Example of a SESSION_AUTH_OBJECT using an X509_V3_CERT Certificate
Figure 3
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.
o Public keys are stored in digital certificates and a trusted o Public keys are stored in digital certificates and a trusted
skipping to change at page 21, line 20 skipping to change at page 21, line 47
certificate. certificate.
Authorizing entity uses its private key to generate Authorizing entity uses its private key to generate
AUTHENTICATION_DATA. Authenticators (router, PDP) use the AUTHENTICATION_DATA. Authenticators (router, PDP) use the
authorizing entity's public key (stored in the digital certificate) authorizing entity's public key (stored in the digital certificate)
to verify and authenticate the policy element. to verify and authenticate the policy element.
4.3.1.1. X.509 V3 digital certificates 4.3.1.1. X.509 V3 digital certificates
When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA
MUST be generated following these steps: MUST be generated by the authorizing entity following these steps:
o A Signed-data is constructed as defined in RFC5652 [RFC5652] . A o A Signed-data is constructed as defined in RFC5652 [RFC5652]. A
digest is computed on the content (as specified in Section 6.1) digest is computed on the content (as specified in Section 6.1)
with a signer-specific message-digest algorithm. The certificates with a signer-specific message-digest algorithm. The certificates
field contains the chain of authorizing entity's X.509 V3 digital field contains the chain of authorizing entity's X.509 V3 digital
certificates. The certificate revocation list is defined in the certificates. The certificate revocation list is defined in the
crls field. The digest output is digitally signed following crls field. The digest output is digitally signed following
Section 8 of RFC 3447 [RFC3447], using the signer's private key. Section 8 of RFC 3447 [RFC3447], using the signer's private key.
When the AUTH_ENT_ID is of type X509_V3_CERT, verification MUST be When the AUTH_ENT_ID is of type X509_V3_CERT, verification at the
done following these steps: verifying network element (PDP or router) MUST be done following
these steps:
o Parse the X.509 V3 certificate to extract the distinguished name o Parse the X.509 V3 certificate to extract the distinguished name
of the issuer of the certificate. of the issuer of the certificate.
o Certification Path Validation is performed as defined in Section 6 o Certification Path Validation is performed as defined in Section 6
of RFC 5280 [RFC5280]. of RFC 5280 [RFC5280].
o Parse through the Certificate Revocation list to verify that the o Parse through the Certificate Revocation list to verify that the
received certificate is not listed. received certificate is not listed.
skipping to change at page 22, line 8 skipping to change at page 22, line 36
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.3.1.2. PGP digital certificates 4.3.1.2. PGP digital certificates
When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be
generated following these steps: generated by the authorizing entity following these steps:
o AUTHENTICATION_DATA contains a Signature Packet as defined in AUTHENTICATION_DATA contains a Signature Packet as defined in Section
Section 5.2.3 of RFC 4880 [RFC4880]. In summary: 5.2.3 of RFC 4880 [RFC4880]. In summary:
o Compute the hash of all data in the SESSION_AUTH policy element up o Compute the hash of all data in the SESSION_AUTH policy element up
to the AUTHENTICATION_DATA. to the AUTHENTICATION_DATA.
o The hash output is digitally signed following Section 8 of RFC o The hash output is digitally signed following Section 8 of RFC
3447, using the signer's private key. 3447, using the signer's private key.
When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done
following these steps: by the verifying network element (PDP or router) following these
steps:
o Validate the certificate. o Validate the certificate.
o Once the PGP certificate is validated, the public key of the o Once the PGP certificate is validated, the public key of the
authorizing entity can be extracted from the certificate. authorizing entity can be extracted from the certificate.
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
skipping to change at page 23, line 11 skipping to change at page 23, line 42
o NSLP_OBJECT_LIST this attribute lists all NSLP objects that are o NSLP_OBJECT_LIST this attribute lists all NSLP objects that are
included into HMAC calculation. included into HMAC calculation.
o AUTHENTICATION_DATA this attribute contains the Key-ID that is o AUTHENTICATION_DATA this attribute contains the Key-ID that is
used for HMAC calculation as well as the HMAC data itself used for HMAC calculation as well as the HMAC data itself
[RFC2104]. [RFC2104].
The key used for HMAC calculation must be exchanged securely by some The key used for HMAC calculation must be exchanged securely by some
other means, e.g., a Kerberos Ticket or pre-shared manual other means, e.g., a Kerberos Ticket or pre-shared manual
installation etc. The Key-ID in the AUTHENTICATION_DATA allows to installation etc. The Key-ID in the AUTHENTICATION_DATA allows the
refer to the appropriate key and also to periodically change signing reference to the appropriate key and also to periodically change
keys within a session. The key length MUST be 64-bit at least, but signing keys within a session. The key length MUST be 64-bit at
it is ideally longer in order to defend against brute force attacks least, but it is ideally longer in order to defend against brute
during the key validity period. For scalability reasons it is force attacks during the key validity period. For scalability
recommended to use a per-user key for signing NSLP messages, but reasons it is suggested to use a per-user key for signing NSLP
using a per-session key is possible, too, at the cost of a per- messages, but using a per-session key is possible, too, at the cost
session key exchange. A per-user key allows for verification of the of a per-session key exchange. A per-user key allows for
authenticity of the message and thus provides a basis for a session- verification of the authenticity of the message and thus provides a
based per-user authorization. It is recommended to periodically basis for a session-based per-user authorization. It is RECOMMENDED
change the shared key in order to prevent eavesdroppers from to periodically change the shared key in order to prevent
performing a brute force off-line attacks on the shared key. The eavesdroppers from performing a brute force off-line attacks on the
actual hash algorithm used in the HMAC computation is specified by shared key. The actual hash algorithm used in the HMAC computation
the "Transform ID" field (given as Transform Type 3 of the IKEv2 is specified by the "Transform ID" field (given as Transform Type 3
registry [RFC4306]). The hash algorithm must be chosen consistently of the IKEv2 registry [RFC4306]). The hash algorithm MUST be chosen
between the object creator and the NN verifying the HMAC; this can be consistently between the object creator and the NN verifying the
accomplished by out-of-band mechanisms when the shared key is HMAC; this can be accomplished by out-of-band mechanisms when the
exchanged. shared key is exchanged.
Figure 1 shows an example of an object that is used for integrity Figure 4 shows an example of an object that is used for integrity
protection of NSLP messages. protection of NSLP messages.
0 1 2 3 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 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 = SESSION_AUTH |0|0|0|0| Object Length | |1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | AUTH_ENT_ID | HMAC_SIGNED | | Length | AUTH_ENT_ID | HMAC_SIGNED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | Transform ID | | reserved | Transform ID |
skipping to change at page 24, line 42 skipping to change at page 25, line 42
| Length | AUTH_DATA | zero | | Length | AUTH_DATA | zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEY_ID | | KEY_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code HMAC Data | | Message Authentication Code HMAC Data |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Example of a SESSION_AUTH_OBJECT that provides integrity protection Example of a SESSION_AUTH_OBJECT that provides integrity protection
for NSLP messages for NSLP messages
Figure 1 Figure 4
5. Framework 5. Framework
RFC3521 [RFC3521] describes a framework in which the SESSION_AUTH RFC3521 [RFC3521] describes a framework in which the SESSION_AUTH
policy element may be utilized to transport information required for policy element may be utilized to transport information required for
authorizing resource reservation for data flows (e.g., media flows). authorizing resource reservation for data flows (e.g., media flows).
RFC3521 introduces 4 different models: RFC3521 introduces 4 different models:
1. The coupled model 1. The coupled model
skipping to change at page 28, line 35 skipping to change at page 29, line 35
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 construct and send a RESPONSE message with the status of must construct and send a RESPONSE message with the status of
authorization failure as specified in [I-D.ietf-nsis-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 or PDP)
1. Retrieve the policy element from the SESSION_AUTH object. Check 1. Retrieve the policy element from the SESSION_AUTH object. Check
the AUTH_ENT_ID type and SubType fields and return an error if the AUTH_ENT_ID type and SubType fields and return an error if
the identity type is not supported. the identity type is not supported.
2. Verify the message integrity. 2. Verify the message integrity.
* Shared symmetric key authentication: The QNE/PDP uses the * Shared symmetric key authentication: The QNE or PDP uses the
AUTH_ENT_ID field to consult a table keyed by that field. The AUTH_ENT_ID field to consult a table keyed by that field. The
table should identify the cryptographic authentication table should identify the cryptographic authentication
algorithm to be used along with the expected length of the algorithm to be used along with the expected length of the
authentication data and the shared symmetric key for the authentication data and the shared symmetric key for the
authorizing entity. Verify that the indicated length of the authorizing entity. Verify that the indicated length of the
authentication data is consistent with the configured table authentication data is consistent with the configured table
entry and validate the authentication data. 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 yet provided by this document. * HMAC signed: The QNE or PDP uses the Key-ID field of the
AUTHENTICATION_DATA attribute 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 integrity of parts of the NSLP
message, i.e., session ID, MRI, NSLP ID and all other NSLP
elements listed in the NSLP_OBJECT_LIST authentication data as
well as the SESSION_AUTH object contents (cf. Section 6.4).
* Kerberos: If AUTH_DATA contains an encapsulated KRB_CRED
message (cf. Section 4.2), the integrity of the KRB_CRED
message can be verified within Kerberos itself. Moreover, an
additionally present SESSION_AUTH object using HMAC_SIGNED can
be used to verify the message integrity as described above.
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 PDP MUST then consult its authorization policy in order to
determine whether or not the specific request is authorized determine whether or not the specific request is authorized
(e.g., based on available credits, information in the (e.g., based on available credits, information in the
subscriber's database). To the extent to which these access subscriber's database). To the extent to which these access
control decisions require supplementary information, routers/PDPs control decisions require supplementary information, routers/PDPs
MUST ensure that supplementary information is obtained securely. MUST ensure that supplementary information is obtained securely.
skipping to change at page 30, line 48 skipping to change at page 32, line 10
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. * HMAC signed: The QNE or PDP uses the Key-ID field of the
AUTHENTICATION_DATA attribute 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 integrity of parts of the NSLP
message, i.e., session ID, MRI, NSLP ID and all other NSLP
elements listed in the NSLP_OBJECT_LIST authentication data as
well as the SESSION_AUTH object contents (cf. Section 6.4).
* Kerberos: If AUTH_DATA contains an encapsulated KRB_CRED
message (cf. Section 4.2), the integrity of the KRB_CRED
message can be verified within Kerberos itself. Moreover, an
additionally present SESSION_AUTH object using HMAC_SIGNED can
be used to verify the message integrity as described above.
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
SESSION_AUTH element then the appropriate actions described the SESSION_AUTH 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 6.4. Integrity Protection of NSLP messages
The SESSION_AUTH object can also be used to provide an integrity The SESSION_AUTH object can also be used to provide an integrity
protection for every NSLP signaling message, thereby also authorizing protection for every NSLP signaling message, thereby also
requests or responses. Assume that a user has deposited a shared key authenticating requests or responses. Assume that a user has
at some NN. This NN can then verify the integrity of every NSLP deposited a shared key at some NN. This NN can then verify the
message sent by the user to the NN, thereby authorizing actions like integrity of every NSLP message sent by the user to the NN. Based on
resource reservations or opening firewall pinholes according to this authentication the NN can apply authorization policies to
policy decisions earlier made. actions like resource reservations or opening of firewall pinholes.
The sender of an NSLP message creates a SESSION_AUTH object that The sender of an NSLP message creates a SESSION_AUTH object that
contains AUTH_ENT_ID attribute set to HMAC_SIGNED (cf. Section 4.4) 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 and hashes with the shared key over all NSLP objects that need to be
protected and lists them in the NSLP_OBJECT_LIST. The SESSION_AUTH protected and lists them in the NSLP_OBJECT_LIST. The SESSION_AUTH
object itself is also protected by the HMAC. By inclusion of the object itself is also protected by the HMAC. By inclusion of the
SESSION_AUTH object into the NSLP message, the receiver of this NSLP SESSION_AUTH object into the NSLP message, the receiver of this NSLP
message can verify its integrity if it has the suitable shared key 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 for the HMAC. Any response to the sender should also be protected by
inclusion of a SESSION_AUTH object in order to prevent attackers inclusion of a SESSION_AUTH object in order to prevent attackers
skipping to change at page 32, line 28 skipping to change at page 34, line 28
different network entities may not be in sync. The start time is different network entities may not be in sync. The start time is
used to verify that the request is not being replayed at a later 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 time. In all other models, the SESSION_ID is used by the Policy
Server to ensure that the resource request successfully correlates Server to ensure that the resource request successfully correlates
with records of an authorized session. If a SESSION_AUTH object is with records of an authorized session. If a SESSION_AUTH object is
replayed, it MUST be detected by the policy server (using internal replayed, it MUST be detected by the policy server (using internal
algorithms) and the request MUST be rejected. algorithms) and the request MUST be rejected.
The second issue, the integrity of the policy element, is preserved The second issue, the integrity of the policy element, is preserved
in untrusted environments by including the AUTHENTICATION_DATA in untrusted environments by including the AUTHENTICATION_DATA
attribute. Therefore, this attribute MUST always be included. attribute in such environments.
In environments where shared symmetric keys are possible, they should In environments where shared symmetric keys are possible, they should
be used in order to keep the SESSION_AUTH policy element size to a be used in order to keep the SESSION_AUTH policy element size to a
strict minimum, e.g., when wireless links are used. A secondary strict minimum, e.g., when wireless links are used. A secondary
option would be PKI authentication, which provides a high level of option would be PKI authentication, which provides a high level of
security and good scalability. However, it requires the presence of security and good scalability. However, it requires the presence of
credentials in the SESSION_AUTH policy element which impacts its credentials in the SESSION_AUTH policy element which impacts its
size. size.
The SESSION_AUTH object can also serve to protect the integrity of The SESSION_AUTH object can also serve to protect the integrity of
NSLP message parts by using the HMAC_SIGNED Authentication Data as NSLP message parts by using the HMAC_SIGNED Authentication Data as
described in Section 6.4. described in Section 6.4.
When shared keys are used, e.g., in AUTHENTICATION_DATA Section 4.1
or in conjunction with HMAC_SIGNED Section 4.4, it is important that
the keys are kept secret, i.e., they must be exchanged, stored, and
managed in a secure and confidential manner. If the key material is
disclosed authentication and integrity protection are useless.
Furthermore, security considerations for public key mechanisms using
the X.509 certificate mechanisms described in [RFC5280] apply.
Similarly, security considerations for PGP described in [RFC4880]
apply.
Further security issues are outlined in RFC 4081 [RFC4081]. Further security issues are outlined in RFC 4081 [RFC4081].
8. IANA Considerations 8. IANA Considerations
The SESSION_AUTH_OBJECT NSLP Message Object type is specified as: The SESSION_AUTH_OBJECT NSLP Message Object type is specified as:
(IANA-TBD) (IANA-TBD)
[TO BE REMOVED: This specification makes the following request to [TO BE REMOVED: This specification makes the following request to
IANA: Assign a new object value (SESSION_AUTH_OBJECT) for the IANA: Assign a new object value (SESSION_AUTH_OBJECT) for the
SESSION_AUTH object from the shared NSLP Message Objects sub- SESSION_AUTH object from the shared NSLP Message Objects sub-
skipping to change at page 36, line 8 skipping to change at page 39, line 8
SubType Description SubType Description
-------- ------------- -------- -------------
0 Reserved 0 Reserved
1 NTP_TIMESTAMP 1 NTP_TIMESTAMP
2-127 Unassigned 2-127 Unassigned
128-255 Reserved 128-255 Reserved
9. Acknowledgments 9. Acknowledgments
We would like to thank Xioaming Fu and Lars Eggert for provided We would like to thank Xioaming Fu and Lars Eggert for provided
reviews and comments. This document is largely based on the RFC 3520 reviews and comments. Helpful comments were also provided by Gen-ART
reviewer Ben Campbell as well as Sean Turner and Tim Polk from the
Security Area. This document is largely based on the RFC 3520
[RFC3520] and credit therefore goes to the authors of RFC 3520, [RFC3520] and credit therefore goes to the authors of RFC 3520,
namely Louis-Nicolas Hamer, Brett Kosinski, Bill Gage and Hugh Shieh. namely Louis-Nicolas Hamer, Brett Kosinski, Bill Gage and Hugh Shieh.
Part of this work was funded by Deutsche Telekom Laboratories within Part of this work was funded by Deutsche Telekom Laboratories within
the context of the ScaleNet project. 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]
skipping to change at page 37, line 44 skipping to change at page 40, line 44
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
10.2. Informative References 10.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
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.
[RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh,
"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,
skipping to change at page 38, line 29 skipping to change at page 41, line 26
Next Steps in Signaling (NSIS)", RFC 4081, June 2005. Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", (LDAP): String Representation of Distinguished Names",
RFC 4514, June 2006. RFC 4514, June 2006.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009. RFC 5652, September 2009.
Appendix A. Changes Appendix A. Changes
[Note to the RFC Editor: this appendix to be removed before [Note to the RFC Editor: this appendix to be removed before
publication as an RFC.] publication as an RFC.]
This section describes changes between draft versions. This section describes changes between draft versions.
-00: based on draft-manner-nsis-nslp-auth-04 -00: based on draft-manner-nsis-nslp-auth-04
skipping to change at page 41, line 5 skipping to change at page 43, line 48
* added description for SESSION_ID (new sec. 3.2.2) * added description for SESSION_ID (new sec. 3.2.2)
* removed a superfluous sentence in NSLP_OBJECT_LIST definition * removed a superfluous sentence in NSLP_OBJECT_LIST definition
(former sec. 3.2.6) (former sec. 3.2.6)
* fixed a typo in figure 1 (was NTLP_OBJ_LIST) * fixed a typo in figure 1 (was NTLP_OBJ_LIST)
* added clarification sentences for HMAC_SIGNED in sections 6.4 * added clarification sentences for HMAC_SIGNED in sections 6.4
and 7 and 7
-07:
* Addressed comments of Gen-ART review by Ben Campell:
+ clarified order requirements on NSLP object list and
computing the hash
+ changed required minimum Hash implementation from HMAC-MD5
to HMAC-SHA2-256
+ clarified Section 6.4, 1st paragraph authentication vs.
authorization
+ removed MUST in Section 7, 3rd paragraph
(AUTHENTICATION_DATA is not always required)
* Addressed comments of Sean Turners review:
+ added Hash Signed and Kerberos usage to Sections 6.2.3, 2.
and 6.3.3, 2.
+ added security considerations for symmetric and public keys
+ capitalized some occurrences of MUST and RECOMMENDED
+ added figure for SESSION_AUTH object with X509_V3_CERT
+ added figure numbers for SESSION_AUTH object examples in
section 4
* many editorial nits
Authors' Addresses Authors' Addresses
Jukka Manner Jukka Manner
Aalto University Aalto University
P.O. Box 13000 P.O. Box 13000
Aalto FI-00076 Aalto FI-00076
Finland Finland
Phone: +358 9 470 22481 Phone: +358 9 470 22481
Email: jukka.manner@tkk.fi Email: jukka.manner@tkk.fi
 End of changes. 38 change blocks. 
106 lines changed or deleted 215 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/