idnits 2.17.1 draft-manner-nsis-nslp-auth-03.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1154. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1165. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1172. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1178. 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 (March 3, 2007) is 6235 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) == Missing Reference: 'QoS NSLP' is mentioned on line 878, but not defined == Missing Reference: 'QOS NSLP' is mentioned on line 860, but not defined == Missing Reference: 'NATFW NSLP' is mentioned on line 943, but not defined == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-13 ** 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-12 ** 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-12 ** 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) ** Downref: Normative reference to an Informational RFC: RFC 4080 ** Downref: Normative reference to an Informational RFC: RFC 4081 -- Obsolete informational reference (is this intentional?): RFC 3852 (Obsoleted by RFC 5652) Summary: 7 errors (**), 0 flaws (~~), 7 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: September 4, 2007 NEC 6 H. Tschofenig 7 Siemens Networks GmbH & Co KG 8 March 3, 2007 10 Authorization for NSIS Signaling Layer Protocols 11 draft-manner-nsis-nslp-auth-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 4, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 Signaling layer protocols in the NSIS working group may rely on GIST 45 to handle authorization. Still, the signaling layer protocol itself 46 may require separate authorization to be performed when a node 47 receives a request for a certain kind of service or resources. This 48 draft presents a generic model and object formats for session 49 authorization within the NSIS Signaling Layer Protocols. The goal of 50 session authorization is to allow the exchange of information between 51 network elements in order to authorize the use of resources for a 52 service and to coordinate actions between the signaling and transport 53 planes. 55 Table of Contents 57 1. Conventions used in this document . . . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Session Authorization Object . . . . . . . . . . . . . . . . . 6 60 3.1. Session Authorization Object format . . . . . . . . . . . 6 61 3.2. Session Authorization Attributes . . . . . . . . . . . . . 7 62 3.2.1. Authorizing Entity Identifier . . . . . . . . . . . . 8 63 3.2.2. Source Address . . . . . . . . . . . . . . . . . . . . 9 64 3.2.3. Destination Address . . . . . . . . . . . . . . . . . 11 65 3.2.4. Start time . . . . . . . . . . . . . . . . . . . . . . 12 66 3.2.5. End time . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.2.6. Authentication data . . . . . . . . . . . . . . . . . 13 68 4. Integrity of the AUTH_SESSION policy element . . . . . . . . . 15 69 4.1. Shared symmetric keys . . . . . . . . . . . . . . . . . . 15 70 4.1.1. Operational Setting using shared symmetric keys . . . 15 71 4.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 4.3. Public Key . . . . . . . . . . . . . . . . . . . . . . . . 16 73 4.3.1. Operational Setting for public key based 74 authentication . . . . . . . . . . . . . . . . . . . . 16 75 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.1. The Coupled Model . . . . . . . . . . . . . . . . . . . . 19 77 5.2. The associated model with one policy server . . . . . . . 19 78 5.3. The associated model with two policy servers . . . . . . . 20 79 5.4. The non-associated model . . . . . . . . . . . . . . . . . 20 80 6. Message Processing Rules . . . . . . . . . . . . . . . . . . . 21 81 6.1. Generation of the AUTH_SESSION by the authorizing 82 entity . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 6.2. Processing within the QoS NSLP . . . . . . . . . . . . . . 21 84 6.2.1. Message Generation . . . . . . . . . . . . . . . . . . 21 85 6.2.2. Message Reception . . . . . . . . . . . . . . . . . . 22 86 6.2.3. Authorization (QNE/PDP) . . . . . . . . . . . . . . . 22 87 6.2.4. Error Signaling . . . . . . . . . . . . . . . . . . . 23 88 6.3. Processing with the NAT/FW NSLP . . . . . . . . . . . . . 23 89 6.3.1. Message Generation . . . . . . . . . . . . . . . . . . 23 90 6.3.2. Message Reception . . . . . . . . . . . . . . . . . . 23 91 6.3.3. Authorization (Router/PDP) . . . . . . . . . . . . . . 24 92 6.3.4. Error Signaling . . . . . . . . . . . . . . . . . . . 24 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 97 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 98 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 100 Intellectual Property and Copyright Statements . . . . . . . . . . 32 102 1. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in BCP 14, RFC 2119 107 [RFC2119]. 109 The term "NSLP node" (NN) is used to refer to an NSIS node running an 110 NSLP protocol that can make use of the authorization object discussed 111 in this document. Currently, this node would run either the QoS or 112 the NAT/FW NSLP service. 114 2. Introduction 116 The NSIS working group is specifying a suite of protocols for the 117 next generation in Internet signaling [RFC4080]. The design is based 118 on a generalized transport protocol for signaling applications, the 119 General Internet Signaling Transport (GIST) [I-D.ietf-nsis-ntlp], and 120 various kinds of signaling applications. Two signaling applications 121 and their NSIS Signaling Layer Protocols (NSLP) have been designed, a 122 Quality of Service application (QoS NSLP) [I-D.ietf-nsis-qos-nslp] 123 and a NAT/firewall application (NAT/FW) [I-D.ietf-nsis-nslp-natfw]. 125 The security architecture is based on a chain-of-trust model, where 126 each GIST hop may chose the appropriate security protocol, taking 127 into account the signaling application requirements. This model is 128 appropriate for a number of different use cases, and allows the 129 signaling applications to leave the handling of security to GIST. 131 Yet, in order to allow for finer-grain per-session admission control, 132 it is necessary to provide a mechanism for ensuring that the use of 133 resources by a host has been properly authorized before allowing the 134 signaling application to commit the resource request, e.g., a QoS 135 reservation or mappings for NAT traversal. In order to meet this 136 requirement,there must be information in the NSLP message which may 137 be used to verify the validity of the request. This can be done by 138 providing the host with a session authorization policy element which 139 is inserted into the message and verified by the network. 141 This document describes a generic NSLP layer session authorization 142 policy object (AUTH_SESSION) used to convey authorization information 143 for the request. The scheme is based on third-party tokens. A 144 trusted third party provides authentication tokens to clients and 145 allows verification of the information by the network elements. The 146 requesting host inserts its authorization information acquired from 147 the trusted third party into the NSLP message to allow verification 148 of the network resource request. Network elements verify the request 149 and then process the resource reservation message based on admission 150 policy. This work is based on RFC 3520 [RFC3520] and RFC 3521 151 [RFC3521]. 153 The default operation of the authorization is to add one 154 authorization policy object. Yet, in order to support end-to-end 155 signaling and request authorization from different networks, a host 156 initiating an NSLP signaling session may add more than one 157 AUTH_SESSION object in the message. The identifier of the 158 authorizing entity can be used by the network elements to use the 159 third party they trust to verify the request. 161 3. Session Authorization Object 163 This section presents a new NSLP layer object called session 164 authorization (AUTH_SESSION). The AUTH_SESSION object can be used in 165 the currently specified and future NSLP protocols. 167 The authorization attributes follow the format and specification 168 given in RFC3520 [RFC3520]. 170 3.1. Session Authorization Object format 172 The AUTH_SESSION object contains a list of fields which describe the 173 session, along with other attributes. The object header follows the 174 generic NSLP object header. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 |A|B|r|r| Type |r|r|r|r| Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 + + 182 // Session Authorization Attribute List // 183 + + 184 +---------------------------------------------------------------+ 186 The value for the Type field comes from shared NSLP object type 187 space. The Length field is given in units of 32 bit words and 188 measures the length of the Value component of the TLV object (i.e. it 189 does not include the standard header). 191 The bits marked 'A' and 'B' are extensibility flags, and used to 192 signal the desired treatment for objects whose treatment has not been 193 defined in the protocol specification (i.e. whose Type field is 194 unknown at the receiver). The following four categories of object 195 have been identified, and are described here. 197 AB=00 ("Mandatory"): If the object is not understood, the entire 198 message containing it MUST be rejected with a "Object Type Error" 199 message with subcode 1 ("Unrecognised Object"). In the NATFW NSLP 200 case it MUST be rejected with an error response of class 'Protocol 201 error' (0x3) with error code 'Unknown object present' (0x06). 203 AB=01 ("Ignore"): If the object is not understood, it MUST be deleted 204 and the rest of the message processed as usual. 206 AB=10 ("Forward"): If the object is not understood, it MUST be 207 retained unchanged in any message forwarded as a result of message 208 processing, but not stored locally. 210 AB=11 ("Refresh"): If the object is not understood, it should be 211 incorporated into the locally stored signaling application state for 212 this flow/session, forwarded in any resulting message, and also used 213 in any refresh or repair message which is generated locally. In the 214 NATFW NSLP this combination AB=11 MUST NOT be used and an error 215 response of class 'Protocol error' (0x3) with error code 'Invalid 216 Flag-Field combination' (0x09) MUST be generated. 218 The remaining bits marked 'r' are reserved. The extensibility flags 219 follow the definition in the GIST specification. The AUTH_SESSION 220 object defines in this specification MUST have the AB-bits set to 221 "10". An NN may use the authorization information if it is 222 configured to do so, but may also just skip the object. 224 Type: 0x0a (TBD by IANA) 226 Length: Variable 228 Session Authorization Attribute List: variable length 230 The session authorization attribute list is a collection of 231 objects which describes the session and provides other information 232 necessary to verify the resource reservation request. An initial 233 set of valid objects is described in Section 3.2. 235 3.2. Session Authorization Attributes 237 A session authorization attribute may contain a variety of 238 information and has both an attribute type and subtype. The 239 attribute itself MUST be a multiple of 4 octets in length, and any 240 attributes that are not a multiple of 4 octets long MUST be padded to 241 a 4-octet boundary. All padding bytes MUST have a value of zero. 243 +--------+--------+--------+--------+ 244 | Length | X-Type |SubType | 245 +--------+--------+--------+--------+ 246 | Value ... 247 +--------+--------+--------+--------+ 249 Length: 16 bits 251 The length field is two octets and indicates the actual length of 252 the attribute (including Length, X-Type and SubType fields) in 253 number of octets. The length does NOT include any bytes padding 254 to the value field to make the attribute a multiple of 4 octets 255 long. 257 X-Type: 8 bits 259 Session authorization attribute type (X-Type) field is one octet. 260 IANA acts as a registry for X-Types as described in Section 7, 261 IANA Considerations. Initially, the registry contains the 262 following X-Types: 264 1. AUTH_ENT_ID The unique identifier of the entity which authorized 265 the session. 267 2. SOURCE_ADDR Address specification for the session originator. 269 3. DEST_ADDR Address specification for the session end-point. 271 4. START_TIME The starting time for the session. 273 5. END_TIME The end time for the session. 275 6. AUTHENTICATION_DATA Authentication data of the session 276 authorization policy element. 278 SubType: 8 bits 280 Session authorization attribute sub-type is one octet in length. 281 The value of the SubType depends on the X-Type. 283 Value: variable length 285 The attribute specific information. 287 3.2.1. Authorizing Entity Identifier 289 AUTH_ENT_ID is used to identify the entity which authorized the 290 initial service request and generated the session authorization 291 policy element. The AUTH_ENT_ID may be represented in various 292 formats, and the SubType is used to define the format for the ID. 293 The format for AUTH_ENT_ID is as follows: 295 +-------+-------+-------+-------+ 296 | Length |X-Type |SubType| 297 +-------+-------+-------+-------+ 298 | OctetString ... 299 +-------+-------+-------+-------+ 301 Length: Length of the attribute, which MUST be > 4. 303 X-Type: AUTH_ENT_ID 305 SubType: 307 The following sub-types for AUTH_ENT_ID are defined. IANA acts as 308 a registry for AUTH_ENT_ID sub-types as described in Section 7, 309 IANA Considerations. Initially, the registry contains the 310 following sub-types of AUTH_ENT_ID: 312 1. IPV4_ADDRESS IPv4 address represented in 32 bits 314 2. IPV6_ADDRESS IPv6 address represented in 128 bits 316 3. FQDN Fully Qualified Domain Name as defined in RFC 1034 as an 317 ASCII string. 319 4. ASCII_DN X.500 Distinguished name as defined in RFC 2253 as an 320 ASCII string. 322 5. UNICODE_DN X.500 Distinguished name as defined in RFC 2253 as a 323 UTF-8 string. 325 6. URI Universal Resource Identifier, as defined in RFC 2396. 327 7. KRB_PRINCIPAL Fully Qualified Kerberos Principal name represented 328 by the ASCII string of a principal followed by the @ realm name 329 as defined in RFC 1510 (e.g., johndoe@nowhere). 331 8. X509_V3_CERT The Distinguished Name of the subject of the 332 certificate as defined in RFC 2253 as a UTF-8 string. 334 9. PGP_CERT The PGP digital certificate of the authorizing entity as 335 defined in RFC 2440. 337 OctetString: Contains the authorizing entity identifier. 339 3.2.2. Source Address 341 SOURCE_ADDR is used to identify the source address specification of 342 the authorized session. This X-Type may be useful in some scenarios 343 to make sure the resource request has been authorized for that 344 particular source address and/or port. 346 +-------+-------+-------+-------+ 347 | Length |X-Type |SubType| 348 +-------+-------+-------+-------+ 349 | OctetString ... 350 +-------+-------+-------+-------+ 352 Length: Length of the attribute, which MUST be > 4. 354 X-Type: SOURCE_ADDR 356 SubType: 358 The following sub types for SOURCE_ADDR are defined. IANA acts as 359 a registry for SOURCE_ADDR sub-types as described in Section 7, 360 IANA Considerations. Initially, the registry contains the 361 following sub types for SOURCE_ADDR: 363 1. IPV4_ADDRESS IPv4 address represented in 32 bits 365 2. IPV6_ADDRESS IPv6 address represented in 128 bits 367 3. UDP_PORT_LIST list of UDP port specifications, represented as 16 368 bits per list entry. 370 4. TCP_PORT_LIST list of TCP port specifications, represented as 16 371 bits per list entry. 373 5. SPI Security Parameter Index represented in 32 bits 375 OctetString: The OctetString contains the source address information. 377 In scenarios where a source address is required (see Section 5), at 378 least one of the subtypes 1 or 2 MUST be included in every Session 379 Authorization Data Policy Element. Multiple SOURCE_ADDR attributes 380 MAY be included if multiple addresses have been authorized. The 381 source address of the request (e.g., a QoS NSLP RESERVE) MUST match 382 one of the SOURCE_ADDR attributes contained in this Session 383 Authorization Data Policy Element. 385 At most, one instance of subtype 3 MAY be included in every Session 386 Authorization Data Policy Element. At most, one instance of subtype 387 4 MAY be included in every Session Authorization Data Policy Element. 388 Inclusion of a subtype 3 attribute does not prevent inclusion of a 389 subtype 4 attribute (i.e., both UDP and TCP ports may be authorized). 391 If no PORT attributes are specified, then all ports are considered 392 valid; otherwise, only the specified ports are authorized for use. 394 Every source address and port list must be included in a separate 395 SOURCE_ADDR attribute. 397 3.2.3. Destination Address 399 DEST_ADDR is used to identify the destination address of the 400 authorized session. This X-Type may be useful in some scenarios to 401 make sure the resource request has been authorized for that 402 particular destination address and/or port. 404 +-------+-------+-------+-------+ 405 | Length |X-Type |SubType| 406 +-------+-------+-------+-------+ 407 | OctetString ... 408 +-------+-------+-------+-------+ 410 Length: Length of the attribute, which MUST be > 4. 412 X-Type: DEST_ADDR 414 SubType: 416 The following sub types for DEST_ADDR are defined. IANA acts as a 417 registry for DEST_ADDR sub-types as described in Section 7, IANA 418 Considerations. Initially, the registry contains the following 419 sub types for DEST_ADDR: 421 1. IPV4_ADDRESS IPv4 address represented in 32 bits 423 2. IPV6_ADDRESS IPv6 address represented in 128 bits 425 3. UDP_PORT_LIST list of UDP port specifications, represented as 16 426 bits per list entry. 428 4. TCP_PORT_LIST list of TCP port specifications, represented as 16 429 bits per list entry. 431 5. SPI Security Parameter Index represented in 32 bits 433 OctetString: The OctetString contains the destination address 434 specification. 436 In scenarios where a destination address is required (see Section 5), 437 at least one of the subtypes 1 or 2 MUST be included in every Session 438 Authorization Data Policy Element. Multiple DEST_ADDR attributes MAY 439 be included if multiple addresses have been authorized. The 440 destination address field of the resource reservation datagram (e.g., 441 RSVP PATH) MUST match one of the DEST_ADDR attributes contained in 442 this Session Authorization Data Policy Element. 444 At most, one instance of subtype 3 MAY be included in every Session 445 Authorization Data Policy Element. At most, one instance of subtype 446 4 MAY be included in every Session Authorization Data Policy Element. 447 Inclusion of a subtype 3 attribute does not prevent inclusion of a 448 subtype 4 attribute (i.e., both UDP and TCP ports may be authorized). 450 If no PORT attributes are specified, then all ports are considered 451 valid; otherwise, only the specified ports are authorized for use. 453 Every destination address and port list must be included in a 454 separate DEST_ADDR attribute. 456 3.2.4. Start time 458 START_TIME is used to identify the start time of the authorized 459 session and can be used to prevent replay attacks. If the 460 AUTH_SESSION policy element is presented in a resource request, the 461 network SHOULD reject the request if it is not received within a few 462 seconds of the start time specified. 464 +-------+-------+-------+-------+ 465 | Length |X-Type |SubType| 466 +-------+-------+-------+-------+ 467 | OctetString ... 468 +-------+-------+-------+-------+ 470 Length: Length of the attribute, which MUST be > 4. 472 X-Type: START_TIME 474 SubType: 476 The following sub types for START_TIME are defined. IANA acts as a 477 registry for START_TIME sub-types as described in Section 7, IANA 478 Considerations. Initially, the registry contains the following sub 479 types for START_TIME: 481 1. 1 NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305. 483 OctetString: The OctetString contains the start time. 485 3.2.5. End time 487 END_TIME is used to identify the end time of the authorized session 488 and can be used to limit the amount of time that resources are 489 authorized for use (e.g., in prepaid session scenarios). 491 +-------+-------+-------+-------+ 492 | Length |X-Type |SubType| 493 +-------+-------+-------+-------+ 494 | OctetString ... 495 +-------+-------+-------+-------+ 497 Length: Length of the attribute, which MUST be > 4. 499 X-Type: END_TIME 501 SubType: 503 The following sub types for END_TIME are defined. IANA acts as a 504 registry for END_TIME sub-types as described in Section 7, IANA 505 Considerations. Initially, the registry contains the following sub 506 types for END_TIME: 508 1. NTP_TIMESTAMP NTP Timestamp Format as defined in RFC 1305. 510 OctetString: The OctetString contains the end time. 512 3.2.6. Authentication data 514 The AUTHENTICATION_DATA attribute contains the authentication data of 515 the AUTH_SESSION policy element and signs all the data in the policy 516 element up to the AUTHENTICATION_DATA. If the AUTHENTICATION_DATA 517 attribute has been included in the AUTH_SESSION policy element, it 518 MUST be the last attribute in the list. The algorithm used to 519 compute the authentication data depends on the AUTH_ENT_ID SubType 520 field. See Section 4 entitled Integrity of the AUTH_SESSION policy 521 element. 523 A summary of AUTHENTICATION_DATA attribute format is described below. 525 +-------+-------+-------+-------+ 526 | Length |X-Type |SubType| 527 +-------+-------+-------+-------+ 528 | OctetString ... 529 +-------+-------+-------+-------+ 531 Length: Length of the attribute, which MUST be > 4. 533 X-Type: AUTHENTICATION_DATA 535 SubType: No sub types for AUTHENTICATION_DATA are currently defined. 536 This field MUST be set to 0. 538 OctetString: The OctetString contains the authentication data of the 539 AUTH_SESSION. 541 4. Integrity of the AUTH_SESSION policy element 543 This section describes how to ensure the integrity of the policy 544 element is preserved. 546 4.1. Shared symmetric keys 548 In shared symmetric key environments, the AUTH_ENT_ID MUST be of 549 subtypes: IPV4_ADDRESS, IPV6_ADDRESS, FQDN, ASCII_DN, UNICODE_DN or 550 URI. An example AUTH_SESSION object is shown below. 552 +--------------+--------------+--------------+--------------+ 553 |1000| Type = AUTH_SESSION |0000| Object length | 554 +--------------+--------------+--------------+--------------+ 555 | Length | AUTH_ENT_ID | IPV4_ADDRESS | 556 +--------------+--------------+--------------+--------------+ 557 | OctetString (The authorizing entity's Identifier) | 558 +--------------+--------------+--------------+--------------+ 559 | Length |AUTH DATA. | zero | 560 +--------------+--------------+--------------+--------------+ 561 | KEY_ID | 562 +--------------+--------------+--------------+--------------+ 563 | OctetString (Authentication data) ... 564 +--------------+--------------+--------------+--------------+ 566 4.1.1. Operational Setting using shared symmetric keys 568 This assumes both the Authorizing Entity and the Network router/PDP 569 are provisioned with shared symmetric keys and with policies 570 detailing which algorithm to be used for computing the authentication 571 data along with the expected length of the authentication data for 572 that particular algorithm. 574 Key maintenance is outside the scope of this document, but 575 AUTH_SESSION implementations MUST at least provide the ability to 576 manually configure keys and their parameters. The key used to 577 produce the authentication data is identified by the AUTH_ENT_ID 578 field. Since multiple keys may be configured for a particular 579 AUTH_ENT_ID value, the first 32 bits of the AUTH_DATA field MUST be a 580 key ID to be used to identify the appropriate key. Each key must 581 also be configured with lifetime parameters for the time period 582 within which it is valid as well as an associated cryptographic 583 algorithm parameter specifying the algorithm to be used with the key. 584 At a minimum, all AUTH_SESSION implementations MUST support the HMAC- 585 MD5-128 [RFC1321] [RFC2104] cryptographic algorithm for computing the 586 authentication data. 588 It is good practice to regularly change keys. Keys MUST be 589 configurable such that their lifetimes overlap allowing smooth 590 transitions between keys. At the midpoint of the lifetime overlap 591 between two keys, senders should transition from using the current 592 key to the next/longer-lived key. Meanwhile, receivers simply accept 593 any identified key received within its configured lifetime and reject 594 those that are not. 596 4.2. Kerberos 598 RFC 3520 provides a mechanism to secure the authorization token using 599 Kerberos. Kerberos, however, has not seen deployment in this context 600 and is not well applicable for this particular usage scenario. 601 Hence, Kerberos support will not be provided by this specification. 603 4.3. Public Key 605 In a public key environment, the AUTH_ENT_ID MUST be of the subtypes: 606 X509_V3_CERT or PGP_CERT. The authentication data is used for 607 authenticating the authorizing entity. An example of the public key 608 AUTH_SESSION policy element is shown below. 610 +--------------+--------------+--------------+--------------+ 611 |1000| Type = AUTH_SESSION |0000| Object length | 612 +--------------+--------------+--------------+--------------+ 613 | Length | AUTH_ENT_ID | PGP_CERT | 614 +--------------+--------------+--------------+--------------+ 615 | OctetString (Authorizing entity Digital Certificate) ... 616 +--------------+--------------+--------------+--------------+ 617 | Length |AUTH DATA. | zero | 618 +--------------+--------------+--------------+--------------+ 619 | OctetString (Authentication data) ... 620 +--------------+--------------+--------------+--------------+ 622 4.3.1. Operational Setting for public key based authentication 624 Public key based authentication assumes the following: 626 o Authorizing entities have a pair of keys (private key and public 627 key). 629 o Private key is secured with the authorizing entity. 631 o Public keys are stored in digital certificates and a trusted 632 party, certificate authority (CA) issues these digital 633 certificates. 635 o The verifier (PDP or router) has the ability to verify the digital 636 certificate. 638 Authorizing entity uses its private key to generate 639 AUTHENTICATION_DATA. Authenticators (router, PDP) use the 640 authorizing entity's public key (stored in the digital certificate) 641 to verify and authenticate the policy element. 643 4.3.1.1. X.509 V3 digital certificates 645 When the AUTH_ENT_ID is of type X509_V3_CERT, AUTHENTICATION_DATA 646 MUST be generated following these steps: 648 o A Signed-data is constructed as defined in RFC3852 [RFC3852] . A 649 digest is computed on the content (as specified in Section 6.1) 650 with a signer-specific message-digest algorithm. The certificates 651 field contains the chain of authorizing entity's X.509 V3 digital 652 certificates. The certificate revocation list is defined in the 653 crls field. The digest output is digitally signed following 654 Section 8 of RFC 3447 [RFC3447], using the signer's private key. 656 When the AUTH_ENT_ID is of type X509_V3_CERT, verification MUST be 657 done following these steps: 659 o Parse the X.509 V3 certificate to extract the distinguished name 660 of the issuer of the certificate. 662 o Certification Path Validation is performed as defined in Section 6 663 of RFC 3280. 665 o Parse through the Certificate Revocation list to verify that the 666 received certificate is not listed. 668 o Once the X.509 V3 certificate is validated, the public key of the 669 authorizing entity can be extracted from the certificate. 671 o Extract the digest algorithm and the length of the digested data 672 by parsing the CMS signed-data. 674 o The recipient independently computes the message digest. This 675 message digest and the signer's public key are used to verify the 676 signature value. 678 This verification ensures integrity, non-repudiation and data origin. 680 4.3.1.2. PGP digital certificates 682 When the AUTH_ENT_ID is of type PGP_CERT, AUTHENTICATION_DATA MUST be 683 generated following these steps: 685 o AUTHENTICATION_DATA contains a Signature Packet as defined in 686 Section 5.2.3 of RFC 2440. In summary: 688 o Compute the hash of all data in the AUTH_SESSION policy element up 689 to the AUTHENTICATION_DATA. 691 o The hash output is digitally signed following Section 8 of RFC 692 3447, using the signer's private key. 694 When the AUTH_ENT_ID is of type PGP_CERT, verification MUST be done 695 following these steps: 697 o Validate the certificate. 699 o Once the PGP certificate is validated, the public key of the 700 authorizing entity can be extracted from the certificate. 702 o Extract the hash algorithm and the length of the hashed data by 703 parsing the PGP signature packet. 705 o The recipient independently computes the message digest. This 706 message digest and the signer's public key are used to verify the 707 signature value. 709 This verification ensures integrity, non-repudiation and data origin. 711 5. Framework 713 RFC3521 [RFC3521] describes a framework in which the AUTH_SESSION 714 policy element may be utilized to transport information required for 715 authorizing resource reservation for media flows. RFC3521 introduces 716 4 different models: 718 1. The coupled model 720 2. The associated model with one policy server 722 3. The associated model with two policy servers 724 4. The non-associated model. 726 The fields that are required in an AUTH SESSION policy element 727 dependent on which of the models is used. 729 5.1. The Coupled Model 731 In the coupled model, the only information that MUST be included in 732 the policy element is the SESSION_ID; it is used by the Authorizing 733 Entity to correlate the resource reservation request with the media 734 authorized during session set up. Since the End Host is assumed to 735 be untrusted, the Policy Server SHOULD take measures to ensure that 736 the integrity of the SESSION_ID is preserved in transit; the exact 737 mechanisms to be used and the format of the SESSION_ID are 738 implementation dependent. 740 5.2. The associated model with one policy server 742 In this model, the contents of the AUTH_SESSION policy element MUST 743 include: 745 o A session identifier - SESSION_ID. This is information that the 746 authorizing entity can use to correlate the resource request with 747 the media authorized during session set up. 749 o The identity of the authorizing entity - AUTH_ENT_ID. This 750 information is used by an NN to determine which authorizing entity 751 (Policy Server) should be used to solicit resource policy 752 decisions. 754 In some environments, an NN may have no means for determining if the 755 identity refers to a legitimate Policy Server within its domain. In 756 order to protect against redirection of authorization requests to a 757 bogus authorizing entity, the AUTH_SESSION MUST also include: 759 AUTHENTICATION_DATA. This authentication data is calculated over 760 all other fields of the AUTH_SESSION policy element. 762 5.3. The associated model with two policy servers 764 The content of the AUTH_SESSION Policy Element is identical to the 765 associated model with one policy server. 767 5.4. The non-associated model 769 In this model, the AUTH_SESSION MUST contain sufficient information 770 to allow the Policy Server to make resource policy decisions 771 autonomously from the authorizing entity. The policy element is 772 created using information about the session by the authorizing 773 entity. The information in the AUTH_SESSION policy element MUST 774 include: 776 o Calling party IP address or Identity (e.g., FQDN) - SOURCE_ADDR 777 X-TYPE 779 o Called party IP address or Identity (e.g., FQDN) - DEST_ADDR 780 X-TYPE 782 o The characteristics of (each of) the media stream(s) authorized 783 for this session - RESOURCES X-TYPE 785 o The authorization lifetime - START_TIME X-TYPE 787 o The identity of the authorizing entity to allow for validation of 788 the token in shared symmetric key and Kerberos schemes - 789 AUTH_ENT_ID X-TYPE 791 o The credentials of the authorizing entity in a public-key scheme - 792 AUTH_ENT_ID X-TYPE 794 o Authentication data used to prevent tampering with the 795 AUTH_SESSION policy element - AUTHENTICATION_DATA 797 Furthermore, the AUTH_SESSION policy element MAY contain: 799 o The lifetime of (each of) the media stream(s) - END_TIME X-TYPE 801 o Calling party port number - SOURCE_ADDR X-TYPE 803 o Called party port number - DEST_ADDR X-TYPE 805 All AUTH_SESSION fields MUST match with the resource request. If a 806 field does not match, the request SHOULD be denied. 808 6. Message Processing Rules 810 This section discusses the message processing related to the 811 AUTH_SESSION object. We describe the details of the QoS NSLP and 812 NAT/FW NSLP. New NSLP protocols should use the same logic in making 813 use of the AUTH_SESSION object. 815 6.1. Generation of the AUTH_SESSION by the authorizing entity 817 1. Generate the AUTH_SESSION policy element with the appropriate 818 contents as specified in Section 5. 820 2. If authentication is needed, the entire AUTH_SESSION policy 821 element is constructed, excluding the length, type and subtype 822 fields of the AUTH_SESSION field. Note that the message MUST 823 include either a START_TIME or a SESSION_ID (See Section 9), to 824 prevent replay attacks. The output of the authentication 825 algorithm, plus appropriate header information, is appended to 826 the AUTH_SESSION policy element. 828 6.2. Processing within the QoS NSLP 830 The AUTH_SESSION object may be used with QoS NSLP QUERY and RESERVE 831 messages to authorize the query operation for network resources, and 832 a resource reservation request, respectively. 834 Moreover, the AUTH_SESSION object may also be used with RESPONSE 835 messages in order to indicate that the authorizing entity changed the 836 original request. For example, the session start or end times may 837 have been modified, or the client may have requested authorization 838 for all ports, but the authorizing entity only allowed the use of 839 certain ports. 841 If the QoS NSIS Initiator (QNI) receives a RESPONSE message with an 842 AUTH_SESSION object, the QNI MUST inspect the AUTH_SESSION object to 843 see what authentication attribute was changed by an authorizing 844 entity. The QNI SHOULD also silently accept AUTH_SESSION objects in 845 RESPONSE message which do not indicate any change to the original 846 authorization request. 848 6.2.1. Message Generation 850 A QoS NSLP message is created as specified in [QoS NSLP]. 852 1. The policy element received from the authorizing entity MUST be 853 copied without modification into the AUTH_SESSION object. 855 2. The AUTH_SESSION object (containing the policy element) is 856 inserted in the NSLP message in the appropriate place. 858 6.2.2. Message Reception 860 The QoS NSLP message is processed as specified in [QOS NSLP] with 861 following modifications. 863 1. If the QNE is policy aware then it SHOULD use the Diameter QoS 864 application or the RADIUS QoS protocol to communicate with the 865 PDP. To construct the AAA message it is necessary to extract the 866 AUTH_SESSION object and the QoS related objects from the QoS NSLP 867 message and to craft the respective RADIUS or Diameter message. 868 The message processing and object format is described in the 869 respective RADIUS or Diameter QoS protocol, respectively. If the 870 QNE is policy unaware then it ignores the policy data objects and 871 continues processing the NSLP message. 873 2. If the response from the PDP is negative the request must be 874 rejected. A negative response in RADIUS is an Access-Reject and 875 in Diameter is based on the 'DIAMETER_SUCCESS' value in the 876 Result-Code AVP of the QoS-Authz-Answer (QAA) message. The QNE 877 must contruct and send a RESPONSE message with the status of 878 authorization failure as specified in [QoS NSLP]. 880 3. Continue processing the NSIS message. 882 6.2.3. Authorization (QNE/PDP) 884 1. Retrieve the policy element from the AUTH_SESSION object. Check 885 the PE type field and return an error if the identity type is not 886 supported. 888 2. Verify the message integrity. 890 * Shared symmetric key authentication: The QNE/PDP uses the 891 AUTH_ENT_ID field to consult a table keyed by that field. The 892 table should identify the cryptographic authentication 893 algorithm to be used along with the expected length of the 894 authentication data and the shared symmetric key for the 895 authorizing entity. Verify that the indicated length of the 896 authentication data is consistent with the configured table 897 entry and validate the authentication data. 899 * Public Key: Validate the certificate chain against the trusted 900 Certificate Authority (CA) and validate the message signature 901 using the public key. 903 * Kerberos based usage is not provided by this document. 905 3. Once the identity of the authorizing entity and the validity of 906 the service request has been established, the authorizing router/ 907 PDP MUST then consult its authorization policy in order to 908 determine whether or not the specific request is authorized 909 (e.g., based on available credits, information in the 910 subscriber's database). To the extent to which these access 911 control decisions require supplementary information, routers/PDPs 912 MUST ensure that supplementary information is obtained securely. 914 4. Verify the requested resources do not exceed the authorized QoS. 916 6.2.4. Error Signaling 918 When the PDP (e.g., a RADIUS or Diameter server) fails to verify the 919 policy element then the appropriate actions described the respective 920 AAA document need to be taken. 922 The QNE node MUST return a RESPONSE message with the INFO_SPEC error 923 code Authorization Failure as defined in the QoS NSLP specification. 924 The QNE MAY include an INFO_SPEC Object Value Info to indicate which 925 AUTH_SESSION attribute created the error. 927 6.3. Processing with the NAT/FW NSLP 929 This section presents processing tules for the NAT/FW NSLP. 931 6.3.1. Message Generation 933 A NAT/FW NSLP message is created as specified in [NATFW NSLP]. 935 1. The policy element received from the authorizing entity MUST be 936 copied without modification into the AUTH_SESSION object. 938 2. The AUTH_SESSION object (containing the policy element) is 939 inserted in the NATFW NSLP message in the appropriate place. 941 6.3.2. Message Reception 943 The NAT/FW NSLP message is processed as specified in [NATFW NSLP] 944 with following modifications. 946 1. If the router is policy aware then it SHOULD use the Diameter 947 application or the RADIUS protocol to communicate with the PDP. 948 To construct the AAA message it is necessary to extract the 949 AUTH_SESSION element and the NATFW policy rule related objects 950 from the NSLP message and to craft the respective RADIUS or 951 Diameter message. The message processing and object format is 952 described in the respective RADIUS or Diameter protocols, 953 respectively. If the router is policy unaware then it ignores 954 the policy data objects and continues processing the NSLP 955 message. 957 2. Reject the message if the response from the PDP is negative. A 958 negative response in RADIUS is an Access-Reject and in Diameter 959 is based on the 'DIAMETER_SUCCESS' value in the Result-Code AVP. 961 3. Continue processing the NSIS message. 963 6.3.3. Authorization (Router/PDP) 965 1. Retrieve the AUTH_SESSION object and the policy element. Check 966 the PE type field and return an error if the identity type is not 967 supported. 969 2. Verify the message integrity. 971 * Shared symmetric key authentication: The Network router/PDP 972 uses the AUTH_ENT_ID field to consult a table keyed by that 973 field. The table should identify the cryptographic 974 authentication algorithm to be used along with the expected 975 length of the authentication data and the shared symmetric key 976 for the authorizing entity. Verify that the indicated length 977 of the authentication data is consistent with the configured 978 table entry and validate the authentication data. 980 * Public Key: Validate the certificate chain against the trusted 981 Certificate Authority (CA) and validate the message signature 982 using the public key. 984 * - Kerberos based usage is not provided by this document. 986 3. Once the identity of the authorizing entity and the validity of 987 the service request has been established, the authorizing router/ 988 PDP MUST then consult its authorization policy in order to deter 989 mine whether or not the specific request is authorized. To the 990 extent to which these access control decisions require 991 supplementary information, routers/PDPs MUST ensure that 992 supplementary information is obtained securely. 994 6.3.4. Error Signaling 996 When the PDP (e.g., a RADIUS or Diameter server) fails to verify the 997 AUTH_SESSION element then the appropriate actions described the 998 respective AAA document need to be taken. The NATFW NSLP node MUST 999 return an error message of class 'Permanent failure' (0x5) with error 1000 code 'Authorization failed' (0x02). 1002 7. Security Considerations 1004 This document describes a mechanism for session authorization to 1005 prevent theft of service. There are three types of security issues 1006 to consider: protectiong against replay attacks, integrity of the 1007 AUTH_SESSION object, and the choice of the authentication algorithms 1008 and keys. 1010 The first issue, replay attacks, MUST be prevented. In the non- 1011 associated model, the AUTH_SESSION object MUST include a START_TIME 1012 field and the Policy Servers MUST support NTP to ensure proper clock 1013 synchronization. Failure to ensure proper clock synchronization will 1014 allow replay attacks since the clocks of the different network 1015 entities may not be in synch. The start time is used to verify that 1016 the request is not being replayed at a later time. In all other 1017 models, the SESSION_ID is used by the Policy Server to ensure that 1018 the resource request successfully correlates with records of an 1019 authorized session. If a AUTH_SESSION object is replayed, it MUST be 1020 detected by the policy server (using internal algorithms) and the 1021 request MUST be rejected. 1023 The second issue, the integrity of the policy element, is preserved 1024 in untrusted environments by including the AUTHENTICATION_DATA 1025 attribute. Therefore, this attribute MUST always be included. 1027 In environments where shared symmetric keys are possible, they should 1028 be used in order to keep the AUTH_SESSION policy element size to a 1029 strict minimum, e.g., when wireless links are used. A secondary 1030 option would be PKI authentication, which provides a high level of 1031 security and good scalability. However, it requires the presence of 1032 credentials in the AUTH_SESSION policy element which impacts its 1033 size. 1035 Further security issues are outlined in RFC 4081 [RFC4081]. 1037 8. IANA Considerations 1039 This specification makes the following request to IANA: 1041 1. Assign a new object value for the AUTH_SESSION object from the 1042 shared NSLP object value space. 1044 2. All AUTH_SESSION object internal values and numbers should be 1045 taken from the allocations already done for RFC 3520 [RFC3520]. 1046 Yet, this specification does make use of two X-types introduced 1047 by RFC3520: Session ID and Resources. 1049 9. Acknowledgements 1051 This document is based on the RFC 3520 [RFC3520] and credit therefore 1052 goes to the authors of RFC 3520, namely Louis-Nicolas Hamer, Brett 1053 Kosinski, Bill Gage and Hugh Shieh. 1055 10. References 1057 10.1. Normative References 1059 [I-D.ietf-nsis-nslp-natfw] 1060 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 1061 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-13 (work in 1062 progress), October 2006. 1064 [I-D.ietf-nsis-ntlp] 1065 Schulzrinne, H. and R. Hancock, "GIST: General Internet 1066 Signalling Transport", draft-ietf-nsis-ntlp-12 (work in 1067 progress), March 2007. 1069 [I-D.ietf-nsis-qos-nslp] 1070 Manner, J., "NSLP for Quality-of-Service Signaling", 1071 draft-ietf-nsis-qos-nslp-12 (work in progress), 1072 October 2006. 1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1075 Requirement Levels", BCP 14, RFC 2119, March 1997. 1077 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1078 Standards (PKCS) #1: RSA Cryptography Specifications 1079 Version 2.1", RFC 3447, February 2003. 1081 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1082 Bosch, "Next Steps in Signaling (NSIS): Framework", 1083 RFC 4080, June 2005. 1085 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1086 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1088 10.2. Informative References 1090 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1091 April 1992. 1093 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1094 Hashing for Message Authentication", RFC 2104, 1095 February 1997. 1097 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 1098 "Session Authorization Policy Element", RFC 3520, 1099 April 2003. 1101 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 1102 Session Set-up with Media Authorization", RFC 3521, 1103 April 2003. 1105 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 1106 RFC 3852, July 2004. 1108 Authors' Addresses 1110 Jukka Manner 1111 Helsinki University of Technology (TKK) 1112 P.O. Box 5400 1113 Espoo FIN-02015 TKK 1114 Finland 1116 Phone: +358 9 451 4161 1117 Email: jmanner@tml.hut.fi 1118 URI: http://www.tml.tkk.fi/~jmanner/ 1120 Martin Stiemerling 1121 Network Laboratories, NEC Europe Ltd. 1122 Kurfuersten-Anlage 36 1123 Heidelberg 69115 1124 Germany 1126 Phone: +49 (0) 6221 4342 113 1127 Email: stiemerling@netlab.nec.de 1128 URI: http://www.stiemerling.org 1130 Hannes Tschofenig 1131 Siemens Networks GmbH & Co KG 1132 Otto-Hahn-Ring 6 1133 Munich, Bavaria 81739 1134 Germany 1136 Phone: +49 89 636 40390 1137 Email: Hannes.Tschofenig@siemens.com 1138 URI: http://www.tschofenig.com 1140 Full Copyright Statement 1142 Copyright (C) The IETF Trust (2007). 1144 This document is subject to the rights, licenses and restrictions 1145 contained in BCP 78, and except as set forth therein, the authors 1146 retain all their rights. 1148 This document and the information contained herein are provided on an 1149 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1150 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1151 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1152 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1153 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1154 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1156 Intellectual Property 1158 The IETF takes no position regarding the validity or scope of any 1159 Intellectual Property Rights or other rights that might be claimed to 1160 pertain to the implementation or use of the technology described in 1161 this document or the extent to which any license under such rights 1162 might or might not be available; nor does it represent that it has 1163 made any independent effort to identify any such rights. Information 1164 on the procedures with respect to rights in RFC documents can be 1165 found in BCP 78 and BCP 79. 1167 Copies of IPR disclosures made to the IETF Secretariat and any 1168 assurances of licenses to be made available, or the result of an 1169 attempt made to obtain a general license or permission for the use of 1170 such proprietary rights by implementers or users of this 1171 specification can be obtained from the IETF on-line IPR repository at 1172 http://www.ietf.org/ipr. 1174 The IETF invites any interested party to bring to its attention any 1175 copyrights, patents or patent applications, or other proprietary 1176 rights that may cover technology that may be required to implement 1177 this standard. Please address the information to the IETF at 1178 ietf-ipr@ietf.org. 1180 Acknowledgment 1182 Funding for the RFC Editor function is provided by the IETF 1183 Administrative Support Activity (IASA).