idnits 2.17.1 draft-ietf-nsis-nslp-auth-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (September 22, 2010) is 4959 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** 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 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Manner 3 Internet-Draft Aalto Univ 4 Intended status: Experimental M. Stiemerling 5 Expires: March 26, 2011 NEC 6 H. Tschofenig 7 Nokia Siemens Networks 8 R. Bless, Ed. 9 KIT 10 September 22, 2010 12 Authorization for NSIS Signaling Layer Protocols 13 draft-ietf-nsis-nslp-auth-07.txt 15 Abstract 17 Signaling layer protocols specified within the NSIS framework may 18 rely on the GIST (General Internet Signaling Transport) protocol to 19 handle authorization. Still, the signaling layer protocol above GIST 20 itself may require separate authorization to be performed when a node 21 receives a request for a certain kind of service or resources. This 22 draft presents a generic model and object formats for session 23 authorization within the NSIS Signaling Layer Protocols. The goal of 24 session authorization is to allow the exchange of information between 25 network elements in order to authorize the use of resources for a 26 service and to coordinate actions between the signaling and transport 27 planes. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 26, 2011. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Conventions used in this document . . . . . . . . . . . . . . 4 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Session Authorization Object . . . . . . . . . . . . . . . . . 7 66 3.1. Session Authorization Object format . . . . . . . . . . . 7 67 3.2. Session Authorization Attributes . . . . . . . . . . . . . 8 68 3.2.1. Authorizing Entity Identifier . . . . . . . . . . . . 9 69 3.2.2. Session Identifier . . . . . . . . . . . . . . . . . . 11 70 3.2.3. Source Address . . . . . . . . . . . . . . . . . . . . 11 71 3.2.4. Destination Address . . . . . . . . . . . . . . . . . 13 72 3.2.5. Start time . . . . . . . . . . . . . . . . . . . . . . 14 73 3.2.6. End time . . . . . . . . . . . . . . . . . . . . . . . 15 74 3.2.7. NSLP Object List . . . . . . . . . . . . . . . . . . . 15 75 3.2.8. Authentication data . . . . . . . . . . . . . . . . . 17 76 4. Integrity of the SESSION_AUTH policy element . . . . . . . . . 18 77 4.1. Shared symmetric keys . . . . . . . . . . . . . . . . . . 18 78 4.1.1. Operational Setting using shared symmetric keys . . . 18 79 4.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 4.3. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 20 81 4.3.1. Operational Setting for public key based 82 authentication . . . . . . . . . . . . . . . . . . . . 21 83 4.4. HMAC Signed . . . . . . . . . . . . . . . . . . . . . . . 23 84 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 26 85 5.1. The Coupled Model . . . . . . . . . . . . . . . . . . . . 26 86 5.2. The associated model with one policy server . . . . . . . 26 87 5.3. The associated model with two policy servers . . . . . . . 27 88 5.4. The non-associated model . . . . . . . . . . . . . . . . . 27 89 6. Message Processing Rules . . . . . . . . . . . . . . . . . . . 28 90 6.1. Generation of the SESSION_AUTH by the authorizing 91 entity . . . . . . . . . . . . . . . . . . . . . . . . . . 28 92 6.2. Processing within the QoS NSLP . . . . . . . . . . . . . . 28 93 6.2.1. Message Generation . . . . . . . . . . . . . . . . . . 28 94 6.2.2. Message Reception . . . . . . . . . . . . . . . . . . 29 95 6.2.3. Authorization (QNE or PDP) . . . . . . . . . . . . . . 29 96 6.2.4. Error Signaling . . . . . . . . . . . . . . . . . . . 30 97 6.3. Processing with the NAT/FW NSLP . . . . . . . . . . . . . 30 98 6.3.1. Message Generation . . . . . . . . . . . . . . . . . . 31 99 6.3.2. Message Reception . . . . . . . . . . . . . . . . . . 31 100 6.3.3. Authorization (Router/PDP) . . . . . . . . . . . . . . 31 101 6.3.4. Error Signaling . . . . . . . . . . . . . . . . . . . 32 102 6.4. Integrity Protection of NSLP messages . . . . . . . . . . 32 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 104 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 105 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 107 10.1. Normative References . . . . . . . . . . . . . . . . . . . 40 108 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 109 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 42 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 112 1. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14, RFC 2119 117 [RFC2119]. 119 The term "NSLP node" (NN) is used to refer to an NSIS node running an 120 NSLP protocol that can make use of the authorization object discussed 121 in this document. Currently, this node would run either the QoS NSLP 122 [I-D.ietf-nsis-qos-nslp] or the NAT/FW NSLP 123 [I-D.ietf-nsis-nslp-natfw] service. 125 2. Introduction 127 The Next Steps in Signaling (NSIS) framework [RFC4080] defines a 128 suite of protocols for the next generation in Internet signaling. 129 The design is based on a generalized transport protocol for signaling 130 applications, the General Internet Signaling Transport (GIST) 131 [I-D.ietf-nsis-ntlp], and various kinds of signaling applications. 132 Two signaling applications and their NSIS Signaling Layer Protocol 133 (NSLP) have been designed, a Quality of Service application (QoS 134 NSLP) [I-D.ietf-nsis-qos-nslp] and a NAT/firewall application 135 (NAT/FW) [I-D.ietf-nsis-nslp-natfw]. 137 The basic security architecture for NSIS is based on a chain-of-trust 138 model, where each GIST hop may choose the appropriate security 139 protocol, taking into account the signaling application requirements. 140 For instance, communication between two directly adjacent GIST peers 141 may be secured via TCP/TLS. On the one hand this model is 142 appropriate for a number of different use cases, and allows the 143 signaling applications to leave the handling of security to GIST. On 144 the other hand, several sessions of different signaling applications 145 are then multiplexed onto the same GIST TLS connection. 147 Yet, in order to allow for finer-grain per-session or per-user 148 admission control, it is necessary to provide a mechanism for 149 ensuring that the use of resources by a host has been properly 150 authorized before allowing the signaling application to commit the 151 resource request, e.g., a QoS reservation or mappings for NAT 152 traversal. In order to meet this requirement, there must be 153 information in the NSLP message which may be used to verify the 154 validity of the request. This can be done by providing the host with 155 a session authorization policy element which is inserted into the 156 message and verified by the respective network elements. 158 This document describes a generic NSLP layer session authorization 159 policy object (SESSION_AUTH) used to convey authorization information 160 for the request. Generic in this context means that it is usable by 161 all NSLPs. The scheme is based on third-party tokens. A trusted 162 third party provides authentication tokens to clients and allows 163 verification of the information by the network elements. The 164 requesting host inserts its authorization information acquired from 165 the trusted third party into the NSLP message to allow verification 166 of the network resource request. Network elements verify the request 167 and then process it based on admission policy (e.g., they perform a 168 resource reservation or change bindings or firewall filter). This 169 work is based on RFC 3520 [RFC3520] and RFC 3521 [RFC3521]. 171 The default operation when using NSLP layer session authorization is 172 to add one authorization policy object. Yet, in order to support 173 end-to-end signaling and request authorization from different 174 networks, a host initiating an NSLP signaling session may add more 175 than one SESSION_AUTH object in the message. The identifier of the 176 authorizing entity can be used by the network elements to use the 177 third party they trust to verify the request. 179 3. Session Authorization Object 181 This section presents a new NSLP layer object called session 182 authorization (SESSION_AUTH). The SESSION_AUTH object can be used in 183 the currently specified and future NSLP protocols. 185 The authorization attributes follow the format and specification 186 given in RFC3520 [RFC3520]. 188 3.1. Session Authorization Object format 190 The SESSION_AUTH object contains a list of fields which describe the 191 session, along with other attributes. The object header follows the 192 generic NSLP object header, therefore it can be used together with 193 any NSLP. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |A|B|r|r| Type |r|r|r|r| Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 + + 201 // Session Authorization Attribute List // 202 + + 203 +---------------------------------------------------------------+ 205 The value for the Type field comes from shared NSLP object type 206 space. The Length field is given in units of 32 bit words and 207 measures the length of the Value component of the TLV object (i.e. it 208 does not include the standard header). 210 The bits marked 'A' and 'B' are extensibility flags, and used to 211 signal the desired treatment for objects whose treatment has not been 212 defined in the protocol specification (i.e. whose Type field is 213 unknown at the receiver). The following four categories of object 214 have been identified, and are described here for informational 215 purposes only, i.e., for normative behavior refer to the particular 216 NSLP documents (e.g., [I-D.ietf-nsis-qos-nslp] 217 [I-D.ietf-nsis-nslp-natfw]). 219 AB=00 ("Mandatory"): If the object is not understood, the entire 220 message containing it MUST be rejected, and an error message sent 221 back (usually of class/code "Protocol Error/Unknown object present"). 223 AB=01 ("Ignore"): If the object is not understood, it MUST be deleted 224 and the rest of the message processed as usual. 226 AB=10 ("Forward"): If the object is not understood, it MUST be 227 retained unchanged in any message forwarded as a result of message 228 processing, but not stored locally. 230 AB=11 ("Refresh"): If the object is not understood, it should be 231 incorporated into the locally stored signaling application state for 232 this flow/session, forwarded in any resulting message, and also used 233 in any refresh or repair message which is generated locally. This 234 flag combination is not used by all NSLPs, e.g., it is not used in 235 NATFW NSLP. 237 The remaining bits marked 'r' are reserved. The extensibility flags 238 follow the definition in the GIST specification. The SESSION_AUTH 239 object defines in this specification MUST have the AB-bits set to 240 "10". An NSLP Node (NN) may use the authorization information if it 241 is configured to do so, but may also just skip the object. 243 Type: SESSION_AUTH_OBJ (IANA-TBD) 245 Length: Variable, contains length of Session authorization object 246 list in units of 32 bit words. 248 Session Authorization Attribute List: variable length 250 The session authorization attribute list is a collection of 251 objects that describes the session and provides other information 252 necessary to verify resource request (e.g., a resource 253 reservation, binding, or firewall filter change request). An 254 initial set of valid objects is described in Section 3.2. 256 3.2. Session Authorization Attributes 258 A session authorization attribute may contain a variety of 259 information and has both an attribute type and subtype. The 260 attribute itself MUST be a multiple of 4 octets in length, and any 261 attributes that are not a multiple of 4 octets long MUST be padded to 262 a 4-octet boundary. All padding bytes MUST have a value of zero. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Length | X-Type | SubType | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 // Value ... // 270 +---------------------------------------------------------------+ 272 Length: 16 bits 273 The Length field is two octets and indicates the actual length of 274 the attribute (including Length, X-Type and SubType fields) in 275 number of octets. The length does NOT include any bytes padding 276 to the value field to make the attribute a multiple of 4 octets 277 long. 279 X-Type: 8 bits 281 Session authorization attribute type (X-Type) field is one octet. 282 IANA acts as a registry for X-Types as described in Section 8, 283 IANA Considerations. This specification uses the following 284 X-Types: 286 1. AUTH_ENT_ID The unique identifier of the entity that authorized 287 the session. 289 2. SESSION_ID Unique identifier for this session, usually created 290 locally at the authorizing entity. See also RFC 3520 [RFC3520], 291 not to be confused with the SESSIONID of GIST/NSIS. 293 3. SOURCE_ADDR Address specification for the signaling session 294 initiator, i.e., the source address of the signaling message 295 originator. 297 4. DEST_ADDR Address specification for the signaling session end- 298 point. 300 5. START_TIME The starting time for the session. 302 6. END_TIME The end time for the session. 304 7. AUTHENTICATION_DATA Authentication data of the session 305 authorization policy element. 307 SubType: 8 bits 309 Session authorization attribute sub-type is one octet in length. 310 The value of the SubType depends on the X-Type. 312 Value: variable length 314 The attribute specific information. 316 3.2.1. Authorizing Entity Identifier 318 AUTH_ENT_ID is used to identify the entity that authorized the 319 initial service request and generated the session authorization 320 policy element. The AUTH_ENT_ID may be represented in various 321 formats, and the SubType is used to define the format for the ID. 322 The format for AUTH_ENT_ID is as follows: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Length | X-Type | SubType | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 // OctetString ... // 330 +---------------------------------------------------------------+ 332 Length: Length of the attribute, which MUST be > 4. 334 X-Type: AUTH_ENT_ID 336 SubType: 338 The following sub-types for AUTH_ENT_ID are defined. IANA acts as 339 a registry for AUTH_ENT_ID sub-types as described in Section 8, 340 IANA Considerations. Initially, the registry contains the 341 following sub-types of AUTH_ENT_ID: 343 1. IPV4_ADDRESS IPv4 address represented in 32 bits 345 2. IPV6_ADDRESS IPv6 address represented in 128 bits 347 3. FQDN Fully Qualified Domain Name as defined in [RFC1034] as an 348 ASCII string. 350 4. ASCII_DN X.500 Distinguished name as defined in [RFC4514] as an 351 ASCII string. 353 5. UNICODE_DN X.500 Distinguished name as defined in [RFC4514] as a 354 UTF-8 string. 356 6. URI Universal Resource Identifier, as defined in [RFC3986]. 358 7. KRB_PRINCIPAL Fully Qualified Kerberos Principal name 359 represented by the ASCII string of a principal followed by the @ 360 realm name as defined in [RFC4120] (e.g., johndoe@nowhere). 362 8. X509_V3_CERT The Distinguished Name of the subject of the 363 certificate as defined in [RFC4514] as a UTF-8 string. 365 9. PGP_CERT The OpenPGP certificate of the authorizing entity as 366 defined as Public-Key Packet in [RFC4880]. 368 10. HMAC_SIGNED Indicates that the AUTHENTICATION_DATA attribute 369 contains a self-signed HMAC signature [RFC2104] that ensures the 370 integrity of the NSLP message. The HMAC is calculated over all 371 NSLP objects given in the NSLP_OBJECT_LIST attribute that MUST 372 also be present. The object specifies the Hash Algorithm that 373 is used for calculation of the HMAC as Transform ID from 374 Transform Type 3 of the IKEv2 registry [RFC4306]. 376 OctetString: Contains the authorizing entity identifier. 378 3.2.2. Session Identifier 380 SESSION_ID is a unique identifier used by the authorizing entity to 381 identify the request. It may be used for a number of purposes, 382 including replay detection, or to correlate this request to a policy 383 decision entry made by the authorizing entity. For example, the 384 SESSION_ID can be based on simple sequence numbers or on a standard 385 NTP timestamp. 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Length | X-Type | SubType | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 // OctetString ... // 393 +---------------------------------------------------------------+ 395 Length: Length of the attribute, which MUST be > 4. 397 X-Type: SESSION_ID 399 SubType: 401 No subtypes for SESSION_ID are currently defined; this field MUST be 402 set to zero. The authorizing entity is the only network entity that 403 needs to interpret the contents of the SESSION_ID therefore the 404 contents and format are implementation dependent. 406 OctetString: The OctetString contains the session identifier. 408 3.2.3. Source Address 410 SOURCE_ADDR is used to identify the source address specification of 411 the authorized session. This X-Type may be useful in some scenarios 412 to make sure the resource request has been authorized for that 413 particular source address and/or port. Usually, it corresponds to 414 the signaling source, e.g., the IP source address of the GIST packet, 415 or flow source or flow destination address respectively, which are 416 contained in the GIST MRI (Message Routing Information) object. 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Length | X-Type | SubType | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 // OctetString ... // 424 +---------------------------------------------------------------+ 426 Length: Length of the attribute, which MUST be > 4. 428 X-Type: SOURCE_ADDR 430 SubType: 432 The following sub types for SOURCE_ADDR are defined. IANA acts as 433 a registry for SOURCE_ADDR sub-types as described in Section 8, 434 IANA Considerations. Initially, the registry contains the 435 following sub types for SOURCE_ADDR: 437 1. IPV4_ADDRESS IPv4 address represented in 32 bits 439 2. IPV6_ADDRESS IPv6 address represented in 128 bits 441 3. UDP_PORT_LIST list of UDP port specifications, represented as 16 442 bits per list entry. 444 4. TCP_PORT_LIST list of TCP port specifications, represented as 16 445 bits per list entry. 447 5. SPI Security Parameter Index represented in 32 bits 449 OctetString: The OctetString contains the source address information. 451 In scenarios where a source address is required (see Section 5), at 452 least one of the subtypes 1 or 2 MUST be included in every Session 453 Authorization Data Policy Element. Multiple SOURCE_ADDR attributes 454 MAY be included if multiple addresses have been authorized. The 455 source address of the request (e.g., a QoS NSLP RESERVE) MUST match 456 one of the SOURCE_ADDR attributes contained in this Session 457 Authorization Data Policy Element. 459 At most, one instance of subtype 3 MAY be included in every Session 460 Authorization Data Policy Element. At most, one instance of subtype 461 4 MAY be included in every Session Authorization Data Policy Element. 462 Inclusion of a subtype 3 attribute does not prevent inclusion of a 463 subtype 4 attribute (i.e., both UDP and TCP ports may be authorized). 465 If no PORT attributes are specified, then all ports are considered 466 valid; otherwise, only the specified ports are authorized for use. 467 Every source address and port list must be included in a separate 468 SOURCE_ADDR attribute. 470 3.2.4. Destination Address 472 DEST_ADDR is used to identify the destination address of the 473 authorized session. This X-Type may be useful in some scenarios to 474 make sure the resource request has been authorized for that 475 particular destination address and/or port. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Length | X-Type | SubType | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 // OctetString ... // 483 +---------------------------------------------------------------+ 485 Length: Length of the attribute in number of octets, which MUST be > 486 4. 488 X-Type: DEST_ADDR 490 SubType: 492 The following sub types for DEST_ADDR are defined. IANA acts as a 493 registry for DEST_ADDR sub-types as described in Section 8, IANA 494 Considerations. Initially, the registry contains the following 495 sub types for DEST_ADDR: 497 1. IPV4_ADDRESS IPv4 address represented in 32 bits 499 2. IPV6_ADDRESS IPv6 address represented in 128 bits 501 3. UDP_PORT_LIST list of UDP port specifications, represented as 16 502 bits per list entry. 504 4. TCP_PORT_LIST list of TCP port specifications, represented as 16 505 bits per list entry. 507 5. SPI Security Parameter Index represented in 32 bits 509 OctetString: The OctetString contains the destination address 510 specification. 512 In scenarios where a destination address is required (see Section 5), 513 at least one of the subtypes 1 or 2 MUST be included in every Session 514 Authorization Data Policy Element. Multiple DEST_ADDR attributes MAY 515 be included if multiple addresses have been authorized. The 516 destination address field of the resource reservation datagram (e.g., 517 QoS NSLP Reserve) MUST match one of the DEST_ADDR attributes 518 contained in this Session Authorization Data Policy Element. 520 At most, one instance of subtype 3 MAY be included in every Session 521 Authorization Data Policy Element. At most, one instance of subtype 522 4 MAY be included in every Session Authorization Data Policy Element. 523 Inclusion of a subtype 3 attribute does not prevent inclusion of a 524 subtype 4 attribute (i.e., both UDP and TCP ports may be authorized). 526 If no PORT attributes are specified, then all ports are considered 527 valid; otherwise, only the specified ports are authorized for use. 529 Every destination address and port list must be included in a 530 separate DEST_ADDR attribute. 532 3.2.5. Start time 534 START_TIME is used to identify the start time of the authorized 535 session and can be used to prevent replay attacks. If the 536 SESSION_AUTH policy element is presented in a resource request, the 537 network SHOULD reject the request if it is not received within a few 538 seconds of the start time specified. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Length | X-Type | SubType | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 // OctetString ... // 546 +---------------------------------------------------------------+ 548 Length: Length of the attribute, which MUST be > 4. 550 X-Type: START_TIME 552 SubType: 554 The following sub types for START_TIME are defined. IANA acts as a 555 registry for START_TIME sub-types as described in Section 8, IANA 556 Considerations. Initially, the registry contains the following sub 557 types for START_TIME: 559 1. 1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 5905 560 [RFC5905]. 562 OctetString: The OctetString contains the start time. 564 3.2.6. End time 566 END_TIME is used to identify the end time of the authorized session 567 and can be used to limit the amount of time that resources are 568 authorized for use (e.g., in prepaid session scenarios). 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Length | X-Type | SubType | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 // OctetString ... // 576 +---------------------------------------------------------------+ 578 Length: Length of the attribute, which MUST be > 4. 580 X-Type: END_TIME 582 SubType: 584 The following sub types for END_TIME are defined. IANA acts as a 585 registry for END_TIME sub-types as described in Section 8, IANA 586 Considerations. Initially, the registry contains the following sub 587 types for END_TIME: 589 1. NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 5905 590 [RFC5905]. 592 OctetString: The OctetString contains the end time. 594 3.2.7. NSLP Object List 596 The NSLP_OBJECT_LIST attribute contains a list of NSLP objects types 597 that are used in the keyed-hash computation whose result is given in 598 the AUTHENTICATION_DATA attribute. This allows for an integrity 599 protection of NSLP PDUs. If an NSLP_OBJECT_LIST attribute has been 600 included in the SESSION_AUTH policy element, an AUTHENTICATION_DATA 601 attribute MUST also be present. 603 The creator of this attribute lists every NSLP object type whose NSLP 604 PDU object was included in the computation of the hash. The hash 605 computation has to follow the order of the NSLP object types as 606 specified by the list. The receiver can verify the integrity of the 607 NSLP PDU by computing a hash over all NSLP objects that are listed in 608 this attribute (in the given order) including all the attributes of 609 the authorization object. Since all NSLP object types are unique 610 over all different NSLPs, this will work for any NSLP. 612 Basic NTLP/NSLP objects like the session ID, the NSLPID and the MRI 613 MUST be always included in the HMAC. Since they are not carried 614 within the NSLP itself, but only within GIST, they have to be 615 provided for HMAC calculation, e.g., they can be delivered via the 616 GIST API. They MUST be normalized to their network representation 617 from [I-D.ietf-nsis-ntlp] again before calculating the hash. These 618 values MUST be hashed first (in order sessionID, NSLPID, MRI), before 619 any other NSLP object values that are included in the hash 620 computation. 622 A summary of the NSLP_OBJECT_LIST attribute format is described 623 below. 625 0 1 2 3 626 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 627 +---------------+---------------+---------------+---------------+ 628 | Length | NSLP_OBJ_LIST | zero | 629 +---------------+---------------+-------+-------+---------------+ 630 | # of signed NSLP objects = n | rsv | NSLP object type (1) | 631 +-------+-------+---------------+-------+-------+---------------+ 632 | rsv | NSLP object type (2) | ..... // 633 +-------+-------+---------------+---------------+---------------+ 634 | rsv | NSLP object type (n) | (padding if required) | 635 +--------------+----------------+---------------+---------------+ 637 Length: Length of the attribute, which MUST be > 4. 639 X-Type: NSLP_OBJECT_LIST 641 SubType: No sub types for NSLP_OBJECT_LIST are currently defined. 642 This field MUST be set to 0 and ignored upon reception. 644 # of signed NSLP objects: The number n of NSLP object types that 645 follow. n=0 is allowed, i.e., only a padding field is contained then. 647 rsv: reserved bits and MUST be set to 0 (zero) and ignored upon 648 reception. 650 NSLP object type: the NSLP 12-bit object type identifier of the 651 object that was included in the hash calculation. The NSLP object 652 type values comprise only 12 bit, so four bits per type value are 653 currently not used within the list. Depending on the number of 654 signed objects, a corresponding padding word of 16 bit must be 655 supplied. 657 padding: padding MUST be added if the number of NSLP objects is even 658 and MUST NOT be added if the number of NSLP objects is odd. If 659 padding has to be applied the padding field MUST be 16 bit set to 0 660 and its contents MUST be ignored upon reception. 662 3.2.8. Authentication data 664 The AUTHENTICATION_DATA attribute contains the authentication data of 665 the SESSION_AUTH policy element and signs all the data in the policy 666 element up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA 667 attribute has been included in the SESSION_AUTH policy element, it 668 MUST be the last attribute in the list. The algorithm used to 669 compute the authentication data depends on the AUTH_ENT_ID SubType 670 field. See Section 4 entitled Integrity of the SESSION_AUTH policy 671 element. 673 A summary of AUTHENTICATION_DATA attribute format is described below. 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Length | X-Type | SubType | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 // OctetString ... // 681 +---------------------------------------------------------------+ 683 Length: Length of the attribute, which MUST be > 4. 685 X-Type: AUTHENTICATION_DATA 687 SubType: No sub types for AUTHENTICATION_DATA are currently defined. 688 This field MUST be set to 0 and ignored upon reception. 690 OctetString: The OctetString contains the authentication data of the 691 SESSION_AUTH. 693 4. Integrity of the SESSION_AUTH policy element 695 This section describes how to ensure the integrity of the policy 696 element is preserved. 698 4.1. Shared symmetric keys 700 In shared symmetric key environments, the AUTH_ENT_ID MUST be of 701 subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or 702 URI. An example SESSION_AUTH object is shown below. 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 |1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Length | AUTH_ENT_ID | IPV4_ADDRESS | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | OctetString ... (The authorizing entity's Identifier) | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Length | AUTH_DATA | zero | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | KEY_ID | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | OctetString ... (Authentication data) | 718 +---------------------------------------------------------------+ 720 4.1.1. Operational Setting using shared symmetric keys 722 This assumes both the Authorizing Entity and the Network router/PDP 723 (Policy Decision Point) are provisioned with shared symmetric keys 724 and with policies detailing which algorithm to be used for computing 725 the authentication data along with the expected length of the 726 authentication data for that particular algorithm. 728 Key maintenance is outside the scope of this document, but 729 SESSION_AUTH implementations MUST at least provide the ability to 730 manually configure keys and their parameters. The key used to 731 produce the authentication data is identified by the AUTH_ENT_ID 732 field. Since multiple keys may be configured for a particular 733 AUTH_ENT_ID value, the first 32 bits of the AUTH_DATA field MUST be a 734 key ID to be used to identify the appropriate key. Each key must 735 also be configured with lifetime parameters for the time period 736 within which it is valid as well as an associated cryptographic 737 algorithm parameter specifying the algorithm to be used with the key. 738 At a minimum, all SESSION_AUTH implementations MUST support the HMAC- 739 SHA2-256 [RFC4868] [RFC2104] cryptographic algorithm for computing 740 the authentication data. 742 It is good practice to regularly change keys. Keys MUST be 743 configurable such that their lifetimes overlap allowing smooth 744 transitions between keys. At the midpoint of the lifetime overlap 745 between two keys, senders should transition from using the current 746 key to the next/longer-lived key. Meanwhile, receivers simply accept 747 any identified key received within its configured lifetime and reject 748 those that are not. 750 4.2. Kerberos 752 Since Kerberos [RFC4120] is widely used for end-user authorization, 753 e.g., in Windows domains, it is well suited for being used in the 754 context of user-based authorization for NSIS sessions. For instance, 755 a user may request a ticket for authorization of installing rules in 756 an NATFW-capable router. 758 In a Kerberos environment, it is assumed that the user of the 759 requesting NSLP host requests a ticket from the (the Kerberos Key 760 Distribution Center - KDC) for using the NSLP Node (router) as 761 resource (target service). The NSLP requesting host (client) can 762 present the ticket to the NSLP node via Kerberos by sending a 763 KRB_CRED message to the NSLP node independently but prior to the NSLP 764 exchange. Thus, the principal name of the service must be known at 765 the client in advance, though the exact IP address may not be known 766 in advance. How the name is assigned and made available to the 767 client is implementation specific. The extracted common session key 768 can subsequently be used for using the HMAC_SIGNED variant of the 769 SESSION_AUTH object. 771 Another option is to encapsulate the credentials in the AUTH_DATA 772 portion of the SESSION_AUTH object. In this case the AUTH_ENT_ID 773 MUST be of the subtype KRB_PRINCIPAL. The KRB_PRINCIPAL field is 774 defined as the Fully Qualified Kerberos Principal name of the 775 authorizing entity. The AUTH_DATA portion of the SESSION_AUTH object 776 contains the KRB_CRED message that the receiving NSLP node has to 777 extract and verify. A second SESSION_AUTH object of type HMAC_SIGNED 778 SHOULD protect the integrity of the NSLP message, including the prior 779 SESSION_AUTH object. The session key included in the first 780 SESSION_AUTH object has to be used for HMAC calculation. 782 An example of the Kerberos AUTH_DATA policy element is shown below in 783 Figure 1. 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 |1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Length | AUTH_ENT_ID | KERB_P. | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | OctetString ... (The principal@realm name) | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Length | AUTH_DATA | zero | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | OctetString ... (KRB_CRED Data) | 797 +---------------------------------------------------------------+ 799 Figure 1 801 4.3. Public Key 803 In a public key environment, the AUTH_ENT_ID MUST be of the subtypes: 804 X509_V3_CERT or PGP_CERT. The authentication data is used for 805 authenticating the authorizing entity. Two examples of the public 806 key SESSION_AUTH policy element are shown in Figure 2 and Figure 3. 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 |1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Length | AUTH_ENT_ID | PGP_CERT | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | OctetString ... (Authorizing entity Digital Certificate) | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Length | AUTH_DATA | zero | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | OctetString ... (Authentication data) | 820 +---------------------------------------------------------------+ 822 Example of a SESSION_AUTH_OBJECT using a PGP Certificate 824 Figure 2 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 |1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Length | AUTH_ENT_ID | X509_V3_CERT | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | OctetString ... (Authorizing entity Digital Certificate) | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Length | AUTH_DATA | zero | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | OctetString ... (Authentication data) | 838 +---------------------------------------------------------------+ 840 Example of a SESSION_AUTH_OBJECT using an X509_V3_CERT Certificate 842 Figure 3 844 4.3.1. Operational Setting for public key based authentication 846 Public key based authentication assumes the following: 848 o Authorizing entities have a pair of keys (private key and public 849 key). 851 o Private key is secured with the authorizing entity. 853 o Public keys are stored in digital certificates and a trusted 854 party, certificate authority (CA) issues these digital 855 certificates. 857 o The verifier (PDP or router) has the ability to verify the digital 858 certificate. 860 Authorizing entity uses its private key to generate 861 AUTHENTICATION_DATA. Authenticators (router, PDP) use the 862 authorizing entity's public key (stored in the digital certificate) 863 to verify and authenticate the policy element. 865 4.3.1.1. X.509 V3 digital certificates 867 When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA 868 MUST be generated by the authorizing entity following these steps: 870 o A Signed-data is constructed as defined in RFC5652 [RFC5652]. A 871 digest is computed on the content (as specified in Section 6.1) 872 with a signer-specific message-digest algorithm. The certificates 873 field contains the chain of authorizing entity's X.509 V3 digital 874 certificates. The certificate revocation list is defined in the 875 crls field. The digest output is digitally signed following 876 Section 8 of RFC 3447 [RFC3447], using the signer's private key. 878 When the AUTH_ENT_ID is of type X509_V3_CERT, verification at the 879 verifying network element (PDP or router) MUST be done following 880 these steps: 882 o Parse the X.509 V3 certificate to extract the distinguished name 883 of the issuer of the certificate. 885 o Certification Path Validation is performed as defined in Section 6 886 of RFC 5280 [RFC5280]. 888 o Parse through the Certificate Revocation list to verify that the 889 received certificate is not listed. 891 o Once the X.509 V3 certificate is validated, the public key of the 892 authorizing entity can be extracted from the certificate. 894 o Extract the digest algorithm and the length of the digested data 895 by parsing the CMS signed-data. 897 o The recipient independently computes the message digest. This 898 message digest and the signer's public key are used to verify the 899 signature value. 901 This verification ensures integrity, non-repudiation and data origin. 903 4.3.1.2. PGP digital certificates 905 When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be 906 generated by the authorizing entity following these steps: 908 AUTHENTICATION_DATA contains a Signature Packet as defined in Section 909 5.2.3 of RFC 4880 [RFC4880]. In summary: 911 o Compute the hash of all data in the SESSION_AUTH policy element up 912 to the AUTHENTICATION_DATA. 914 o The hash output is digitally signed following Section 8 of RFC 915 3447, using the signer's private key. 917 When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done 918 by the verifying network element (PDP or router) following these 919 steps: 921 o Validate the certificate. 923 o Once the PGP certificate is validated, the public key of the 924 authorizing entity can be extracted from the certificate. 926 o Extract the hash algorithm and the length of the hashed data by 927 parsing the PGP signature packet. 929 o The recipient independently computes the message digest. This 930 message digest and the signer's public key are used to verify the 931 signature value. 933 This verification ensures integrity, non-repudiation and data origin. 935 4.4. HMAC Signed 937 A SESSION_AUTH object that carries an AUTH_ENT_ID of HMAC_SIGNED is 938 used as integrity protection for NSLP messages. The SESSION_AUTH 939 object MUST contain the following attributes: 941 o SOURCE_ADDR the source address of the entity that created the HMAC 943 o START_TIME the timestamp when the HMAC signature was calculated. 944 This MUST be different for any two messages in sequence in order 945 to prevent replay attacks. Since the NTP timestamp provides 946 currently a resolution of 200 pico seconds this should be 947 sufficient. 949 o NSLP_OBJECT_LIST this attribute lists all NSLP objects that are 950 included into HMAC calculation. 952 o AUTHENTICATION_DATA this attribute contains the Key-ID that is 953 used for HMAC calculation as well as the HMAC data itself 954 [RFC2104]. 956 The key used for HMAC calculation must be exchanged securely by some 957 other means, e.g., a Kerberos Ticket or pre-shared manual 958 installation etc. The Key-ID in the AUTHENTICATION_DATA allows the 959 reference to the appropriate key and also to periodically change 960 signing keys within a session. The key length MUST be 64-bit at 961 least, but it is ideally longer in order to defend against brute 962 force attacks during the key validity period. For scalability 963 reasons it is suggested to use a per-user key for signing NSLP 964 messages, but using a per-session key is possible, too, at the cost 965 of a per-session key exchange. A per-user key allows for 966 verification of the authenticity of the message and thus provides a 967 basis for a session-based per-user authorization. It is RECOMMENDED 968 to periodically change the shared key in order to prevent 969 eavesdroppers from performing a brute force off-line attacks on the 970 shared key. The actual hash algorithm used in the HMAC computation 971 is specified by the "Transform ID" field (given as Transform Type 3 972 of the IKEv2 registry [RFC4306]). The hash algorithm MUST be chosen 973 consistently between the object creator and the NN verifying the 974 HMAC; this can be accomplished by out-of-band mechanisms when the 975 shared key is exchanged. 977 Figure 4 shows an example of an object that is used for integrity 978 protection of NSLP messages. 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 |1|0|0|0| Type = SESSION_AUTH |0|0|0|0| Object Length | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | Length | AUTH_ENT_ID | HMAC_SIGNED | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | reserved | Transform ID | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Length | SOURCE_ADDR | IPV4_ADDRESS | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | IPv4 Source Address of NSLP sender | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Length | START_TIME | NTP_TIME_STAMP| 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | NTP Time Stamp (1) | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | NTP Time Stamp (2) | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Length | NSLP_OBJ_LIST | zero | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 |No. of signed NSLP objects = n | rsv | NSLP object type (1) | 1002 +-------+-------+---------------+-------+-------+---------------+ 1003 | rsv | NSLP object type (2) | ..... // 1004 +-------+-------+---------------+---------------+---------------+ 1005 | rsv | NSLP object type (n) | (padding if required) | 1006 +--------------+----------------+---------------+---------------+ 1007 | Length | AUTH_DATA | zero | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | KEY_ID | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Message Authentication Code HMAC Data | 1012 +---------------------------------------------------------------+ 1014 Example of a SESSION_AUTH_OBJECT that provides integrity protection 1015 for NSLP messages 1017 Figure 4 1019 5. Framework 1021 RFC3521 [RFC3521] describes a framework in which the SESSION_AUTH 1022 policy element may be utilized to transport information required for 1023 authorizing resource reservation for data flows (e.g., media flows). 1024 RFC3521 introduces 4 different models: 1026 1. The coupled model 1028 2. The associated model with one policy server 1030 3. The associated model with two policy servers 1032 4. The non-associated model. 1034 The fields that are required in a SESSION_AUTH policy element depend 1035 on which of the models is used. 1037 5.1. The Coupled Model 1039 In the coupled model, the only information that MUST be included in 1040 the policy element is the SESSION_ID; it is used by the Authorizing 1041 Entity to correlate the resource reservation request with the media 1042 authorized during session set up. Since the End Host is assumed to 1043 be untrusted, the Policy Server SHOULD take measures to ensure that 1044 the integrity of the SESSION_ID is preserved in transit; the exact 1045 mechanisms to be used and the format of the SESSION_ID are 1046 implementation dependent. 1048 5.2. The associated model with one policy server 1050 In this model, the contents of the SESSION_AUTH policy element MUST 1051 include: 1053 o A session identifier - SESSION_ID. This is information that the 1054 authorizing entity can use to correlate the resource request with 1055 the data flows authorized during session set up. 1057 o The identity of the authorizing entity - AUTH_ENT_ID. This 1058 information is used by an NN to determine which authorizing entity 1059 (Policy Server) should be used to solicit resource policy 1060 decisions. 1062 In some environments, an NN may have no means for determining if the 1063 identity refers to a legitimate Policy Server within its domain. In 1064 order to protect against redirection of authorization requests to a 1065 bogus authorizing entity, the SESSION_AUTH MUST also include: 1067 AUTHENTICATION_DATA. This authentication data is calculated over 1068 all other fields of the SESSION_AUTH policy element. 1070 5.3. The associated model with two policy servers 1072 The content of the SESSION_AUTH Policy Element is identical to the 1073 associated model with one policy server. 1075 5.4. The non-associated model 1077 In this model, the SESSION_AUTH MUST contain sufficient information 1078 to allow the Policy Server to make resource policy decisions 1079 autonomously from the authorizing entity. The policy element is 1080 created using information about the session by the authorizing 1081 entity. The information in the SESSION_AUTH policy element MUST 1082 include: 1084 o Initiating party IP address or Identity (e.g., FQDN) - SOURCE_ADDR 1085 X-TYPE 1087 o Responding party IP address or Identity (e.g., FQDN) - DEST_ADDR 1088 X-TYPE 1090 o The authorization lifetime - START_TIME X-TYPE 1092 o The identity of the authorizing entity to allow for validation of 1093 the token in shared symmetric key and Kerberos schemes - 1094 AUTH_ENT_ID X-TYPE 1096 o The credentials of the authorizing entity in a public-key scheme - 1097 AUTH_ENT_ID X-TYPE 1099 o Authentication data used to prevent tampering with the 1100 SESSION_AUTH policy element - AUTHENTICATION_DATA 1102 Furthermore, the SESSION_AUTH policy element MAY contain: 1104 o The lifetime of (each of) the media stream(s) - END_TIME X-TYPE 1106 o Initiating party port number - SOURCE_ADDR X-TYPE 1108 o Responding party port number - DEST_ADDR X-TYPE 1110 All SESSION_AUTH fields MUST match with the resource request. If a 1111 field does not match, the request SHOULD be denied. 1113 6. Message Processing Rules 1115 This section discusses the message processing related to the 1116 SESSION_AUTH object. Details of the processing the SESSION_AUTH 1117 object within QoS NSLP and NAT/FW NSLP are described. New NSLP 1118 protocols should use the same logic in making use of the SESSION_AUTH 1119 object. 1121 6.1. Generation of the SESSION_AUTH by the authorizing entity 1123 1. Generate the SESSION_AUTH policy element with the appropriate 1124 contents as specified in Section 3. 1126 2. If authentication is needed, the entire SESSION_AUTH policy 1127 element is constructed, excluding the length, type and subtype 1128 fields of the SESSION_AUTH field. Note that the message MUST 1129 include a START_TIME to prevent replay attacks. The output of 1130 the authentication algorithm, plus appropriate header 1131 information, is appended as AUTHENTICATION_DATA attribute to the 1132 SESSION_AUTH policy element. 1134 6.2. Processing within the QoS NSLP 1136 The SESSION_AUTH object may be used with QoS NSLP QUERY and RESERVE 1137 messages to authorize the query operation for network resources, and 1138 a resource reservation request, respectively. 1140 Moreover, the SESSION_AUTH object may also be used with RESPONSE 1141 messages in order to indicate that the authorizing entity changed the 1142 original request. For example, the session start or end times may 1143 have been modified, or the client may have requested authorization 1144 for all ports, but the authorizing entity only allowed the use of 1145 certain ports. 1147 If the QoS NSIS Initiator (QNI) receives a RESPONSE message with a 1148 SESSION_AUTH object, the QNI MUST inspect the SESSION_AUTH object to 1149 see what authentication attribute was changed by an authorizing 1150 entity. The QNI SHOULD also silently accept SESSION_AUTH objects in 1151 RESPONSE message, which do not indicate any change to the original 1152 authorization request. 1154 6.2.1. Message Generation 1156 A QoS NSLP message is created as specified in 1157 [I-D.ietf-nsis-qos-nslp]. 1159 1. The policy element received from the authorizing entity MUST be 1160 copied without modification into the SESSION_AUTH object. 1162 2. The SESSION_AUTH object (containing the policy element) is 1163 inserted in the NSLP message in the appropriate place. 1165 6.2.2. Message Reception 1167 The QoS NSLP message is processed as specified in 1168 [I-D.ietf-nsis-qos-nslp] with following modifications. 1170 1. If the QNE is policy aware then it SHOULD use the Diameter QoS 1171 application or the RADIUS QoS protocol to communicate with the 1172 PDP. To construct the AAA message it is necessary to extract the 1173 SESSION_AUTH object and the QoS related objects from the QoS NSLP 1174 message and to craft the respective RADIUS or Diameter message. 1175 The message processing and object format is described in the 1176 respective RADIUS or Diameter QoS protocol, respectively. If the 1177 QNE is policy unaware then it ignores the policy data objects and 1178 continues processing the NSLP message. 1180 2. If the response from the PDP is negative the request must be 1181 rejected. A negative response in RADIUS is an Access-Reject and 1182 in Diameter is based on the 'DIAMETER_SUCCESS' value in the 1183 Result-Code AVP of the QoS-Authz-Answer (QAA) message. The QNE 1184 must construct and send a RESPONSE message with the status of 1185 authorization failure as specified in [I-D.ietf-nsis-qos-nslp]. 1187 3. Continue processing the NSIS message. 1189 6.2.3. Authorization (QNE or PDP) 1191 1. Retrieve the policy element from the SESSION_AUTH object. Check 1192 the AUTH_ENT_ID type and SubType fields and return an error if 1193 the identity type is not supported. 1195 2. Verify the message integrity. 1197 * Shared symmetric key authentication: The QNE or PDP uses the 1198 AUTH_ENT_ID field to consult a table keyed by that field. The 1199 table should identify the cryptographic authentication 1200 algorithm to be used along with the expected length of the 1201 authentication data and the shared symmetric key for the 1202 authorizing entity. Verify that the indicated length of the 1203 authentication data is consistent with the configured table 1204 entry and validate the authentication data. 1206 * Public Key: Validate the certificate chain against the trusted 1207 Certificate Authority (CA) and validate the message signature 1208 using the public key. 1210 * HMAC signed: The QNE or PDP uses the Key-ID field of the 1211 AUTHENTICATION_DATA attribute to consult a table keyed by that 1212 field. The table should identify the cryptographic 1213 authentication algorithm to be used along with the expected 1214 length of the authentication data and the shared symmetric key 1215 for the authorizing entity. Verify that the indicated length 1216 of the authentication data is consistent with the configured 1217 table entry and validate the integrity of parts of the NSLP 1218 message, i.e., session ID, MRI, NSLP ID and all other NSLP 1219 elements listed in the NSLP_OBJECT_LIST authentication data as 1220 well as the SESSION_AUTH object contents (cf. Section 6.4). 1222 * Kerberos: If AUTH_DATA contains an encapsulated KRB_CRED 1223 message (cf. Section 4.2), the integrity of the KRB_CRED 1224 message can be verified within Kerberos itself. Moreover, an 1225 additionally present SESSION_AUTH object using HMAC_SIGNED can 1226 be used to verify the message integrity as described above. 1228 3. Once the identity of the authorizing entity and the validity of 1229 the service request has been established, the authorizing router/ 1230 PDP MUST then consult its authorization policy in order to 1231 determine whether or not the specific request is authorized 1232 (e.g., based on available credits, information in the 1233 subscriber's database). To the extent to which these access 1234 control decisions require supplementary information, routers/PDPs 1235 MUST ensure that supplementary information is obtained securely. 1237 4. Verify the requested resources do not exceed the authorized QoS. 1239 6.2.4. Error Signaling 1241 When the PDP (e.g., a RADIUS or Diameter server) fails to verify the 1242 policy element then the appropriate actions described the respective 1243 AAA document need to be taken. 1245 The QNE node MUST return a RESPONSE message with the INFO_SPEC error 1246 code Authorization Failure as defined in the QoS NSLP specification. 1247 The QNE MAY include an INFO_SPEC Object Value Info to indicate which 1248 SESSION_AUTH attribute created the error. 1250 6.3. Processing with the NAT/FW NSLP 1252 This section presents processing rules for the NAT/FW NSLP 1253 [I-D.ietf-nsis-nslp-natfw]. 1255 6.3.1. Message Generation 1257 A NAT/FW NSLP message is created as specified in 1258 [I-D.ietf-nsis-nslp-natfw]. 1260 1. The policy element received from the authorizing entity MUST be 1261 copied without modification into the SESSION_AUTH object. 1263 2. The SESSION_AUTH object (containing the policy element) is 1264 inserted in the NATFW NSLP message in the appropriate place. 1266 6.3.2. Message Reception 1268 The NAT/FW NSLP message is processed as specified in 1269 [I-D.ietf-nsis-nslp-natfw] with following modifications. 1271 1. If the router is policy aware then it SHOULD use the Diameter 1272 application or the RADIUS protocol to communicate with the PDP. 1273 To construct the AAA message it is necessary to extract the 1274 SESSION_AUTH element and the NATFW policy rule related objects 1275 from the NSLP message and to craft the respective RADIUS or 1276 Diameter message. The message processing and object format is 1277 described in the respective RADIUS or Diameter protocols, 1278 respectively. If the router is policy unaware then it ignores 1279 the policy data objects and continues processing the NSLP 1280 message. 1282 2. Reject the message if the response from the PDP is negative. A 1283 negative response in RADIUS is an Access-Reject and in Diameter 1284 is based on the 'DIAMETER_SUCCESS' value in the Result-Code AVP. 1286 3. Continue processing the NSIS message. 1288 6.3.3. Authorization (Router/PDP) 1290 1. Retrieve the SESSION_AUTH object and the policy element. Check 1291 the PE type field and return an error if the identity type is not 1292 supported. 1294 2. Verify the message integrity. 1296 * Shared symmetric key authentication: The Network router/PDP 1297 uses the AUTH_ENT_ID field to consult a table keyed by that 1298 field. The table should identify the cryptographic 1299 authentication algorithm to be used along with the expected 1300 length of the authentication data and the shared symmetric key 1301 for the authorizing entity. Verify that the indicated length 1302 of the authentication data is consistent with the configured 1303 table entry and validate the authentication data. 1305 * Public Key: Validate the certificate chain against the trusted 1306 Certificate Authority (CA) and validate the message signature 1307 using the public key. 1309 * HMAC signed: The QNE or PDP uses the Key-ID field of the 1310 AUTHENTICATION_DATA attribute to consult a table keyed by that 1311 field. The table should identify the cryptographic 1312 authentication algorithm to be used along with the expected 1313 length of the authentication data and the shared symmetric key 1314 for the authorizing entity. Verify that the indicated length 1315 of the authentication data is consistent with the configured 1316 table entry and validate the integrity of parts of the NSLP 1317 message, i.e., session ID, MRI, NSLP ID and all other NSLP 1318 elements listed in the NSLP_OBJECT_LIST authentication data as 1319 well as the SESSION_AUTH object contents (cf. Section 6.4). 1321 * Kerberos: If AUTH_DATA contains an encapsulated KRB_CRED 1322 message (cf. Section 4.2), the integrity of the KRB_CRED 1323 message can be verified within Kerberos itself. Moreover, an 1324 additionally present SESSION_AUTH object using HMAC_SIGNED can 1325 be used to verify the message integrity as described above. 1327 3. Once the identity of the authorizing entity and the validity of 1328 the service request has been established, the authorizing router/ 1329 PDP MUST then consult its authorization policy in order to deter 1330 mine whether or not the specific request is authorized. To the 1331 extent to which these access control decisions require 1332 supplementary information, routers/PDPs MUST ensure that 1333 supplementary information is obtained securely. 1335 6.3.4. Error Signaling 1337 When the PDP (e.g., a RADIUS or Diameter server) fails to verify the 1338 SESSION_AUTH element then the appropriate actions described the 1339 respective AAA document need to be taken. The NATFW NSLP node MUST 1340 return an error message of class 'Permanent failure' (0x5) with error 1341 code 'Authorization failed' (0x02). 1343 6.4. Integrity Protection of NSLP messages 1345 The SESSION_AUTH object can also be used to provide an integrity 1346 protection for every NSLP signaling message, thereby also 1347 authenticating requests or responses. Assume that a user has 1348 deposited a shared key at some NN. This NN can then verify the 1349 integrity of every NSLP message sent by the user to the NN. Based on 1350 this authentication the NN can apply authorization policies to 1351 actions like resource reservations or opening of firewall pinholes. 1353 The sender of an NSLP message creates a SESSION_AUTH object that 1354 contains AUTH_ENT_ID attribute set to HMAC_SIGNED (cf. Section 4.4) 1355 and hashes with the shared key over all NSLP objects that need to be 1356 protected and lists them in the NSLP_OBJECT_LIST. The SESSION_AUTH 1357 object itself is also protected by the HMAC. By inclusion of the 1358 SESSION_AUTH object into the NSLP message, the receiver of this NSLP 1359 message can verify its integrity if it has the suitable shared key 1360 for the HMAC. Any response to the sender should also be protected by 1361 inclusion of a SESSION_AUTH object in order to prevent attackers 1362 sending unauthorized responses on behalf of the real NN. 1364 If a SESSION_AUTH object is present that has an AUTH_ENT_ID attribute 1365 set to HMAC_SIGNED, the integrity of all NSLP elements listed in the 1366 NSLP_OBJECT_LIST has to be checked, including the SESSION_AUTH object 1367 contents itself. Furthermore, session ID, MRI, and NSLP ID have to 1368 be included into the HMAC calculation, too, as specified in 1369 Section 3.2.7. The key that is used to calculate the HMAC is 1370 referred to by the Key ID included in the AUTH_DATA attribute. If 1371 the provided timestamp in START_TIME is not recent enough or the 1372 calculated HMAC differs from the one provided in AUTH_DATA the 1373 message must be discarded silently and an error should be logged 1374 locally. 1376 7. Security Considerations 1378 This document describes a mechanism for session authorization to 1379 prevent theft of service. There are three types of security issues 1380 to consider: protection against replay attacks, integrity of the 1381 SESSION_AUTH object, and the choice of the authentication algorithms 1382 and keys. 1384 The first issue, replay attacks, MUST be prevented. In the non- 1385 associated model, the SESSION_AUTH object MUST include a START_TIME 1386 field and the NNs as well as Policy Servers MUST support NTP to 1387 ensure proper clock synchronization. Failure to ensure proper clock 1388 synchronization will allow replay attacks since the clocks of the 1389 different network entities may not be in sync. The start time is 1390 used to verify that the request is not being replayed at a later 1391 time. In all other models, the SESSION_ID is used by the Policy 1392 Server to ensure that the resource request successfully correlates 1393 with records of an authorized session. If a SESSION_AUTH object is 1394 replayed, it MUST be detected by the policy server (using internal 1395 algorithms) and the request MUST be rejected. 1397 The second issue, the integrity of the policy element, is preserved 1398 in untrusted environments by including the AUTHENTICATION_DATA 1399 attribute in such environments. 1401 In environments where shared symmetric keys are possible, they should 1402 be used in order to keep the SESSION_AUTH policy element size to a 1403 strict minimum, e.g., when wireless links are used. A secondary 1404 option would be PKI authentication, which provides a high level of 1405 security and good scalability. However, it requires the presence of 1406 credentials in the SESSION_AUTH policy element which impacts its 1407 size. 1409 The SESSION_AUTH object can also serve to protect the integrity of 1410 NSLP message parts by using the HMAC_SIGNED Authentication Data as 1411 described in Section 6.4. 1413 When shared keys are used, e.g., in AUTHENTICATION_DATA Section 4.1 1414 or in conjunction with HMAC_SIGNED Section 4.4, it is important that 1415 the keys are kept secret, i.e., they must be exchanged, stored, and 1416 managed in a secure and confidential manner. If the key material is 1417 disclosed authentication and integrity protection are useless. 1419 Furthermore, security considerations for public key mechanisms using 1420 the X.509 certificate mechanisms described in [RFC5280] apply. 1421 Similarly, security considerations for PGP described in [RFC4880] 1422 apply. 1424 Further security issues are outlined in RFC 4081 [RFC4081]. 1426 8. IANA Considerations 1428 The SESSION_AUTH_OBJECT NSLP Message Object type is specified as: 1429 (IANA-TBD) 1431 [TO BE REMOVED: This specification makes the following request to 1432 IANA: Assign a new object value (SESSION_AUTH_OBJECT) for the 1433 SESSION_AUTH object from the shared NSLP Message Objects sub- 1434 registry: http://www.iana.org/assignments/nslp-parameters/ 1435 nslp-parameters.xhtml] 1437 This document specifies an 8-bit Session authorization attribute type 1438 (X-Type) field as well as 8-bit SubType fields per X-Type, for which 1439 IANA is to create and maintain corresponding sub-registries for the 1440 NSLP Session Authorization Object. 1442 Initial values for the X-Type registry are given below and the 1443 Registration Procedures according to [RFC5226] are specified as 1444 follows: 1446 Range Registration Procedures 1447 ----- --------------------------- 1448 0-127 Specification Required 1449 128-255 Private or Experimental Use 1451 X-Type Description 1452 -------- ------------------- 1453 0 Reserved 1454 1 AUTH_ENT_ID 1455 2 SESSION_ID 1456 3 SOURCE_ADDR 1457 4 DEST_ADDR 1458 5 START_TIME 1459 6 END_TIME 1460 7 NSLP_OBJECT_LIST 1461 8 AUTHENTICATION_DATA 1462 9-127 Unassigned 1463 128-255 Reserved 1465 In the following registration procedures and initial values for the 1466 SubType registries are specified. 1468 Sub-registry: AUTH_ENT_ID (X-Type 1) SubType values 1470 Range Registration Procedures 1471 ---------- ----------------------- 1472 0-127 Specification Required 1473 128-255 Private or Experimental Use 1475 Registry: 1476 SubType Description 1477 -------- ------------- 1478 0 Reserved 1479 1 IPV4_ADDRESS 1480 2 IPV6_ADDRESS 1481 3 FQDN 1482 4 ASCII_DN 1483 5 UNICODE_DN 1484 6 URI 1485 7 KRB_PRINCIPAL 1486 8 X509_V3_CERT 1487 9 PGP_CERT 1488 10 HMAC_SIGNED 1489 11-127 Unassigned 1490 128-255 Reserved 1492 Sub-registry: SOURCE_ADDR (X-Type 3) SubType values 1494 Range Registration Procedures 1495 ---------- ----------------------- 1496 0-127 Specification Required 1497 128-255 Private or Experimental Use 1499 Registry: 1500 SubType Description 1501 -------- ------------- 1502 0 Reserved 1503 1 IPV4_ADDRESS 1504 2 IPV6_ADDRESS 1505 3 UDP_PORT_LIST 1506 4 TCP_PORT_LIST 1507 5 SPI 1508 6-127 Unassigned 1509 128-255 Reserved 1511 Sub-registry: DEST_ADDR (X-Type 4) SubType values 1513 Range Registration Procedures 1514 ---------- ------------------------ 1515 0-127 Specification Required 1516 128-255 Private or Experimental Use 1517 Registry: 1518 0 Reserved 1519 1 IPV4_ADDRESS 1520 2 IPV6_ADDRESS 1521 3 UDP_PORT_LIST 1522 4 TCP_PORT_LIST 1523 5 SPI 1524 6-127 Unassigned 1525 128-255 Reserved 1527 Sub-registry: START_TIME (X-Type 5) SubType values 1529 Range Registration Procedures 1530 ---------- ----------------------- 1531 0-127 Specification Required 1532 128-255 Private or Experimental Use 1534 Registry: 1535 SubType Description 1536 -------- ------------- 1537 0 Reserved 1538 1 NTP_TIMESTAMP 1539 2-127 Unassigned 1540 128-255 Reserved 1542 Sub-registry: END_TIME (X-Type 6) SubType values 1544 Range Registration Procedures 1545 ---------- ----------------------- 1546 0-127 Specification Required 1547 128-255 Private or Experimental Use 1549 Registry: 1550 SubType Description 1551 -------- ------------- 1552 0 Reserved 1553 1 NTP_TIMESTAMP 1554 2-127 Unassigned 1555 128-255 Reserved 1557 9. Acknowledgments 1559 We would like to thank Xioaming Fu and Lars Eggert for provided 1560 reviews and comments. Helpful comments were also provided by Gen-ART 1561 reviewer Ben Campbell as well as Sean Turner and Tim Polk from the 1562 Security Area. This document is largely based on the RFC 3520 1563 [RFC3520] and credit therefore goes to the authors of RFC 3520, 1564 namely Louis-Nicolas Hamer, Brett Kosinski, Bill Gage and Hugh Shieh. 1565 Part of this work was funded by Deutsche Telekom Laboratories within 1566 the context of the ScaleNet project. 1568 10. References 1570 10.1. Normative References 1572 [I-D.ietf-nsis-nslp-natfw] 1573 Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, 1574 "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 1575 draft-ietf-nsis-nslp-natfw-25 (work in progress), 1576 April 2010. 1578 [I-D.ietf-nsis-ntlp] 1579 Schulzrinne, H. and M. Stiemerling, "GIST: General 1580 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 1581 (work in progress), June 2009. 1583 [I-D.ietf-nsis-qos-nslp] 1584 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 1585 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 1586 (work in progress), January 2010. 1588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1589 Requirement Levels", BCP 14, RFC 2119, March 1997. 1591 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1592 Standards (PKCS) #1: RSA Cryptography Specifications 1593 Version 2.1", RFC 3447, February 2003. 1595 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1596 RFC 4306, December 2005. 1598 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1599 Time Protocol Version 4: Protocol and Algorithms 1600 Specification", RFC 5905, June 2010. 1602 10.2. Informative References 1604 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1605 STD 13, RFC 1034, November 1987. 1607 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1608 Hashing for Message Authentication", RFC 2104, 1609 February 1997. 1611 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 1612 "Session Authorization Policy Element", RFC 3520, 1613 April 2003. 1615 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 1616 Session Set-up with Media Authorization", RFC 3521, 1617 April 2003. 1619 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1620 Resource Identifier (URI): Generic Syntax", STD 66, 1621 RFC 3986, January 2005. 1623 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1624 Bosch, "Next Steps in Signaling (NSIS): Framework", 1625 RFC 4080, June 2005. 1627 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1628 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1630 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1631 Kerberos Network Authentication Service (V5)", RFC 4120, 1632 July 2005. 1634 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 1635 (LDAP): String Representation of Distinguished Names", 1636 RFC 4514, June 2006. 1638 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1639 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1641 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1642 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1644 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1645 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1646 May 2008. 1648 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1649 Housley, R., and W. Polk, "Internet X.509 Public Key 1650 Infrastructure Certificate and Certificate Revocation List 1651 (CRL) Profile", RFC 5280, May 2008. 1653 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1654 RFC 5652, September 2009. 1656 Appendix A. Changes 1658 [Note to the RFC Editor: this appendix to be removed before 1659 publication as an RFC.] 1661 This section describes changes between draft versions. 1663 -00: based on draft-manner-nsis-nslp-auth-04 1665 * removed extensibility flag handling directives as the NSLPs are 1666 responsible 1668 * added IANA-TBD flag and SESSION_AUTH_OBJ 1670 * changed Kerberos section 1672 * removed calling/called party 1674 * updated text in IANA section: removed "This specification uses 1675 two X-types introduced by RFC3520: Session_ID and Resources." 1676 as it may worry IANA (no action required) 1678 * other small additions and fixes 1680 * Updated Jukka's contact info 1682 -01: 1684 * addressed Xiaoming's comments of 2010-02-17 1685 http://www.ietf.org/mail-archive/web/nsis/current/msg08726.html 1687 * removed resource reservation specific text and used them as 1688 examples 1690 * removed referral to checksum and used MAC instead 1692 * specified action if AUTH_ENT_ID or sub type are not known 1694 * added missing _ in AUTH_SESSION 1696 -02: 1698 * changed intended category to experimental, because other NSIS 1699 protocols are now in this category. 1701 * added text in Section 4.2 for Kerberos usage 1703 * added more references to quoted RFCs 1705 * moved Changes to Appendix 1707 -03: 1709 * Incorporated Lars Eggert's comments from AD review. 1711 * added SESSION_ID to 3.2 with some clarifying text 1713 * removed RESOURCES from section 5.4 since it is not directly 1714 applicable in the NSIS context 1716 -04: 1718 * Updated references to new RFC 5905 (NTP), RFC 4880 (OpenPGP 1719 Message Format), RFC 5280 (PKIX Certificate and CRL Profile) 1721 * changed IPR to trust200902 1723 -05: 1725 * Replaced one remnant of RFC 2440 by RFC 4880 1727 -06: 1729 * Added a registry description in IANA Considerations section 8 1731 * Relabeled AUTH_SESSION to SESSION_AUTH to better match the 1732 verbose name of the object and to distinguish from RFC 3520 1734 * added description for SESSION_ID (new sec. 3.2.2) 1736 * removed a superfluous sentence in NSLP_OBJECT_LIST definition 1737 (former sec. 3.2.6) 1739 * fixed a typo in figure 1 (was NTLP_OBJ_LIST) 1741 * added clarification sentences for HMAC_SIGNED in sections 6.4 1742 and 7 1744 -07: 1746 * Addressed comments of Gen-ART review by Ben Campell: 1748 + clarified order requirements on NSLP object list and 1749 computing the hash 1751 + changed required minimum Hash implementation from HMAC-MD5 1752 to HMAC-SHA2-256 1754 + clarified Section 6.4, 1st paragraph authentication vs. 1755 authorization 1757 + removed MUST in Section 7, 3rd paragraph 1758 (AUTHENTICATION_DATA is not always required) 1760 * Addressed comments of Sean Turners review: 1762 + added Hash Signed and Kerberos usage to Sections 6.2.3, 2. 1763 and 6.3.3, 2. 1765 + added security considerations for symmetric and public keys 1767 + capitalized some occurrences of MUST and RECOMMENDED 1769 + added figure for SESSION_AUTH object with X509_V3_CERT 1771 + added figure numbers for SESSION_AUTH object examples in 1772 section 4 1774 * many editorial nits 1776 Authors' Addresses 1778 Jukka Manner 1779 Aalto University 1780 P.O. Box 13000 1781 Aalto FI-00076 1782 Finland 1784 Phone: +358 9 470 22481 1785 Email: jukka.manner@tkk.fi 1787 Martin Stiemerling 1788 Network Laboratories, NEC Europe Ltd. 1789 Kurfuersten-Anlage 36 1790 Heidelberg 69115 1791 Germany 1793 Phone: +49 (0) 6221 4342 113 1794 Email: stiemerling@nw.neclab.eu 1795 URI: http://www.stiemerling.org 1797 Hannes Tschofenig 1798 Nokia Siemens Networks 1799 Linnoitustie 6 1800 Espoo 02600 1801 Finland 1803 Phone: +358 (50) 4871445 1804 Email: Hannes.Tschofenig@gmx.net 1805 URI: http://www.tschofenig.priv.at 1807 Roland Bless (editor) 1808 Karlsruhe Institute of Technology 1809 Institute of Telematics 1810 Zirkel 2, Building 20.20 1811 P.O. Box 6980 1812 Karlsruhe 76049 1813 Germany 1815 Phone: +49 721 608 6413 1816 Email: roland.bless@kit.edu 1817 URI: http://tm.kit.edu/~bless