idnits 2.17.1 draft-manner-nsis-nslp-auth-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1397. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2008) is 5778 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-18 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. 'I-D.ietf-nsis-nslp-natfw') == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-15 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. 'I-D.ietf-nsis-ntlp') == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-16 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. 'I-D.ietf-nsis-qos-nslp') ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manner 3 Internet-Draft TKK 4 Intended status: Standards Track M. Stiemerling 5 Expires: January 3, 2009 NEC 6 H. Tschofenig 7 Nokia Siemens Networks 8 R. Bless 9 Univ. of Karlsruhe 10 July 2, 2008 12 Authorization for NSIS Signaling Layer Protocols 13 draft-manner-nsis-nslp-auth-04.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 3, 2009. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 Signaling layer protocols in the NSIS working group may rely on GIST 47 to handle authorization. Still, the signaling layer protocol itself 48 may require separate authorization to be performed when a node 49 receives a request for a certain kind of service or resources. This 50 draft presents a generic model and object formats for session 51 authorization within the NSIS Signaling Layer Protocols. The goal of 52 session authorization is to allow the exchange of information between 53 network elements in order to authorize the use of resources for a 54 service and to coordinate actions between the signaling and transport 55 planes. 57 Table of Contents 59 1. Conventions used in this document . . . . . . . . . . . . . . 5 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Session Authorization Object . . . . . . . . . . . . . . . . . 7 62 3.1. Session Authorization Object format . . . . . . . . . . . 7 63 3.2. Session Authorization Attributes . . . . . . . . . . . . . 8 64 3.2.1. Authorizing Entity Identifier . . . . . . . . . . . . 9 65 3.2.2. Source Address . . . . . . . . . . . . . . . . . . . . 11 66 3.2.3. Destination Address . . . . . . . . . . . . . . . . . 12 67 3.2.4. Start time . . . . . . . . . . . . . . . . . . . . . . 13 68 3.2.5. End time . . . . . . . . . . . . . . . . . . . . . . . 14 69 3.2.6. NSLP Object List . . . . . . . . . . . . . . . . . . . 15 70 3.2.7. Authentication data . . . . . . . . . . . . . . . . . 16 71 4. Integrity of the AUTH_SESSION policy element . . . . . . . . . 18 72 4.1. Shared symmetric keys . . . . . . . . . . . . . . . . . . 18 73 4.1.1. Operational Setting using shared symmetric keys . . . 18 74 4.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 4.3. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 19 76 4.3.1. Operational Setting for public key based 77 authentication . . . . . . . . . . . . . . . . . . . . 19 78 4.4. HMAC Signed . . . . . . . . . . . . . . . . . . . . . . . 21 79 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 24 80 5.1. The Coupled Model . . . . . . . . . . . . . . . . . . . . 24 81 5.2. The associated model with one policy server . . . . . . . 24 82 5.3. The associated model with two policy servers . . . . . . . 25 83 5.4. The non-associated model . . . . . . . . . . . . . . . . . 25 84 6. Message Processing Rules . . . . . . . . . . . . . . . . . . . 26 85 6.1. Generation of the AUTH_SESSION by the authorizing 86 entity . . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 6.2. Processing within the QoS NSLP . . . . . . . . . . . . . . 26 88 6.2.1. Message Generation . . . . . . . . . . . . . . . . . . 26 89 6.2.2. Message Reception . . . . . . . . . . . . . . . . . . 27 90 6.2.3. Authorization (QNE/PDP) . . . . . . . . . . . . . . . 27 91 6.2.4. Error Signaling . . . . . . . . . . . . . . . . . . . 28 92 6.3. Processing with the NAT/FW NSLP . . . . . . . . . . . . . 28 93 6.3.1. Message Generation . . . . . . . . . . . . . . . . . . 28 94 6.3.2. Message Reception . . . . . . . . . . . . . . . . . . 28 95 6.3.3. Authorization (Router/PDP) . . . . . . . . . . . . . . 29 96 6.3.4. Error Signaling . . . . . . . . . . . . . . . . . . . 30 97 6.4. Integrity Protection of NSLP messages . . . . . . . . . . 30 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 100 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 34 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 34 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 105 Intellectual Property and Copyright Statements . . . . . . . . . . 37 107 1. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in BCP 14, RFC 2119 112 [RFC2119]. 114 The term "NSLP node" (NN) is used to refer to an NSIS node running an 115 NSLP protocol that can make use of the authorization object discussed 116 in this document. Currently, this node would run either the QoS or 117 the NAT/FW NSLP service. 119 2. Introduction 121 The NSIS working group is specifying a suite of protocols for the 122 next generation in Internet signaling [RFC4080]. The design is based 123 on a generalized transport protocol for signaling applications, the 124 General Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp], and 125 various kinds of signaling applications. Two signaling applications 126 and their NSIS Signaling Layer Protocol (NSLP) have been designed, a 127 Quality of Service application (QoS NSLP) [I-D.ietf-nsis-qos-nslp] 128 and a NAT/firewall application (NAT/FW) [I-D.ietf-nsis-nslp-natfw]. 130 The security architecture is based on a chain-of-trust model, where 131 each GIST hop may chose the appropriate security protocol, taking 132 into account the signaling application requirements. This model is 133 appropriate for a number of different use cases, and allows the 134 signaling applications to leave the handling of security to GIST. 136 Yet, in order to allow for finer-grain per-session or per-user 137 admission control, it is necessary to provide a mechanism for 138 ensuring that the use of resources by a host has been properly 139 authorized before allowing the signaling application to commit the 140 resource request, e.g., a QoS reservation or mappings for NAT 141 traversal. In order to meet this requirement,there must be 142 information in the NSLP message which may be used to verify the 143 validity of the request. This can be done by providing the host with 144 a session authorization policy element which is inserted into the 145 message and verified by the network. 147 This document describes a generic NSLP layer session authorization 148 policy object (AUTH_SESSION) used to convey authorization information 149 for the request. The scheme is based on third-party tokens. A 150 trusted third party provides authentication tokens to clients and 151 allows verification of the information by the network elements. The 152 requesting host inserts its authorization information acquired from 153 the trusted third party into the NSLP message to allow verification 154 of the network resource request. Network elements verify the request 155 and then process the resource reservation message based on admission 156 policy. This work is based on RFC 3520 [RFC3520] and RFC 3521 157 [RFC3521]. 159 The default operation of the authorization is to add one 160 authorization policy object. Yet, in order to support end-to-end 161 signaling and request authorization from different networks, a host 162 initiating an NSLP signaling session may add more than one 163 AUTH_SESSION object in the message. The identifier of the 164 authorizing entity can be used by the network elements to use the 165 third party they trust to verify the request. 167 3. Session Authorization Object 169 This section presents a new NSLP layer object called session 170 authorization (AUTH_SESSION). The AUTH_SESSION object can be used in 171 the currently specified and future NSLP protocols. 173 The authorization attributes follow the format and specification 174 given in RFC3520 [RFC3520]. 176 3.1. Session Authorization Object format 178 The AUTH_SESSION object contains a list of fields which describe the 179 session, along with other attributes. The object header follows the 180 generic NSLP object header. 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 |A|B|r|r| Type |r|r|r|r| Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 + + 188 // Session Authorization Attribute List // 189 + + 190 +---------------------------------------------------------------+ 192 The value for the Type field comes from shared NSLP object type 193 space. The Length field is given in units of 32 bit words and 194 measures the length of the Value component of the TLV object (i.e. it 195 does not include the standard header). 197 The bits marked 'A' and 'B' are extensibility flags, and used to 198 signal the desired treatment for objects whose treatment has not been 199 defined in the protocol specification (i.e. whose Type field is 200 unknown at the receiver). The following four categories of object 201 have been identified, and are described here. 203 AB=00 ("Mandatory"): If the object is not understood, the entire 204 message containing it MUST be rejected with a "Object Type Error" 205 message with subcode 1 ("Unrecognised Object"). In the NATFW NSLP 206 case it MUST be rejected with an error response of class 'Protocol 207 error' (0x3) with error code 'Unknown object present' (0x06). 209 AB=01 ("Ignore"): If the object is not understood, it MUST be deleted 210 and the rest of the message processed as usual. 212 AB=10 ("Forward"): If the object is not understood, it MUST be 213 retained unchanged in any message forwarded as a result of message 214 processing, but not stored locally. 216 AB=11 ("Refresh"): If the object is not understood, it should be 217 incorporated into the locally stored signaling application state for 218 this flow/session, forwarded in any resulting message, and also used 219 in any refresh or repair message which is generated locally. In the 220 NATFW NSLP this combination AB=11 MUST NOT be used and an error 221 response of class 'Protocol error' (0x3) with error code 'Invalid 222 Flag-Field combination' (0x09) MUST be generated. 224 The remaining bits marked 'r' are reserved. The extensibility flags 225 follow the definition in the GIST specification. The AUTH_SESSION 226 object defines in this specification MUST have the AB-bits set to 227 "10". An NN may use the authorization information if it is 228 configured to do so, but may also just skip the object. 230 Type: 0x0a (TBD by IANA) 232 Length: Variable 234 Session Authorization Attribute List: variable length 236 The session authorization attribute list is a collection of 237 objects which describes the session and provides other information 238 necessary to verify the resource reservation request. An initial 239 set of valid objects is described in Section 3.2. 241 3.2. Session Authorization Attributes 243 A session authorization attribute may contain a variety of 244 information and has both an attribute type and subtype. The 245 attribute itself MUST be a multiple of 4 octets in length, and any 246 attributes that are not a multiple of 4 octets long MUST be padded to 247 a 4-octet boundary. All padding bytes MUST have a value of zero. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Length | X-Type | SubType | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 // Value ... // 255 +---------------------------------------------------------------+ 257 Length: 16 bits 258 The length field is two octets and indicates the actual length of 259 the attribute (including Length, X-Type and SubType fields) in 260 number of octets. The length does NOT include any bytes padding 261 to the value field to make the attribute a multiple of 4 octets 262 long. 264 X-Type: 8 bits 266 Session authorization attribute type (X-Type) field is one octet. 267 IANA acts as a registry for X-Types as described in Section 7, 268 IANA Considerations. Initially, the registry contains the 269 following X-Types: 271 1. AUTH_ENT_ID The unique identifier of the entity that authorized 272 the session. 274 2. SOURCE_ADDR Address specification for the signaling session 275 initiator, i.e., the source address of the signaling message 276 originator. 278 3. DEST_ADDR Address specification for the signaling session end- 279 point. 281 4. START_TIME The starting time for the session. 283 5. END_TIME The end time for the session. 285 6. AUTHENTICATION_DATA Authentication data of the session 286 authorization policy element. 288 SubType: 8 bits 290 Session authorization attribute sub-type is one octet in length. 291 The value of the SubType depends on the X-Type. 293 Value: variable length 295 The attribute specific information. 297 3.2.1. Authorizing Entity Identifier 299 AUTH_ENT_ID is used to identify the entity which authorized the 300 initial service request and generated the session authorization 301 policy element. The AUTH_ENT_ID may be represented in various 302 formats, and the SubType is used to define the format for the ID. 303 The format for AUTH_ENT_ID is as follows: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Length | X-Type | SubType | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 // OctetString ... // 311 +---------------------------------------------------------------+ 313 Length: Length of the attribute, which MUST be > 4. 315 X-Type: AUTH_ENT_ID 317 SubType: 319 The following sub-types for AUTH_ENT_ID are defined. IANA acts as 320 a registry for AUTH_ENT_ID sub-types as described in Section 7, 321 IANA Considerations. Initially, the registry contains the 322 following sub-types of AUTH_ENT_ID: 324 1. IPV4_ADDRESS IPv4 address represented in 32 bits 326 2. IPV6_ADDRESS IPv6 address represented in 128 bits 328 3. FQDN Fully Qualified Domain Name as defined in RFC 1034 as an 329 ASCII string. 331 4. ASCII_DN X.500 Distinguished name as defined in RFC 2253 as an 332 ASCII string. 334 5. UNICODE_DN X.500 Distinguished name as defined in RFC 2253 as a 335 UTF-8 string. 337 6. URI Universal Resource Identifier, as defined in RFC 2396. 339 7. KRB_PRINCIPAL Fully Qualified Kerberos Principal name 340 represented by the ASCII string of a principal followed by the @ 341 realm name as defined in RFC 1510 (e.g., johndoe@nowhere). 343 8. X509_V3_CERT The Distinguished Name of the subject of the 344 certificate as defined in RFC 2253 as a UTF-8 string. 346 9. PGP_CERT The PGP digital certificate of the authorizing entity 347 as defined in RFC 2440. 349 10. HMAC_SIGNED Indicates that the AUTHENTICATION_DATA attribute 350 contains a self-signed HMAC signature [RFC2104] that ensures the 351 integrity of the NSLP message. The HMAC is calculated over all 352 NSLP objects given in the NSLP_OBJECT_LIST attribute that MUST 353 also be present. The AUTH_ENT_ID contains the Hash Algorithm 354 that is used for calculation of the HMAC as Transform ID from 355 Transform Type 3 of the IKEv2 registry [RFC4306]. 357 OctetString: Contains the authorizing entity identifier. 359 3.2.2. Source Address 361 SOURCE_ADDR is used to identify the source address specification of 362 the authorized session. This X-Type may be useful in some scenarios 363 to make sure the resource request has been authorized for that 364 particular source address and/or port. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Length | X-Type | SubType | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 // OctetString ... // 372 +---------------------------------------------------------------+ 374 Length: Length of the attribute, which MUST be > 4. 376 X-Type: SOURCE_ADDR 378 SubType: 380 The following sub types for SOURCE_ADDR are defined. IANA acts as 381 a registry for SOURCE_ADDR sub-types as described in Section 7, 382 IANA Considerations. Initially, the registry contains the 383 following sub types for SOURCE_ADDR: 385 1. IPV4_ADDRESS IPv4 address represented in 32 bits 387 2. IPV6_ADDRESS IPv6 address represented in 128 bits 389 3. UDP_PORT_LIST list of UDP port specifications, represented as 16 390 bits per list entry. 392 4. TCP_PORT_LIST list of TCP port specifications, represented as 16 393 bits per list entry. 395 5. SPI Security Parameter Index represented in 32 bits 397 OctetString: The OctetString contains the source address information. 399 In scenarios where a source address is required (see Section 5), at 400 least one of the subtypes 1 or 2 MUST be included in every Session 401 Authorization Data Policy Element. Multiple SOURCE_ADDR attributes 402 MAY be included if multiple addresses have been authorized. The 403 source address of the request (e.g., a QoS NSLP RESERVE) MUST match 404 one of the SOURCE_ADDR attributes contained in this Session 405 Authorization Data Policy Element. 407 At most, one instance of subtype 3 MAY be included in every Session 408 Authorization Data Policy Element. At most, one instance of subtype 409 4 MAY be included in every Session Authorization Data Policy Element. 410 Inclusion of a subtype 3 attribute does not prevent inclusion of a 411 subtype 4 attribute (i.e., both UDP and TCP ports may be authorized). 413 If no PORT attributes are specified, then all ports are considered 414 valid; otherwise, only the specified ports are authorized for use. 415 Every source address and port list must be included in a separate 416 SOURCE_ADDR attribute. 418 3.2.3. Destination Address 420 DEST_ADDR is used to identify the destination address of the 421 authorized session. This X-Type may be useful in some scenarios to 422 make sure the resource request has been authorized for that 423 particular destination address and/or port. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Length | X-Type | SubType | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 // OctetString ... // 431 +---------------------------------------------------------------+ 433 Length: Length of the attribute in number of octects, which MUST be > 434 4. 436 X-Type: DEST_ADDR 438 SubType: 440 The following sub types for DEST_ADDR are defined. IANA acts as a 441 registry for DEST_ADDR sub-types as described in Section 7, IANA 442 Considerations. Initially, the registry contains the following 443 sub types for DEST_ADDR: 445 1. IPV4_ADDRESS IPv4 address represented in 32 bits 447 2. IPV6_ADDRESS IPv6 address represented in 128 bits 449 3. UDP_PORT_LIST list of UDP port specifications, represented as 16 450 bits per list entry. 452 4. TCP_PORT_LIST list of TCP port specifications, represented as 16 453 bits per list entry. 455 5. SPI Security Parameter Index represented in 32 bits 457 OctetString: The OctetString contains the destination address 458 specification. 460 In scenarios where a destination address is required (see Section 5), 461 at least one of the subtypes 1 or 2 MUST be included in every Session 462 Authorization Data Policy Element. Multiple DEST_ADDR attributes MAY 463 be included if multiple addresses have been authorized. The 464 destination address field of the resource reservation datagram (e.g., 465 QoS NSLP Reserve) MUST match one of the DEST_ADDR attributes 466 contained in this Session Authorization Data Policy Element. 468 At most, one instance of subtype 3 MAY be included in every Session 469 Authorization Data Policy Element. At most, one instance of subtype 470 4 MAY be included in every Session Authorization Data Policy Element. 471 Inclusion of a subtype 3 attribute does not prevent inclusion of a 472 subtype 4 attribute (i.e., both UDP and TCP ports may be authorized). 474 If no PORT attributes are specified, then all ports are considered 475 valid; otherwise, only the specified ports are authorized for use. 477 Every destination address and port list must be included in a 478 separate DEST_ADDR attribute. 480 3.2.4. Start time 482 START_TIME is used to identify the start time of the authorized 483 session and can be used to prevent replay attacks. If the 484 AUTH_SESSION policy element is presented in a resource request, the 485 network SHOULD reject the request if it is not received within a few 486 seconds of the start time specified. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Length | X-Type | SubType | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 // OctetString ... // 494 +---------------------------------------------------------------+ 496 Length: Length of the attribute, which MUST be > 4. 498 X-Type: START_TIME 500 SubType: 502 The following sub types for START_TIME are defined. IANA acts as a 503 registry for START_TIME sub-types as described in Section 7, IANA 504 Considerations. Initially, the registry contains the following sub 505 types for START_TIME: 507 1. 1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305. 509 OctetString: The OctetString contains the start time. 511 3.2.5. End time 513 END_TIME is used to identify the end time of the authorized session 514 and can be used to limit the amount of time that resources are 515 authorized for use (e.g., in prepaid session scenarios). 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Length | X-Type | SubType | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 // OctetString ... // 523 +---------------------------------------------------------------+ 525 Length: Length of the attribute, which MUST be > 4. 527 X-Type: END_TIME 529 SubType: 531 The following sub types for END_TIME are defined. IANA acts as a 532 registry for END_TIME sub-types as described in Section 7, IANA 533 Considerations. Initially, the registry contains the following sub 534 types for END_TIME: 536 1. NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305. 538 OctetString: The OctetString contains the end time. 540 3.2.6. NSLP Object List 542 The NSLP_OBJECT_LIST attribute contains a list of NSLP objects types 543 that are used in the keyed-hash computation whose result is given in 544 the AUTHENTICATION_DATA attribute. This allows for an integrity 545 protection of NSLP PDUs. If an NSLP_OBJECT_LIST attribute has been 546 included in the AUTH_SESSION policy element, an AUTHENTICATION_DATA 547 attribute MUST also be present. 549 The creator of the this attribute lists every NSLP object type whose 550 NSLP PDU object was included in the computation of the hash. The 551 receiver can verify the integrity of the NSLP PDU by computing a hash 552 over all NSLP objects that are listed in this attribute including all 553 the attributes of the authorization object. Since all NSLP object 554 types are unique over all different NSLPs, this will work for any 555 NSLP. 557 Basic NTLP/NSLP objects like the session ID, the NSLPID and the MRI 558 MUST be always included in the HMAC. Since they are not carried 559 within the NSLP itself, but only within GIST, they must be delivered 560 via the GIST API and normalized to their network representation from 561 [I-D.ietf-nsis-ntlp] again before calculating the hash. These values 562 are hashed first, before any other NSLP object values that are 563 included in the hash computation. 565 A summary of the NSLP_OBJECT_LIST attribute format is described 566 below. 568 0 1 2 3 569 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 570 +---------------+---------------+---------------+---------------+ 571 | Length | NSLP_OBJ_LIST | zero | 572 +---------------+---------------+-------+-------+---------------+ 573 | No of signed NSLP objects = n | rsv | NSLP object type (1) | 574 +-------+-------+---------------+-------+-------+---------------+ 575 | rsv | NSLP object type (2) | ..... // 576 +-------+-------+---------------+---------------+---------------+ 577 | rsv | NSLP object type (n) | (padding if required) | 578 +--------------+----------------+---------------+---------------+ 580 Length: Length of the attribute, which MUST be > 4. 582 X-Type: NSLP_OBJECT_LIST 584 SubType: No sub types for NSLP_OBJECT_LIST are currently defined. 585 This field MUST be set to 0. 587 OctetString: The OctetString contains the authentication data of the 588 AUTH_SESSION. 590 No of signed NSLP objects: The number n of NSLP object types that 591 follow. n=0 is allowed, i.e., only a padding field is contained then. 593 rsv: reserved bits and must be set to 0 (zero). 595 NSLP object type: the NSLP 12-bit object type identifier of the 596 object that was included in the hash calculation. The NSLP object 597 type values comprise only 12 bit, so four bits per type value are 598 currently not used within the list. Depending on the number of 599 signed objects, a corresponding padding word of 16 bit must be 600 supplied. 602 padding: padding is required if the number of NSLP objects is even. 603 The padding field MUST be 16 bit set to 0. 605 3.2.7. Authentication data 607 The AUTHENTICATION_DATA attribute contains the authentication data of 608 the AUTH_SESSION policy element and signs all the data in the policy 609 element up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA 610 attribute has been included in the AUTH_SESSION policy element, it 611 MUST be the last attribute in the list. The algorithm used to 612 compute the authentication data depends on the AUTH_ENT_ID SubType 613 field. See Section 4 entitled Integrity of the AUTH_SESSION policy 614 element. 616 A summary of AUTHENTICATION_DATA attribute format is described below. 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Length | X-Type | SubType | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 // OctetString ... // 624 +---------------------------------------------------------------+ 626 Length: Length of the attribute, which MUST be > 4. 628 X-Type: AUTHENTICATION_DATA 630 SubType: No sub types for AUTHENTICATION_DATA are currently defined. 631 This field MUST be set to 0. 633 OctetString: The OctetString contains the authentication data of the 634 AUTH_SESSION. 636 4. Integrity of the AUTH_SESSION policy element 638 This section describes how to ensure the integrity of the policy 639 element is preserved. 641 4.1. Shared symmetric keys 643 In shared symmetric key environments, the AUTH_ENT_ID MUST be of 644 subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or 645 URI. An example AUTH_SESSION object is shown below. 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 |1|0|0|0| Type = AUTH_SESSION |0|0|0|0| Object Length | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Length | AUTH_ENT_ID | IPV4_ADDRESS | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | OctetString ... (The authorizing entity's Identifier) | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Length | AUTH_DATA | zero | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | KEY_ID | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | OctetString ... (Authentication data) | 661 +---------------------------------------------------------------+ 663 4.1.1. Operational Setting using shared symmetric keys 665 This assumes both the Authorizing Entity and the Network router/PDP 666 are provisioned with shared symmetric keys and with policies 667 detailing which algorithm to be used for computing the authentication 668 data along with the expected length of the authentication data for 669 that particular algorithm. 671 Key maintenance is outside the scope of this document, but 672 AUTH_SESSION implementations MUST at least provide the ability to 673 manually configure keys and their parameters. The key used to 674 produce the authentication data is identified by the AUTH_ENT_ID 675 field. Since multiple keys may be configured for a particular 676 AUTH_ENT_ID value, the first 32 bits of the AUTH_DATA field MUST be a 677 key ID to be used to identify the appropriate key. Each key must 678 also be configured with lifetime parameters for the time period 679 within which it is valid as well as an associated cryptographic 680 algorithm parameter specifying the algorithm to be used with the key. 681 At a minimum, all AUTH_SESSION implementations MUST support the HMAC- 682 MD5-128 [RFC1321] [RFC2104] cryptographic algorithm for computing the 683 authentication data. 685 It is good practice to regularly change keys. Keys MUST be 686 configurable such that their lifetimes overlap allowing smooth 687 transitions between keys. At the midpoint of the lifetime overlap 688 between two keys, senders should transition from using the current 689 key to the next/longer-lived key. Meanwhile, receivers simply accept 690 any identified key received within its configured lifetime and reject 691 those that are not. 693 4.2. Kerberos 695 RFC 3520 provides a mechanism to secure the authorization token using 696 Kerberos. Kerberos, however, has not seen deployment in this context 697 and is not well applicable for this particular usage scenario. 698 Hence, Kerberos support will not be provided by this specification. 700 4.3. Public Key 702 In a public key environment, the AUTH_ENT_ID MUST be of the subtypes: 703 X509_V3_CERT or PGP_CERT. The authentication data is used for 704 authenticating the authorizing entity. An example of the public key 705 AUTH_SESSION policy element is shown below. 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 |1|0|0|0| Type = AUTH_SESSION |0|0|0|0| Object Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Length | AUTH_ENT_ID | PGP_CERT | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | OctetString ... (Authorizing entity Digital Certificate) | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Length | AUTH_DATA | zero | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | OctetString ... (Authentication data) | 719 +---------------------------------------------------------------+ 721 4.3.1. Operational Setting for public key based authentication 723 Public key based authentication assumes the following: 725 o Authorizing entities have a pair of keys (private key and public 726 key). 728 o Private key is secured with the authorizing entity. 730 o Public keys are stored in digital certificates and a trusted 731 party, certificate authority (CA) issues these digital 732 certificates. 734 o The verifier (PDP or router) has the ability to verify the digital 735 certificate. 737 Authorizing entity uses its private key to generate 738 AUTHENTICATION_DATA. Authenticators (router, PDP) use the 739 authorizing entity's public key (stored in the digital certificate) 740 to verify and authenticate the policy element. 742 4.3.1.1. X.509 V3 digital certificates 744 When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA 745 MUST be generated following these steps: 747 o A Signed-data is constructed as defined in RFC3852 [RFC3852] . A 748 digest is computed on the content (as specified in Section 6.1) 749 with a signer-specific message-digest algorithm. The certificates 750 field contains the chain of authorizing entity's X.509 V3 digital 751 certificates. The certificate revocation list is defined in the 752 crls field. The digest output is digitally signed following 753 Section 8 of RFC 3447 [RFC3447], using the signer's private key. 755 When the AUTH_ENT_ID is of type X509_V3_CERT, verification MUST be 756 done following these steps: 758 o Parse the X.509 V3 certificate to extract the distinguished name 759 of the issuer of the certificate. 761 o Certification Path Validation is performed as defined in Section 6 762 of RFC 3280. 764 o Parse through the Certificate Revocation list to verify that the 765 received certificate is not listed. 767 o Once the X.509 V3 certificate is validated, the public key of the 768 authorizing entity can be extracted from the certificate. 770 o Extract the digest algorithm and the length of the digested data 771 by parsing the CMS signed-data. 773 o The recipient independently computes the message digest. This 774 message digest and the signer's public key are used to verify the 775 signature value. 777 This verification ensures integrity, non-repudiation and data origin. 779 4.3.1.2. PGP digital certificates 781 When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be 782 generated following these steps: 784 o AUTHENTICATION_DATA contains a Signature Packet as defined in 785 Section 5.2.3 of RFC 2440. In summary: 787 o Compute the hash of all data in the AUTH_SESSION policy element up 788 to the AUTHENTICATION_DATA. 790 o The hash output is digitally signed following Section 8 of RFC 791 3447, using the signer's private key. 793 When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done 794 following these steps: 796 o Validate the certificate. 798 o Once the PGP certificate is validated, the public key of the 799 authorizing entity can be extracted from the certificate. 801 o Extract the hash algorithm and the length of the hashed data by 802 parsing the PGP signature packet. 804 o The recipient independently computes the message digest. This 805 message digest and the signer's public key are used to verify the 806 signature value. 808 This verification ensures integrity, non-repudiation and data origin. 810 4.4. HMAC Signed 812 An AUTH_SESSION object that carries an AUTH_ENT_ID of HMAC_SIGNED is 813 used as integrity protection for NSLP messages. The AUTH_SESSION 814 object MUST contain the following attributes: 816 o SOURCE_ADDR the source address of the entity that created the HMAC 818 o START_TIME the timestamp when the HMAC signature was calculated. 819 This MUST be different for any two messages in sequence in order 820 to prevent replay attacks. Since the NTP timestamp provides 821 currently a resolution of 200 pico seconds this should be 822 sufficient. 824 o NSLP_OBJECT_LIST this attribute lists all NSLP objects that are 825 included into HMAC calculation. 827 o AUTHENTICATION_DATA this attribute contains the Key-ID that is 828 used for HMAC calculation as well as the HMAC data itself 829 [RFC2104]. 831 The key used for HMAC calculation must be exchanged securely by some 832 other means, e.g., a Kerberos Ticket or pre-shared manual 833 installation etc. The Key-ID in the AUTHENTICATION_DATA allows to 834 refer to the appropriate key and also to change signing keys. The 835 key length MUST be 64-bit at least, but it is ideally longer in order 836 to defend against brute force attacks. It is recommended to use a 837 per-user key for signing NSLP messages. 839 Figure 12 shows an example of an object that is used for integrity 840 protection of NSLP messages. 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 |1|0|0|0| Type = AUTH_SESSION |0|0|0|0| Object Length | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Length | AUTH_ENT_ID | HMAC_SIGNED | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | reserved | Transform ID | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Length | SOURCE_ADDR | IPV4_ADDRESS | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | IPv4 Source Address of NSLP sender | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Length | START_TIME | NTP_TIME_STAMP| 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | NTP Time Stamp (1) | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | NTP Time Stamp (2) | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Length | NTLP_OBJ_LIST | zero | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | No of signed NSLP objects = n | rsv | NSLP object type (1) | 864 +-------+-------+---------------+-------+-------+---------------+ 865 | rsv | NSLP object type (2) | ..... // 866 +-------+-------+---------------+---------------+---------------+ 867 | rsv | NSLP object type (n) | (padding if required) | 868 +--------------+----------------+---------------+---------------+ 869 | Length | AUTH_DATA | zero | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | KEY_ID | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Message Authentication Code HMAC Data | 874 +---------------------------------------------------------------+ 876 Example for an AUTH_SESSION_OBJECT that provides integrity protection 877 for NSLP messages 879 Figure 12 881 5. Framework 883 RFC3521 [RFC3521] describes a framework in which the AUTH_SESSION 884 policy element may be utilized to transport information required for 885 authorizing resource reservation for media flows. RFC3521 introduces 886 4 different models: 888 1. The coupled model 890 2. The associated model with one policy server 892 3. The associated model with two policy servers 894 4. The non-associated model. 896 The fields that are required in an AUTH SESSION policy element 897 dependent on which of the models is used. 899 5.1. The Coupled Model 901 In the coupled model, the only information that MUST be included in 902 the policy element is the SESSION_ID; it is used by the Authorizing 903 Entity to correlate the resource reservation request with the media 904 authorized during session set up. Since the End Host is assumed to 905 be untrusted, the Policy Server SHOULD take measures to ensure that 906 the integrity of the SESSION_ID is preserved in transit; the exact 907 mechanisms to be used and the format of the SESSION_ID are 908 implementation dependent. 910 5.2. The associated model with one policy server 912 In this model, the contents of the AUTH_SESSION policy element MUST 913 include: 915 o A session identifier - SESSION_ID. This is information that the 916 authorizing entity can use to correlate the resource request with 917 the media authorized during session set up. 919 o The identity of the authorizing entity - AUTH_ENT_ID. This 920 information is used by an NN to determine which authorizing entity 921 (Policy Server) should be used to solicit resource policy 922 decisions. 924 In some environments, an NN may have no means for determining if the 925 identity refers to a legitimate Policy Server within its domain. In 926 order to protect against redirection of authorization requests to a 927 bogus authorizing entity, the AUTH_SESSION MUST also include: 929 AUTHENTICATION_DATA. This authentication data is calculated over 930 all other fields of the AUTH_SESSION policy element. 932 5.3. The associated model with two policy servers 934 The content of the AUTH_SESSION Policy Element is identical to the 935 associated model with one policy server. 937 5.4. The non-associated model 939 In this model, the AUTH_SESSION MUST contain sufficient information 940 to allow the Policy Server to make resource policy decisions 941 autonomously from the authorizing entity. The policy element is 942 created using information about the session by the authorizing 943 entity. The information in the AUTH_SESSION policy element MUST 944 include: 946 o Calling party IP address or Identity (e.g., FQDN) - SOURCE_ADDR 947 X-TYPE 949 o Called party IP address or Identity (e.g., FQDN) - DEST_ADDR 950 X-TYPE 952 o The characteristics of (each of) the media stream(s) authorized 953 for this session - RESOURCES X-TYPE 955 o The authorization lifetime - START_TIME X-TYPE 957 o The identity of the authorizing entity to allow for validation of 958 the token in shared symmetric key and Kerberos schemes - 959 AUTH_ENT_ID X-TYPE 961 o The credentials of the authorizing entity in a public-key scheme - 962 AUTH_ENT_ID X-TYPE 964 o Authentication data used to prevent tampering with the 965 AUTH_SESSION policy element - AUTHENTICATION_DATA 967 Furthermore, the AUTH_SESSION policy element MAY contain: 969 o The lifetime of (each of) the media stream(s) - END_TIME X-TYPE 971 o Calling party port number - SOURCE_ADDR X-TYPE 973 o Called party port number - DEST_ADDR X-TYPE 975 All AUTH_SESSION fields MUST match with the resource request. If a 976 field does not match, the request SHOULD be denied. 978 6. Message Processing Rules 980 This section discusses the message processing related to the 981 AUTH_SESSION object. We describe the details of the QoS NSLP and 982 NAT/FW NSLP. New NSLP protocols should use the same logic in making 983 use of the AUTH_SESSION object. 985 6.1. Generation of the AUTH_SESSION by the authorizing entity 987 1. Generate the AUTH_SESSION policy element with the appropriate 988 contents as specified in Section 3. 990 2. If authentication is needed, the entire AUTH_SESSION policy 991 element is constructed, excluding the length, type and subtype 992 fields of the AUTH_SESSION field. Note that the message MUST 993 include a START_TIME to prevent replay attacks. The output of 994 the authentication algorithm, plus appropriate header 995 information, is appended as AUTHENTICATION_DATA attribute to the 996 AUTH_SESSION policy element. 998 6.2. Processing within the QoS NSLP 1000 The AUTH_SESSION object may be used with QoS NSLP QUERY and RESERVE 1001 messages to authorize the query operation for network resources, and 1002 a resource reservation request, respectively. 1004 Moreover, the AUTH_SESSION object may also be used with RESPONSE 1005 messages in order to indicate that the authorizing entity changed the 1006 original request. For example, the session start or end times may 1007 have been modified, or the client may have requested authorization 1008 for all ports, but the authorizing entity only allowed the use of 1009 certain ports. 1011 If the QoS NSIS Initiator (QNI) receives a RESPONSE message with an 1012 AUTH_SESSION object, the QNI MUST inspect the AUTH_SESSION object to 1013 see what authentication attribute was changed by an authorizing 1014 entity. The QNI SHOULD also silently accept AUTH_SESSION objects in 1015 RESPONSE message which do not indicate any change to the original 1016 authorization request. 1018 6.2.1. Message Generation 1020 A QoS NSLP message is created as specified in 1021 [I-D.ietf-nsis-qos-nslp]. 1023 1. The policy element received from the authorizing entity MUST be 1024 copied without modification into the AUTH_SESSION object. 1026 2. The AUTH_SESSION object (containing the policy element) is 1027 inserted in the NSLP message in the appropriate place. 1029 6.2.2. Message Reception 1031 The QoS NSLP message is processed as specified in 1032 [I-D.ietf-nsis-qos-nslp] with following modifications. 1034 1. If the QNE is policy aware then it SHOULD use the Diameter QoS 1035 application or the RADIUS QoS protocol to communicate with the 1036 PDP. To construct the AAA message it is necessary to extract the 1037 AUTH_SESSION object and the QoS related objects from the QoS NSLP 1038 message and to craft the respective RADIUS or Diameter message. 1039 The message processing and object format is described in the 1040 respective RADIUS or Diameter QoS protocol, respectively. If the 1041 QNE is policy unaware then it ignores the policy data objects and 1042 continues processing the NSLP message. 1044 2. If the response from the PDP is negative the request must be 1045 rejected. A negative response in RADIUS is an Access-Reject and 1046 in Diameter is based on the 'DIAMETER_SUCCESS' value in the 1047 Result-Code AVP of the QoS-Authz-Answer (QAA) message. The QNE 1048 must contruct and send a RESPONSE message with the status of 1049 authorization failure as specified in [I-D.ietf-nsis-qos-nslp]. 1051 3. Continue processing the NSIS message. 1053 6.2.3. Authorization (QNE/PDP) 1055 1. Retrieve the policy element from the AUTH_SESSION object. Check 1056 the PE type field and return an error if the identity type is not 1057 supported. 1059 2. Verify the message integrity. 1061 * Shared symmetric key authentication: The QNE/PDP uses the 1062 AUTH_ENT_ID field to consult a table keyed by that field. The 1063 table should identify the cryptographic authentication 1064 algorithm to be used along with the expected length of the 1065 authentication data and the shared symmetric key for the 1066 authorizing entity. Verify that the indicated length of the 1067 authentication data is consistent with the configured table 1068 entry and validate the authentication data. 1070 * Public Key: Validate the certificate chain against the trusted 1071 Certificate Authority (CA) and validate the message signature 1072 using the public key. 1074 * Kerberos based usage is not provided by this document. 1076 3. Once the identity of the authorizing entity and the validity of 1077 the service request has been established, the authorizing router/ 1078 PDP MUST then consult its authorization policy in order to 1079 determine whether or not the specific request is authorized 1080 (e.g., based on available credits, information in the 1081 subscriber's database). To the extent to which these access 1082 control decisions require supplementary information, routers/PDPs 1083 MUST ensure that supplementary information is obtained securely. 1085 4. Verify the requested resources do not exceed the authorized QoS. 1087 6.2.4. Error Signaling 1089 When the PDP (e.g., a RADIUS or Diameter server) fails to verify the 1090 policy element then the appropriate actions described the respective 1091 AAA document need to be taken. 1093 The QNE node MUST return a RESPONSE message with the INFO_SPEC error 1094 code Authorization Failure as defined in the QoS NSLP specification. 1095 The QNE MAY include an INFO_SPEC Object Value Info to indicate which 1096 AUTH_SESSION attribute created the error. 1098 6.3. Processing with the NAT/FW NSLP 1100 This section presents processing rules for the NAT/FW NSLP 1101 [I-D.ietf-nsis-nslp-natfw]. 1103 6.3.1. Message Generation 1105 A NAT/FW NSLP message is created as specified in 1106 [I-D.ietf-nsis-nslp-natfw]. 1108 1. The policy element received from the authorizing entity MUST be 1109 copied without modification into the AUTH_SESSION object. 1111 2. The AUTH_SESSION object (containing the policy element) is 1112 inserted in the NATFW NSLP message in the appropriate place. 1114 6.3.2. Message Reception 1116 The NAT/FW NSLP message is processed as specified in 1117 [I-D.ietf-nsis-nslp-natfw] with following modifications. 1119 1. If the router is policy aware then it SHOULD use the Diameter 1120 application or the RADIUS protocol to communicate with the PDP. 1121 To construct the AAA message it is necessary to extract the 1122 AUTH_SESSION element and the NATFW policy rule related objects 1123 from the NSLP message and to craft the respective RADIUS or 1124 Diameter message. The message processing and object format is 1125 described in the respective RADIUS or Diameter protocols, 1126 respectively. If the router is policy unaware then it ignores 1127 the policy data objects and continues processing the NSLP 1128 message. 1130 2. Reject the message if the response from the PDP is negative. A 1131 negative response in RADIUS is an Access-Reject and in Diameter 1132 is based on the 'DIAMETER_SUCCESS' value in the Result-Code AVP. 1134 3. Continue processing the NSIS message. 1136 6.3.3. Authorization (Router/PDP) 1138 1. Retrieve the AUTH_SESSION object and the policy element. Check 1139 the PE type field and return an error if the identity type is not 1140 supported. 1142 2. Verify the message integrity. 1144 * Shared symmetric key authentication: The Network router/PDP 1145 uses the AUTH_ENT_ID field to consult a table keyed by that 1146 field. The table should identify the cryptographic 1147 authentication algorithm to be used along with the expected 1148 length of the authentication data and the shared symmetric key 1149 for the authorizing entity. Verify that the indicated length 1150 of the authentication data is consistent with the configured 1151 table entry and validate the authentication data. 1153 * Public Key: Validate the certificate chain against the trusted 1154 Certificate Authority (CA) and validate the message signature 1155 using the public key. 1157 * Kerberos based usage is not provided by this document. 1159 3. Once the identity of the authorizing entity and the validity of 1160 the service request has been established, the authorizing router/ 1161 PDP MUST then consult its authorization policy in order to deter 1162 mine whether or not the specific request is authorized. To the 1163 extent to which these access control decisions require 1164 supplementary information, routers/PDPs MUST ensure that 1165 supplementary information is obtained securely. 1167 6.3.4. Error Signaling 1169 When the PDP (e.g., a RADIUS or Diameter server) fails to verify the 1170 AUTH_SESSION element then the appropriate actions described the 1171 respective AAA document need to be taken. The NATFW NSLP node MUST 1172 return an error message of class 'Permanent failure' (0x5) with error 1173 code 'Authorization failed' (0x02). 1175 6.4. Integrity Protection of NSLP messages 1177 The AUTH_SESSION object can also be used to provide an integrity 1178 protection for every NSLP signaling message, thereby also authorizing 1179 requests or responses. Assume that a user has deposited a shared key 1180 at some NN. This NN can then verify the integrity of every NSLP 1181 message sent by the user to the NN, thereby authorizing actions like 1182 resource reservations or opening firewall pinholes according to 1183 policy decisions earlier made. 1185 The sender of an NSLP message creates an AUTH_SESSION object that 1186 contains AUTH_ENT_ID attribute set to HMAC_SIGNED (cf. Section 4.4) 1187 and hashes with the shared key over all NSLP objects that need to be 1188 protected and lists them in the NSLP_OBJECT_LIST. The AUTH_SESSION 1189 object itself is also protected by the HMAC. By inclusion of the 1190 AUTH_SESSION object into the NSLP message, the receiver of this NSLP 1191 message can verify its integrity if it has the suitable shared key 1192 for the HMAC. Any response to the sender should also be protected by 1193 inclusion of an AUTH_SESSION object in order to prevent attackers 1194 sending unauthorized responses on behalf of the real NN. 1196 If an AUTH_SESSION object is present that has an AUTH_ENT_ID 1197 attribute set to HMAC_SIGNED, the integrity of all NSLP elements 1198 listed in the NSLP_OBJECT_LIST has to be checked, including the 1199 AUTH_SESSION object contents itself. The key that is used to 1200 calculate the HMAC is referred to by the Key ID included in the 1201 AUTH_DATA attribute. If the provided timestamp in START_TIME is not 1202 recent enough or the calculated HMAC differs from the one provided in 1203 AUTH_DATA the message must be discarded silently and an error should 1204 be logged locally. 1206 7. Security Considerations 1208 This document describes a mechanism for session authorization to 1209 prevent theft of service. There are three types of security issues 1210 to consider: protection against replay attacks, integrity of the 1211 AUTH_SESSION object, and the choice of the authentication algorithms 1212 and keys. 1214 The first issue, replay attacks, MUST be prevented. In the non- 1215 associated model, the AUTH_SESSION object MUST include a START_TIME 1216 field and the Policy Servers MUST support NTP to ensure proper clock 1217 synchronization. Failure to ensure proper clock synchronization will 1218 allow replay attacks since the clocks of the different network 1219 entities may not be in synch. The start time is used to verify that 1220 the request is not being replayed at a later time. In all other 1221 models, the SESSION_ID is used by the Policy Server to ensure that 1222 the resource request successfully correlates with records of an 1223 authorized session. If a AUTH_SESSION object is replayed, it MUST be 1224 detected by the policy server (using internal algorithms) and the 1225 request MUST be rejected. 1227 The second issue, the integrity of the policy element, is preserved 1228 in untrusted environments by including the AUTHENTICATION_DATA 1229 attribute. Therefore, this attribute MUST always be included. 1231 In environments where shared symmetric keys are possible, they should 1232 be used in order to keep the AUTH_SESSION policy element size to a 1233 strict minimum, e.g., when wireless links are used. A secondary 1234 option would be PKI authentication, which provides a high level of 1235 security and good scalability. However, it requires the presence of 1236 credentials in the AUTH_SESSION policy element which impacts its 1237 size. 1239 Further security issues are outlined in RFC 4081 [RFC4081]. 1241 8. IANA Considerations 1243 This specification makes the following request to IANA: 1245 1. Assign a new object value for the AUTH_SESSION object from the 1246 shared NSLP object value space. 1248 2. All AUTH_SESSION object internal values and numbers should be 1249 taken from the allocations already done for RFC 3520 [RFC3520]. 1250 Yet, this specification does make use of two X-types introduced 1251 by RFC3520: Session_ID and Resources. 1253 9. Acknowledgments 1255 This document is based on the RFC 3520 [RFC3520] and credit therefore 1256 goes to the authors of RFC 3520, namely Louis-Nicolas Hamer, Brett 1257 Kosinski, Bill Gage and Hugh Shieh. Part of this work was funded by 1258 Deutsche Telekom Laboratories within the context of the ScaleNet 1259 project. 1261 10. References 1263 10.1. Normative References 1265 [I-D.ietf-nsis-nslp-natfw] 1266 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1267 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1268 draft-ietf-nsis-nslp-natfw-18 (work in progress), 1269 February 2008. 1271 [I-D.ietf-nsis-ntlp] 1272 Schulzrinne, H. and R. Hancock, "GIST: General Internet 1273 Signalling Transport", draft-ietf-nsis-ntlp-15 (work in 1274 progress), February 2008. 1276 [I-D.ietf-nsis-qos-nslp] 1277 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1278 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 1279 (work in progress), February 2008. 1281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1282 Requirement Levels", BCP 14, RFC 2119, March 1997. 1284 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1285 Standards (PKCS) #1: RSA Cryptography Specifications 1286 Version 2.1", RFC 3447, February 2003. 1288 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1289 RFC 4306, December 2005. 1291 10.2. Informative References 1293 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1294 April 1992. 1296 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1297 Hashing for Message Authentication", RFC 2104, 1298 February 1997. 1300 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 1301 "Session Authorization Policy Element", RFC 3520, 1302 April 2003. 1304 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 1305 Session Set-up with Media Authorization", RFC 3521, 1306 April 2003. 1308 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1309 RFC 3852, July 2004. 1311 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1312 Bosch, "Next Steps in Signaling (NSIS): Framework", 1313 RFC 4080, June 2005. 1315 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1316 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1318 Authors' Addresses 1320 Jukka Manner 1321 Helsinki University of Technology (TKK) 1322 P.O. Box 3000 1323 Espoo FI-02015 TKK 1324 Finland 1326 Phone: +358 9 451 2481 1327 Email: jukka.manner@tkk.fi 1329 Martin Stiemerling 1330 Network Laboratories, NEC Europe Ltd. 1331 Kurfuersten-Anlage 36 1332 Heidelberg 69115 1333 Germany 1335 Phone: +49 (0) 6221 4342 113 1336 Email: stiemerling@nw.neclab.eu 1337 URI: http://www.stiemerling.org 1339 Hannes Tschofenig 1340 Nokia Siemens Networks 1341 Linnoitustie 6 1342 Espoo 02600 1343 Finland 1345 Phone: +358 (50) 4871445 1346 Email: Hannes.Tschofenig@gmx.net 1347 URI: http://www.tschofenig.priv.at 1349 Roland Bless 1350 Institute of Telematics, Universitaet Karlsruhe (TH) 1351 Zirkel 2, Building 20.20 1352 Karlsruhe 76131 1353 Germany 1355 Phone: +49 721 608 6413 1356 Email: bless@tm.uka.de 1357 URI: http://www.tm.uka.de/~bless 1359 Full Copyright Statement 1361 Copyright (C) The IETF Trust (2008). 1363 This document is subject to the rights, licenses and restrictions 1364 contained in BCP 78, and except as set forth therein, the authors 1365 retain all their rights. 1367 This document and the information contained herein are provided on an 1368 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1369 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1370 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1371 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1372 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1373 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1375 Intellectual Property 1377 The IETF takes no position regarding the validity or scope of any 1378 Intellectual Property Rights or other rights that might be claimed to 1379 pertain to the implementation or use of the technology described in 1380 this document or the extent to which any license under such rights 1381 might or might not be available; nor does it represent that it has 1382 made any independent effort to identify any such rights. Information 1383 on the procedures with respect to rights in RFC documents can be 1384 found in BCP 78 and BCP 79. 1386 Copies of IPR disclosures made to the IETF Secretariat and any 1387 assurances of licenses to be made available, or the result of an 1388 attempt made to obtain a general license or permission for the use of 1389 such proprietary rights by implementers or users of this 1390 specification can be obtained from the IETF on-line IPR repository at 1391 http://www.ietf.org/ipr. 1393 The IETF invites any interested party to bring to its attention any 1394 copyrights, patents or patent applications, or other proprietary 1395 rights that may cover technology that may be required to implement 1396 this standard. Please address the information to the IETF at 1397 ietf-ipr@ietf.org. 1399 Acknowledgment 1401 Funding for the RFC Editor function is provided by the IETF 1402 Administrative Support Activity (IASA).