idnits 2.17.1 draft-ietf-rap-rsvp-authsession-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 15) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([POL-EXT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (April 2001) is 8384 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) -- Looks like a reference, but probably isn't: '1' on line 15 == Missing Reference: 'RFC-2119' is mentioned on line 59, but not defined == Missing Reference: 'RFC 2104' is mentioned on line 525, but not defined == Unused Reference: 'ASCII' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'POL-FRAME' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC-1305' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC-1510' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC-1779' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC-2209' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'RFC-2327' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC-2396' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC-2474' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 700, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ietf-rap-rsvp-newidentity-01 -- Possible downref: Normative reference to a draft: ref. 'S-AUTH' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'POL-FRAME') ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 1633 ** Obsolete normative reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 2209 ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational RFC: RFC 2998 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 14 errors (**), 0 flaws (~~), 16 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RAP Working Group L-N. Hamer 2 Internet Draft B. Kosinski 3 Expires September 31, 2001 B. Gage 4 Nortel Networks 5 April 2001 7 Session Authorization for RSVP 9 draft-ietf-rap-rsvp-authsession-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet- Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 The distribution of this memo is unlimited. This memo is filed as 30 , and expires September 31, 31 2001. Please send comments to the authors. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This document describes the representation of session authorization 40 information in the POLICY_DATA object [POL-EXT] for supporting 41 policy-based per-session authorization and admission control in 42 RSVP. The goal of session authorization is to allow the exchange 43 of information between network elements in order to authorize the 44 use of resources for a service and to co-ordinate actions between 45 the signaling and transport planes. This document describes how a 46 process on a system authorizes the reservation of resources by a 47 host and then provides that host with a session authorization 48 policy element which can be inserted into the RSVP PATH message to 49 facilitate proper and secure reservation of those resources within 50 the network. We describe the encoding of media authorization 51 information as RSVP policy elements and provide details relating to 52 operations, processing rules and error scenarios. 54 1. Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC-2119]. 60 2. Introduction 62 RSVP [RFC-2205] is a resource reservation setup protocol designed 63 for an integrated services [RFC-1633] or DiffEdge [RFC-2998] 64 Internet. The RSVP protocol is used by a host to request specific 65 qualities of service from the network for particular application 66 data streams or flows. RSVP is also used by routers to deliver 67 quality-of-service (QoS) requests to all nodes along the path(s) of 68 the flows and to establish and maintain state to provide the 69 requested service. RSVP requests will generally result in 70 resources being reserved in each node along the data path. RSVP 71 allows users to obtain preferential access to network resources, 72 under the control of an admission control mechanism. Such 73 admission control is often based on user or application identity 74 [I-REP], however, it is also valuable to provide the ability for 75 per-session admission control. 77 In order to allow for per-session admission control, it is necessary 78 to provide a mechanism for ensuring an RSVP request from a host has 79 been properly pre-authorized before allowing the reservation of 80 resources. In order to meet this requirement, there must be 81 information in the RSVP message which may be used to verify the 82 validity of the RSVP request. This may be done by providing the host 83 with a token upon authorization which may be inserted into the RSVP 84 PATH message and verified by the network. 86 We describe the session authorization element (AUTH_SESSION) 87 contained in the POLICY_DATA object. The user process must obtain an 88 AUTH_SESSION object from an authorizing entity, which it may then 89 pass to the RSVP process (service) on the originating host. The RSVP 90 service then inserts the AUTH_SESSION object into the RSVP PATH 91 message to allow verification of the network resource request. 92 Network elements, such as routers, verify the request and then admit 93 the RSVP message based on admission policy. 95 [S-AUTH] describes a framework in which a session authorization 96 policy element may be utilized to contain information relevant to 97 the network's decision to grant a reservation request. 99 3. Policy Element for Session Authorization Data 101 3.1 Policy Data Object Format 103 POLICY_DATA objects contain policy information and are carried by 104 RSVP messages. A detail description of the format of POLICY_DATA 105 object can be found in "RSVP Extensions for Policy Control" [POL- 106 EXT]. 108 3.2 Session Authorization Data Policy Element 110 In this section we describe a policy element (PE) called session 111 authorization data (AUTH_SESSION). The AUTH_SESSION policy element 112 contains a list of fields which describe the session, along with 113 other attributes. 115 +-------------+-------------+-------------+-------------+ 116 | Length | P-Type = AUTH_SESSION | 117 +-------------+-------------+-------------+-------------+ 118 // Session Authorization Attribute List // 119 +-------------------------------------------------------+ 121 Length 122 The length of the policy element (including the Length and 123 P-Type) is in number of octets (MUST be in multiples of 4) and 124 indicates the end of the session authorization information 125 block. 127 P-Type (Session Authorization Type) 128 The Policy element type (P-type) of this element. The 129 Internet Assigned Numbers Authority (IANA) acts as a registry 130 for policy element types for identity as described in 131 [POL-EXT]. The definition for AUTH_SESSION is currently to be 132 defined. 134 Session Authorization Attribute List 135 The session authorization attribute list is a collection of 136 objects which describes the session and provides other 137 information necessary to verify the RSVP request. 139 3.3 Session Authorization Attributes 141 A session authorization attribute may contain a variety of 142 information and has both an attribute type and subtype. The 143 attribute itself MUST be a multiple of 4 octets in length, and any 144 attributes that are not a multiple of 4 octets long MUST be padded 145 to a 4-octet boundary. 147 +--------+--------+--------+--------+ 148 | Length | S-Type |SubType | 149 +--------+--------+--------+--------+ 150 | Value ... 151 +--------+--------+--------+--------+ 153 Length 154 The length field is two octets and indicates the actual length 155 of the attribute (including Length, S-Type and SubType fields) 156 in number of octets. The length does NOT include any bytes 157 padding to the value field to make the attribute a multiple of 158 4 octets long. 160 S-Type 161 Session authorization attribute type (S-Type) field is one 162 octet. IANA SHALL act as a registry for S-Types as described 163 in section 7, IANA Considerations. Initially, the registry 164 contains the following S-Types: 166 1 AUTH_ENT_ID The unique identifier of the entity 167 which authorized the session. 169 2 AUTH_ENT_CRED The credentials of the authorizing 170 entity, such as a digital 171 certificate. 173 3 SESSION_ID Unique identifier for this session. 175 4 SOURCE_ADDR Address specification for the 176 session originator. 178 5 DEST_ADDR Address specification for the 179 session end-point. 181 6 START_TIME The starting time for the session. 183 7 END_TIME The end time for the session. 185 8 RESOURCES The resources which the user is 186 authorized to request. 188 9 DIGITAL_SIGNATURE Digital signature of the session 189 authorization policy element. 191 SubType 192 Session authorization attribute sub-type is one octet in 193 length. The value of the SubType depends on the S-Type. 195 Value 196 The attribute specific information. 198 3.3.1 Authorizing Entity Identifier 200 AUTH_ENT_ID is used to identify the entity which authorized the 201 initial service request and generated the session authorization 202 policy element. The AUTH_ENT_ID may be represented in various 203 formats, and the SubType is used to define the format for the ID. 204 The format for AUTH_ENT_ID is as follows: 206 +-------+-------+-------+-------+ 207 | Length |S-Type |SubType| 208 +-------+-------+-------+-------+ 209 | OctetString ... 210 +-------+-------+-------+-------+ 212 Length 213 Length of the attribute, which MUST be >= 4. 215 S-Type 216 AUTH_ENT_ID 218 SubType 219 The following sub-types for AUTH_ENT_ID are defined. IANA 220 SHALL act as a registry for AUTH_ENT_ID sub-types as described 221 in section 7, IANA Considerations. Initially, the registry 222 contains the following sub-types of AUTH_ENT_ID: 224 1 IPV4_ADDRESS IPv4 address 226 2 IPV6_ADDRESS IPv6 address 228 3 FQDN Fully Qualified Domain Name 230 4 ASCII_DN X.500 Distinguished name as defined 231 in RFC-1779 as an ASCII string. 233 5 UNICODE_DN X.500 Distinguished name as defined 234 in RFC-1779 as a UNICODE string. 236 6 URI Universal Resource Identifier, as 237 defined in RFC-2396. 239 7 KRB_PRINCIPAL Kerberos principal name as defined in 240 RFC-1510. 242 OctetString 243 Contains the authorizing entity identifier. 245 3.3.2 Authorizing Entity Credentials 247 AUTH_ENT_CRED contains the credentials of the authorizing entity, 248 which can then be used by the network to ensure that the entity 249 which generated this session authorization policy element is a 250 valid trusted entity. 252 +-------+-------+-------+-------+ 253 | Length |S-Type |SubType| 254 +-------+-------+-------+-------+ 255 | OctetString ... 256 +-------+-------+-------+-------+ 258 Length 259 Length of the attribute, which MUST be >= 4. 261 S-Type 262 AUTH_ENT_CRED 264 SubType 265 The type of credentials contained in this attribute. IANA 266 SHALL act as a registry for AUTH_ENT_CRED sub-types as 267 described in section 7, IANA Considerations. Initially, the 268 registry contains the following sub-types: 270 1 ASCII_ID The authorizing entity identification in a 271 plain ASCII text string. 273 2 UNICODE_ID The authorizing entity identification in a 274 plain UNICODE text string. 276 3 X509_V3_CERT A chain of authorizing entity's X.509 V3 277 digital certificates. 279 4 PGP_CERT The PGP digital certificate of the 280 authorizing entity. 282 OctetString 283 Contains the authorizing entity credentials. 285 3.3.3 Session Identifier 287 SESSION_ID is a unique identifier for this session. It may be used 288 for a number of purposes, including replay detection, or even 289 mapping this request to a policy decision entry made by the 290 authorizing entity. 292 +-------+-------+-------+-------+ 293 | Length |S-Type |SubType| 294 +-------+-------+-------+-------+ 295 | OctetString ... 296 +-------+-------+-------+-------+ 297 Length 298 Length of the attribute, which MUST be >= 4. 300 S-Type 301 SESSION_ID 303 SubType 304 The following sub-types for SESSION_ID are defined. IANA 305 SHALL act as a registry for SESSION_ID sub-types as described 306 in section 7, IANA Considerations. Initially, the registry 307 contains the following sub-types of SESSION_ID: 309 1 ASCII_ID Simple plain ASCII string identifier. 311 2 UNICODE_ID Simple plain UNICODE string identifier. 313 3 OCTET_ID Raw octet string identifier. 315 OctetString 316 Contains the actual session identifier. 318 3.3.4 Source Address 320 SOURCE_ADDR is used to identify the source address specification of 321 the authorized session. This S-Type MAY be useful in some scenarios 322 to make sure the resource request has been authorized for that 323 particular source IP address and/or port. 325 +-------+-------+-------+-------+ 326 | Length |S-Type |SubType| 327 +-------+-------+-------+-------+ 328 | OctetString ... 329 +-------+-------+-------+-------+ 331 Length 332 Length of the attribute, which MUST be >= 4. 334 S-Type 335 SOURCE_ADDR 337 SubType 338 The following sub types for SOURCE_ADDR are defined. IANA 339 SHALL act as a registry for SOURCE_ADDR sub-types as 340 described in section 7, IANA Considerations. Initially, the 341 registry contains the following sub types for SOURCE_ADDR: 343 1 IPV4_ADDRESS IPv4 address 345 2 IPV6_ADDRESS IPv6 address 346 3 UDP_PORT UDP port specification 348 4 TCP_PORT TCP port specification 350 OctetString 351 The OctetString contains the source address information. 353 3.3.5 Destination Address 355 DEST_ADDR is used to identify the destination address of the 356 authorized session. This S-Type MAY be useful in some scenarios to 357 make sure the resource request has been authorized for that 358 particular destination IP address and/or port. 360 +-------+-------+-------+-------+ 361 | Length |S-Type |SubType| 362 +-------+-------+-------+-------+ 363 | OctetString ... 364 +-------+-------+-------+-------+ 366 Length 367 Length of the attribute, which MUST be >= 4. 369 S-Type 370 DEST_ADDR 372 SubType 373 The following sub types for DEST_ADDR are defined. IANA SHALL 374 act as a registry for DEST_ADDR sub-types as described in 375 section 7, IANA Considerations. Initially, the registry 376 contains the following sub types for DEST_ADDR: 378 1 IPV4_ADDRESS IPv4 address 380 2 IPV6_ADDRESS IPv6 address 382 3 UDP_PORT UDP port specification 384 4 TCP_PORT TCP port specification 386 OctetString 387 The OctetString contains the destination address specification. 389 3.3.6 Start time 391 START_TIME is used to identify the start time of the authorized 392 session. This S-Type MAY be useful in some scenarios to specify a 393 start time for the authorized session. 395 +-------+-------+-------+-------+ 396 | Length |S-Type |SubType| 397 +-------+-------+-------+-------+ 398 | OctetString ... 399 +-------+-------+-------+-------+ 401 Length 402 Length of the attribute, which MUST be >= 4. 404 S-Type 405 START_TIME 407 SubType 408 The following sub types for START_TIME are defined. IANA SHALL 409 act as a registry for START_TIME sub-types as described in 410 section 7, IANA Considerations. Initially, the registry 411 contains the following sub types for START_TIME: 413 1 NTP_TIMESTAMP NTP Timestamp Format as defined in 414 RFC-1305. 416 OctetString 417 The OctetString contains the start time. 419 3.3.7 End time 421 END_TIME is used to identify the end time of the authorized 422 session. This S-Type MAY be useful in some scenarios to specify a 423 end time for the authorized session. 425 +-------+-------+-------+-------+ 426 | Length |S-Type |SubType| 427 +-------+-------+-------+-------+ 428 | OctetString ... 429 +-------+-------+-------+-------+ 431 Length 432 Length of the attribute, which MUST be >= 4. 434 S-Type 435 END_TIME 437 SubType 438 The following sub types for END_TIME are defined. IANA SHALL 439 act as a registry for END_TIME sub-types as described in 440 section 7, IANA Considerations. Initially, the registry 441 contains the following sub types for END_TIME: 443 1 NTP_TIMESTAMP NTP Timestamp Format as defined in 444 RFC-1305. 446 OctetString 447 The OctetString contains the end time. 449 3.3.8 Resources Authorized 451 RESOURCES is used to define the characteristics of the authorized 452 session. This S-Type MAY be useful in some scenarios to specify the 453 specific resources authorized to ensure the request fits the 454 authorized specifications. 456 +-------+-------+-------+-------+ 457 | Length |S-Type |SubType| 458 +-------+-------+-------+-------+ 459 | OctetString ... 460 +-------+-------+-------+-------+ 462 Length 463 Length of the attribute, which MUST be >= 4. 465 S-Type 466 RESOURCES 468 SubType 469 The following sub-types for RESOURCES are defined. IANA SHALL 470 act as a registry for RESOURCES sub-types as described in 471 section 7, IANA Considerations. Initially, the registry 472 contains the following sub types for RESOURCES: 474 1 BANDWIDTH Maximum bandwidth (kbps) authorized. 476 2 FLOW_SPEC Flow spec specification as defined in 477 RFC-2205. 479 3 SDP SDP Media Descriptor as defined in 480 RFC-2327. 482 4 DSCP Differentiated services codepoint as 483 defined in RFC-2474. 485 OctetString 486 The OctetString contains the resources specification. 488 3.3.9 Digital Signature 490 The DIGITAL_SIGNATURE attribute contains the digital signature of 491 the AUTH_SESSION policy element and signs all the data in the 492 policy element up to the DIGITAL_SIGNATURE. If the 493 DIGITAL_SIGNATURE attribute has been included in the AUTH_SESSION 494 policy element, it MUST be the last attribute in the list. 496 A summary of DIGITAL_SIGNATURE attribute format is described below. 498 +-------+-------+-------+-------+ 499 | Length |S-Type |SubType| 500 +-------+-------+-------+-------+ 501 | OctetString ... 502 +-------+-------+-------+-------+ 504 Length 505 Length of the attribute, which MUST be >= 4. 507 S-Type 508 DIGITAL_SIGNATURE 510 SubType 511 The following sub-types for DIGITAL_SIGNATURE are 512 defined. IANA SHALL act as a registry for DIGITAL_SIGNATURE 513 sub-types as described in section 7, IANA 514 Considerations. Initially, the registry contains the following 515 sub types for DIGITAL_SIGNATURE: 517 1 DSA_SHA1 DSA signature using SHA1 [X.509]. 519 2 RSA_SHA1 RSA signature using SHA1 [X.509]. 521 3 RSA_MD5 RSA signature using MD5 [X.509]. 523 4 HMAC_SHA1 HMAC with SHA1 [RFC 2104]. 525 5 HMAC_MD5 HMAC with MD5 [RFC 2104]. 527 OctetString 528 OctetString contains the digital signature of the AUTH_SESSION. 530 4. Framework 532 [S-AUTH] describes a framework in which the session authorization 533 policy element may be utilized to transport information for use in 534 authorizing resource reservation for media flows. 536 5. Message Processing Rules 538 5.1 Message Generation (RSVP Host) 540 An RSVP message is created as specified in [RFC-2205] with following 541 modifications. 543 1. RSVP message MUST contain at most one AUTH_SESSION policy element. 545 2. A Session Authorization policy element (AUTH_SESSION) is created 546 and the IdentityType field is set to indicate the identity type 547 in the policy element. Only the required Session Authorization 548 attributes are added. 550 3. POLICY_DATA object (containing the AUTH_SESSION policy element) 551 is inserted in the RSVP message in the appropriate place. 553 5.2 Message Reception (Router) 555 RSVP message is processed as specified in [RFC-2205] with following 556 modifications. 558 1. If router is policy aware then it SHOULD send the RSVP 559 message to the PDP and wait for response. If the router is 560 policy unaware then it ignores the policy data objects and 561 continues processing the RSVP message. 563 2. Reject the message if the response from the PDP is negative. 565 3. Continue processing the RSVP message. 567 5.3 Authorization (Router/PDP) 569 1. Retrieve the AUTH_SESSION policy element. Check the PE type 570 field and return an error if the identity type is not supported. 572 2. Verify the authorizing entity credentials and message integrity. 574 - Pre-shared key authentication: Get entity ID, identify 575 appropriate pre-shared key for the authorizing entity, and 576 validate signature. 578 - Public Key: Validate the certificate chain against 579 trusted Certificate Authority (CA) and valide the 580 message signature using the public key. 582 - Kerberos Ticket: Request a ticket for the authorizing entity 583 from the local KDC. Use the ticket to access the authorizing 584 entity and obtain authentication data for the message (e.g. 585 the signing key) or the data itself. 587 3. Verify the requested QoS does not exceed the authorized QoS. 589 6. Error Signaling 591 If PDP fails to verify the AUTH_SESSION policy element then it MUST 592 return policy control failure (Error Code = 02) to the PEP. The 593 error values are described in [RFC-2205] and [POL-EXT]. Also PDP 594 SHOULD supply a policy data object containing an AUTH_DATA 595 Policy Element with A-Type=POLICY_ERROR_CODE containing more 596 details on the Policy Control failure [I-REP]. The PEP 597 will include this Policy Data object in the outgoing RSVP Error 598 message. 600 7. IANA Considerations 602 Following the policies outlined in [IANA-CONSIDERATIONS], session 603 authorization attribute types (S-Type)in the range 0-127 are 604 allocated through an IETF Consensus action, S-Type values between 605 128-255 are reserved for Private Use and are not assigned by IANA. 607 Following the policies outlined in [IANA-CONSIDERATIONS], 608 AUTH_ENT_ID, AUTH_ENT_CRED, SESSION_ID, START_TIME, STOP_TIME, 609 SOURCE_IP, DEST_IP, RESOURCES and DIGITAL_SIGNATURE SubType values 610 in the range 0-127 are allocated through an IETF Consensus action, 611 SubType values between 128-255 are reserved for Private Use and are 612 not assigned by IANA. 614 8. Security Considerations 616 The purpose of this draft is to describe a mechanism for media 617 authorization to prevent theft of service. It does not cover other 618 possible security breaches such as IP spoofing. 620 9. Acknowledgments 622 We would like to thank Francois Audet, Don Wade, Hamid Syed, Matt 623 Broda, and many others for their valuable comments. 625 In addition, we would like to thank S. Yadav, et al, for their 626 efforts on RFC 2752, as this document borrows heavily from their 627 work. 629 10. References 631 [I-REP] S. Yadav et al, "Identity Representation for 632 RSVP", Internet-draft, 633 draft-ietf-rap-rsvp-newidentity-01.txt, 634 January 2000 636 [S-AUTH] Hamer, L-N. and Gage, B, "Framework for 637 session setup with media authorization", 638 Internet-Draft, 639 draft-hamer-rap-session-auth-00.txt, 640 February 2001. 642 [ASCII] Coded Character Set -- 7-Bit American Standard 643 Code for Information Interchange, ANSI X3.4- 644 1986. 646 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 647 Writing an IANA Considerations Section in 648 RFCs", BCP 26, RFC 2434, October 1998. 650 [POL-EXT] Herzog, S., "RSVP Extensions for Policy 651 Control", RFC 2750, January 2000. 653 [POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A 654 Framework for Policy-based Admission Control 655 RSVP", RFC 2753, January 2000. 657 [RFC-1305] Mills, David L., "Network Time Protocol 658 (Version 3) Specification, Implementation, and 659 Analysis", RFC 1305, March 1992. 661 [RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network 662 Authentication Service (V5)", RFC 1510, 663 September 1993. 665 [RFC-1633] Braden, R., Clark, D., Shenker, S., 666 "Integrated Services in the Internet 667 Architecture: An Overview", RFC 1633, 668 June 1994. 670 [RFC-1779] Killie, S., "A String Representation of 671 Distinguished Names", RFC 1779, March 1995. 673 [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. 674 and S. Jamin, "Resource ReSerVation Protocol 675 (RSVP) - Version 1 Functional Specification", 676 RFC 2205, September 1997. 678 [RFC-2209] Braden, R. and L. Zhang, "Resource ReSerVation 679 Protocol (RSVP) - Version 1 Message Processing 680 Rules", RFC 2209, September 1997. 682 [RFC-2327] Handley, M., Jacobson, V., "SDP: Session 683 Description Protocol", RFC 2327, April 1998. 685 [RFC-2396] Berners-Lee, T., Fielding, R., Irvine, U.C., 686 Masinter, L., "Uniform Resource Identifiers 687 (URI): Generic Syntax", RFC 2396, August 1998. 689 [RFC-2474] Nichols, K., Blake, S., Baker, F., Black, D., 690 "Definition of the Differentiated Services 691 Field (DS Field) in the IPv4 and IPv6 692 Headers", RFC 2474, December 1998. 694 [RFC-2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., 695 Zhang, L., Speer, M., Braden, R., Davie, B., 696 Wroclawski, J., Felstaine, E., "A Framework 697 for Integrated Services Operation over 698 Diffserv Networks", RFC 2998, November 2000. 700 [UNICODE] The Unicode Consortium, "The Unicode Standard, 701 Version 2.0", Addison-Wesley, Reading, MA, 702 1996. 704 [X.509] Housley, R., Ford, W., Polk, W. and D. Solo, 705 "Internet X.509 Public Key Infrastructure 706 Certificate and CRL Profile", RFC 2459, January 707 1999. 709 [X.509-ITU] ITU-T (formerly CCITT) Information technology - 710 Open Systems Interconnection - The Directory: 711 Authentication Framework Recommendation X.509 712 ISO/IEC 9594-8 714 11. Author Information 716 Louis-Nicolas Hamer 717 Nortel Networks 718 Ottawa, Canada 719 EMail: nhamer@nortelnetworks.com 721 Brett Kosinski 722 Nortel Networks 723 Ottawa, Canada 724 EMail: brettk@nortelnetworks.com 726 Bill Gage 727 Nortel Networks 728 Ottawa, Canada 729 EMail: gageb@nortelnetworks.com 731 12. Full Copyright Statement 733 Copyright (C) The Internet Society (2001). All Rights Reserved. This 734 document and translations of it may be copied and furnished to 735 others, and derivative works that comment on or otherwise explain it 736 or assist in its implementation may be prepared, copied, published 737 and distributed, in whole or in part, without restriction of any 738 kind, provided that the above copyright notice and this paragraph 739 are included on all such copies and derivative works. However, this 740 document itself may not be modified in any way, such as by removing 741 the copyright notice or references to the Internet Society or other 742 Internet organisations, except as needed for the purpose of 743 developing Internet standards in which case the procedures for 744 copyrights defined in the Internet Standards process must be 745 followed, or as required to translate it into. 747 Expiration Date 749 This memo is filed as , and 750 expires September 31, 2001.