idnits 2.17.1 draft-ietf-rap-rsvp-authsession-01.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 15 longer pages, the longest (page 13) being 78 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 (November 2001) is 8197 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 19 == Missing Reference: 'RFC-2119' is mentioned on line 63, but not defined == Missing Reference: 'RFC 2104' is mentioned on line 538, but not defined == Unused Reference: 'ASCII' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'POL-FRAME' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC-1305' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC-1510' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'RFC-1779' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'RFC-2209' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'RFC-2327' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'RFC-2396' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC-2474' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 730, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-ietf-rap-rsvp-better-identity-00 -- Possible downref: Normative reference to a draft: ref. 'I-REP' -- Unexpected draft version: The latest known version of draft-hamer-rap-session-auth is -00, but you're referring to -02. -- 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: 15 errors (**), 0 flaws (~~), 17 warnings (==), 8 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. Gage 3 Expires April 31, 2002 M. Broda 4 Nortel Networks 5 B. Kosinski 6 University of Alberta 7 Hugh Shieh 8 AT&T Wireless 9 November 2001 11 Session Authorization for RSVP 13 draft-ietf-rap-rsvp-authsession-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 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. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet- Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 The distribution of this memo is unlimited. This memo is filed as 34 , and expires April 31, 35 2002. Please send comments to the authors. 37 Copyright Notice 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 Abstract 43 This document describes the representation of session authorization 44 information in the POLICY_DATA object [POL-EXT] for supporting 45 policy-based per-session authorization and admission control in 46 RSVP. The goal of session authorization is to allow the exchange 47 of information between network elements in order to authorize the 48 use of resources for a service and to co-ordinate actions between 49 the signaling and transport planes. This document describes how a 50 process on a system authorizes the reservation of resources by a 51 host and then provides that host with a session authorization 52 policy element which can be inserted into the RSVP PATH message to 53 facilitate proper and secure reservation of those resources within 54 the network. We describe the encoding of media authorization 55 information as RSVP policy elements and provide details relating to 56 operations, processing rules and error scenarios. 58 1. Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC-2119]. 64 2. Introduction 66 RSVP [RFC-2205] is a resource reservation setup protocol designed 67 for an integrated services [RFC-1633] or DiffEdge [RFC-2998] 68 Internet. The RSVP protocol is used by a host to request specific 69 qualities of service from the network for particular application 70 data streams or flows. RSVP is also used by routers to deliver 71 quality-of-service (QoS) requests to all nodes along the path(s) of 72 the flows and to establish and maintain state to provide the 73 requested service. RSVP requests will generally result in 74 resources being reserved in each node along the data path. RSVP 75 allows users to obtain preferential access to network resources, 76 under the control of an admission control mechanism. Such 77 admission control is often based on user or application identity 78 [I-REP], however, it is also valuable to provide the ability for 79 per-session admission control. 81 In order to allow for per-session admission control, it is necessary 82 to provide a mechanism for ensuring an RSVP request from a host has 83 been properly pre-authorized before allowing the reservation of 84 resources. In order to meet this requirement, there must be 85 information in the RSVP message which may be used to verify the 86 validity of the RSVP request. This may be done by providing the host 87 with a token upon authorization which may be inserted into the RSVP 88 PATH message and verified by the network. 90 We describe the session authorization element (AUTH_SESSION) 91 contained in the POLICY_DATA object. The user process must obtain an 92 AUTH_SESSION object from an authorizing entity, which it may then 93 pass to the RSVP process (service) on the originating host. The RSVP 94 service then inserts the AUTH_SESSION object into the RSVP PATH 95 message to allow verification of the network resource request. 96 Network elements, such as routers, verify the request and then admit 97 the RSVP message based on admission policy. 99 [S-AUTH] describes a framework in which a session authorization 100 policy element may be utilized to contain information relevant to 101 the network's decision to grant a reservation request. 103 3. Policy Element for Session Authorization Data 105 3.1 Policy Data Object Format 107 POLICY_DATA objects contain policy information and are carried by 108 RSVP messages. A detail description of the format of POLICY_DATA 109 object can be found in "RSVP Extensions for Policy Control" [POL- 110 EXT]. 112 3.2 Session Authorization Data Policy Element 114 In this section we describe a policy element (PE) called session 115 authorization data (AUTH_SESSION). The AUTH_SESSION policy element 116 contains a list of fields which describe the session, along with 117 other attributes. 119 +-------------+-------------+-------------+-------------+ 120 | Length | P-Type = AUTH_SESSION | 121 +-------------+-------------+-------------+-------------+ 122 // Session Authorization Attribute List // 123 +-------------------------------------------------------+ 125 Length 126 The length of the policy element (including the Length and 127 P-Type) is in number of octets (MUST be in multiples of 4) and 128 indicates the end of the session authorization information 129 block. 131 P-Type (Session Authorization Type) 132 The Policy element type (P-type) of this element. The 133 Internet Assigned Numbers Authority (IANA) acts as a registry 134 for policy element types for identity as described in 135 [POL-EXT]. The definition for AUTH_SESSION is currently to be 136 defined. 138 Session Authorization Attribute List 139 The session authorization attribute list is a collection of 140 objects which describes the session and provides other 141 information necessary to verify the RSVP request. 143 3.3 Session Authorization Attributes 145 A session authorization attribute may contain a variety of 146 information and has both an attribute type and subtype. The 147 attribute itself MUST be a multiple of 4 octets in length, and any 148 attributes that are not a multiple of 4 octets long MUST be padded 149 to a 4-octet boundary. 151 +--------+--------+--------+--------+ 152 | Length | S-Type |SubType | 153 +--------+--------+--------+--------+ 154 | Value ... 155 +--------+--------+--------+--------+ 157 Length 158 The length field is two octets and indicates the actual length 159 of the attribute (including Length, S-Type and SubType fields) 160 in number of octets. The length does NOT include any bytes 161 padding to the value field to make the attribute a multiple of 162 4 octets long. 164 S-Type 165 Session authorization attribute type (S-Type) field is one 166 octet. IANA SHALL act as a registry for S-Types as described 167 in section 7, IANA Considerations. Initially, the registry 168 contains the following S-Types: 170 1 AUTH_ENT_ID The unique identifier of the entity 171 which authorized the session. 173 2 AUTH_ENT_CRED The credentials of the authorizing 174 entity, such as a digital 175 certificate. 177 3 SESSION_ID Unique identifier for this session. 179 4 SOURCE_ADDR Address specification for the 180 session originator. 182 5 DEST_ADDR Address specification for the 183 session end-point. 185 6 START_TIME The starting time for the session. 187 7 END_TIME The end time for the session. 189 8 RESOURCES The resources which the user is 190 authorized to request. 192 9 DIGITAL_SIGNATURE Digital signature of the session 193 authorization policy element. 195 SubType 196 Session authorization attribute sub-type is one octet in 197 length. The value of the SubType depends on the S-Type. 199 Value 200 The attribute specific information. 202 3.3.1 Authorizing Entity Identifier 204 AUTH_ENT_ID is used to identify the entity which authorized the 205 initial service request and generated the session authorization 206 policy element. The AUTH_ENT_ID may be represented in various 207 formats, and the SubType is used to define the format for the ID. 208 The format for AUTH_ENT_ID is as follows: 210 +-------+-------+-------+-------+ 211 | Length |S-Type |SubType| 212 +-------+-------+-------+-------+ 213 | OctetString ... 214 +-------+-------+-------+-------+ 216 Length 217 Length of the attribute, which MUST be >= 4. 219 S-Type 220 AUTH_ENT_ID 222 SubType 223 The following sub-types for AUTH_ENT_ID are defined. IANA 224 SHALL act as a registry for AUTH_ENT_ID sub-types as described 225 in section 7, IANA Considerations. Initially, the registry 226 contains the following sub-types of AUTH_ENT_ID: 228 1 IPV4_ADDRESS IPv4 address 230 2 IPV6_ADDRESS IPv6 address 232 3 FQDN Fully Qualified Domain Name 234 4 ASCII_DN X.500 Distinguished name as defined 235 in RFC-1779 as an ASCII string. 237 5 UNICODE_DN X.500 Distinguished name as defined 238 in RFC-1779 as a UNICODE string. 240 6 URI Universal Resource Identifier, as 241 defined in RFC-2396. 243 7 KRB_PRINCIPAL Kerberos principal name as defined in 244 RFC-1510. 246 OctetString 247 Contains the authorizing entity identifier. 249 3.3.2 Authorizing Entity Credentials 251 AUTH_ENT_CRED contains the credentials of the authorizing entity, 252 which can then be used by the network to ensure that the entity 253 which generated this session authorization policy element is a 254 valid trusted entity. 256 +-------+-------+-------+-------+ 257 | Length |S-Type |SubType| 258 +-------+-------+-------+-------+ 259 | OctetString ... 260 +-------+-------+-------+-------+ 262 Length 263 Length of the attribute, which MUST be >= 4. 265 S-Type 266 AUTH_ENT_CRED 268 SubType 269 The type of credentials contained in this attribute. IANA 270 SHALL act as a registry for AUTH_ENT_CRED sub-types as 271 described in section 7, IANA Considerations. Initially, the 272 registry contains the following sub-types: 274 1 ASCII_ID The authorizing entity identification in a 275 plain ASCII text string. 277 2 UNICODE_ID The authorizing entity identification in a 278 plain UNICODE text string. 280 3 X509_V3_CERT A chain of authorizing entity's X.509 V3 281 digital certificates. 283 4 PGP_CERT The PGP digital certificate of the 284 authorizing entity. 286 OctetString 287 Contains the authorizing entity credentials. 289 3.3.3 Session Identifier 291 SESSION_ID is a unique identifier for this session. It may be used 292 for a number of purposes, including replay detection, or even 293 mapping this request to a policy decision entry made by the 294 authorizing entity. The SESSION_ID can be based on simple sequence 295 number or on a standard NTP timestamp. 297 +-------+-------+-------+-------+ 298 | Length |S-Type |SubType| 299 +-------+-------+-------+-------+ 300 | OctetString ... 301 +-------+-------+-------+-------+ 302 Length 303 Length of the attribute, which MUST be >= 4. 304 Dependant on the environment, the session identifier will have 305 different lengths in order to ensure uniqueness during the 306 lifetime of a token (equal to the lifetime of the session). 307 We recommend using an octet string of a minimum of 32 bit, but 308 a value of 64 bit may be required in some environments. 310 S-Type 311 SESSION_ID 313 SubType 314 The following sub-types for SESSION_ID are defined. IANA 315 SHALL act as a registry for SESSION_ID sub-types as described 316 in section 7, IANA Considerations. Initially, the registry 317 contains the following sub-types of SESSION_ID: 319 1 ASCII_ID Simple plain ASCII string identifier. 321 2 UNICODE_ID Simple plain UNICODE string identifier. 323 3 OCTET_ID Raw octet string identifier. 325 4 NTP_TIMESTAMP NTP Timestamp Format as defined in 326 RFC-1305. 328 OctetString 329 Contains the actual session identifier. 331 3.3.4 Source Address 333 SOURCE_ADDR is used to identify the source address specification of 334 the authorized session. This S-Type MAY be useful in some scenarios 335 to make sure the resource request has been authorized for that 336 particular source IP address and/or port. 338 +-------+-------+-------+-------+ 339 | Length |S-Type |SubType| 340 +-------+-------+-------+-------+ 341 | OctetString ... 342 +-------+-------+-------+-------+ 344 Length 345 Length of the attribute, which MUST be >= 4. 347 S-Type 348 SOURCE_ADDR 350 SubType 351 The following sub types for SOURCE_ADDR are defined. IANA 352 SHALL act as a registry for SOURCE_ADDR sub-types as 353 described in section 7, IANA Considerations. Initially, the 354 registry contains the following sub types for SOURCE_ADDR: 356 1 IPV4_ADDRESS IPv4 address 358 2 IPV6_ADDRESS IPv6 address 359 3 UDP_PORT UDP port specification 361 4 TCP_PORT TCP port specification 363 OctetString 364 The OctetString contains the source address information. 366 3.3.5 Destination Address 368 DEST_ADDR is used to identify the destination address of the 369 authorized session. This S-Type MAY be useful in some scenarios to 370 make sure the resource request has been authorized for that 371 particular destination IP address and/or port. 373 +-------+-------+-------+-------+ 374 | Length |S-Type |SubType| 375 +-------+-------+-------+-------+ 376 | OctetString ... 377 +-------+-------+-------+-------+ 379 Length 380 Length of the attribute, which MUST be >= 4. 382 S-Type 383 DEST_ADDR 385 SubType 386 The following sub types for DEST_ADDR are defined. IANA SHALL 387 act as a registry for DEST_ADDR sub-types as described in 388 section 7, IANA Considerations. Initially, the registry 389 contains the following sub types for DEST_ADDR: 391 1 IPV4_ADDRESS IPv4 address 393 2 IPV6_ADDRESS IPv6 address 395 3 UDP_PORT UDP port specification 397 4 TCP_PORT TCP port specification 399 OctetString 400 The OctetString contains the destination address specification. 402 3.3.6 Start time 404 START_TIME is used to identify the start time of the authorized 405 session. This S-Type MAY be useful in some scenarios to specify a 406 start time for the authorized session. 408 +-------+-------+-------+-------+ 409 | Length |S-Type |SubType| 410 +-------+-------+-------+-------+ 411 | OctetString ... 412 +-------+-------+-------+-------+ 414 Length 415 Length of the attribute, which MUST be >= 4. 417 S-Type 418 START_TIME 420 SubType 421 The following sub types for START_TIME are defined. IANA SHALL 422 act as a registry for START_TIME sub-types as described in 423 section 7, IANA Considerations. Initially, the registry 424 contains the following sub types for START_TIME: 426 1 NTP_TIMESTAMP NTP Timestamp Format as defined in 427 RFC-1305. 429 OctetString 430 The OctetString contains the start time. 432 3.3.7 End time 434 END_TIME is used to identify the end time of the authorized 435 session. This S-Type MAY be useful in some scenarios to specify a 436 end time for the authorized session. 438 +-------+-------+-------+-------+ 439 | Length |S-Type |SubType| 440 +-------+-------+-------+-------+ 441 | OctetString ... 442 +-------+-------+-------+-------+ 444 Length 445 Length of the attribute, which MUST be >= 4. 447 S-Type 448 END_TIME 450 SubType 451 The following sub types for END_TIME are defined. IANA SHALL 452 act as a registry for END_TIME sub-types as described in 453 section 7, IANA Considerations. Initially, the registry 454 contains the following sub types for END_TIME: 456 1 NTP_TIMESTAMP NTP Timestamp Format as defined in 457 RFC-1305. 459 OctetString 460 The OctetString contains the end time. 462 3.3.8 Resources Authorized 464 RESOURCES is used to define the characteristics of the authorized 465 session. This S-Type MAY be useful in some scenarios to specify the 466 specific resources authorized to ensure the request fits the 467 authorized specifications. 469 +-------+-------+-------+-------+ 470 | Length |S-Type |SubType| 471 +-------+-------+-------+-------+ 472 | OctetString ... 473 +-------+-------+-------+-------+ 475 Length 476 Length of the attribute, which MUST be >= 4. 478 S-Type 479 RESOURCES 481 SubType 482 The following sub-types for RESOURCES are defined. IANA SHALL 483 act as a registry for RESOURCES sub-types as described in 484 section 7, IANA Considerations. Initially, the registry 485 contains the following sub types for RESOURCES: 487 1 BANDWIDTH Maximum bandwidth (kbps) authorized. 489 2 FLOW_SPEC Flow spec specification as defined in 490 RFC-2205. 492 3 SDP SDP Media Descriptor as defined in 493 RFC-2327. 495 4 DSCP Differentiated services codepoint as 496 defined in RFC-2474. 498 OctetString 499 The OctetString contains the resources specification. 501 3.3.9 Digital Signature 503 The DIGITAL_SIGNATURE attribute contains the digital signature of 504 the AUTH_SESSION policy element and signs all the data in the 505 policy element up to the DIGITAL_SIGNATURE. If the 506 DIGITAL_SIGNATURE attribute has been included in the AUTH_SESSION 507 policy element, it MUST be the last attribute in the list. 509 A summary of DIGITAL_SIGNATURE attribute format is described below. 511 +-------+-------+-------+-------+ 512 | Length |S-Type |SubType| 513 +-------+-------+-------+-------+ 514 | OctetString ... 515 +-------+-------+-------+-------+ 517 Length 518 Length of the attribute, which MUST be >= 4. 520 S-Type 521 DIGITAL_SIGNATURE 523 SubType 524 The following sub-types for DIGITAL_SIGNATURE are 525 defined. IANA SHALL act as a registry for DIGITAL_SIGNATURE 526 sub-types as described in section 7, IANA 527 Considerations. Initially, the registry contains the following 528 sub types for DIGITAL_SIGNATURE: 530 1 DSA_SHA1 DSA signature using SHA1 [X.509]. 532 2 RSA_SHA1 RSA signature using SHA1 [X.509]. 534 3 RSA_MD5 RSA signature using MD5 [X.509]. 536 4 HMAC_SHA1 HMAC with SHA1 [RFC 2104]. 538 5 HMAC_MD5 HMAC with MD5 [RFC 2104]. 540 OctetString 541 OctetString contains the digital signature of the AUTH_SESSION. 543 4. Framework 545 [S-AUTH] describes a framework in which the session authorization 546 policy element may be utilized to transport information for use in 547 authorizing resource reservation for media flows. 549 5. Message Processing Rules 551 5.1 Message Generation (RSVP Host) 553 An RSVP message is created as specified in [RFC-2205] with following 554 modifications. 556 1. RSVP message MUST contain at most one AUTH_SESSION policy element. 558 2. A Session Authorization policy element (AUTH_SESSION) is created 559 and the IdentityType field is set to indicate the identity type 560 in the policy element. Only the required Session Authorization 561 attributes are added. 563 3. POLICY_DATA object (containing the AUTH_SESSION policy element) 564 is inserted in the RSVP message in the appropriate place. 566 5.2 Message Reception (Router) 568 RSVP message is processed as specified in [RFC-2205] with following 569 modifications. 571 1. If router is policy aware then it SHOULD send the RSVP 572 message to the PDP and wait for response. If the router is 573 policy unaware then it ignores the policy data objects and 574 continues processing the RSVP message. 576 2. Reject the message if the response from the PDP is negative. 578 3. Continue processing the RSVP message. 580 5.3 Authorization (Router/PDP) 582 1. Retrieve the AUTH_SESSION policy element. Check the PE type 583 field and return an error if the identity type is not supported. 585 2. Verify the authorizing entity credentials and message integrity. 587 - Pre-shared key authentication: Get entity ID, identify 588 appropriate pre-shared key for the authorizing entity, and 589 validate signature. 591 - Public Key: Validate the certificate chain against 592 trusted Certificate Authority (CA) and valide the 593 message signature using the public key. 595 - Kerberos Ticket: Request a ticket for the authorizing entity 596 from the local KDC. Use the ticket to access the authorizing 597 entity and obtain authentication data for the message (e.g. 598 the signing key) or the data itself. 600 3. Verify the requested QoS does not exceed the authorized QoS. 602 6. Error Signaling 604 If PDP fails to verify the AUTH_SESSION policy element then it MUST 605 return policy control failure (Error Code = 02) to the PEP. The 606 error values are described in [RFC-2205] and [POL-EXT]. Also PDP 607 SHOULD supply a policy data object containing an AUTH_DATA 608 Policy Element with A-Type=POLICY_ERROR_CODE containing more 609 details on the Policy Control failure [I-REP]. The PEP 610 will include this Policy Data object in the outgoing RSVP Error 611 message. 613 7. IANA Considerations 615 Following the policies outlined in [IANA-CONSIDERATIONS], session 616 authorization attribute types (S-Type)in the range 0-127 are 617 allocated through an IETF Consensus action, S-Type values between 618 128-255 are reserved for Private Use and are not assigned by IANA. 620 Following the policies outlined in [IANA-CONSIDERATIONS], 621 AUTH_ENT_ID, AUTH_ENT_CRED, SESSION_ID, START_TIME, STOP_TIME, 622 SOURCE_IP, DEST_IP, RESOURCES and DIGITAL_SIGNATURE SubType values 623 in the range 0-127 are allocated through an IETF Consensus action, 624 SubType values between 128-255 are reserved for Private Use and are 625 not assigned by IANA. 627 8. Security Considerations 629 The purpose of this draft is to describe a mechanism for session 630 authorization to prevent theft of service. 632 In order to ensure that the integrity of the token is preserved in 633 some environments, the digital signature attribute SHOULD be used. 634 In fact, since the token is to be relayed through the end host, 635 which is usually considered untrusted, we strongly recommend the 636 use of the digital signature attribute. 638 Simple authentication (e.g. plain ASCII or UNICODE) does not 639 contain credential that can be securely authenticated and is 640 inherently less secured. 642 The Kerberos authentication mechanism is reasonably well secured. 643 Kerberos is more efficient than the PKI mechanism from 644 computational point of view. 646 PKI authentication option should provide highest level of 647 security and good scalability, however it requires infrastructure 648 support and may have performance impacts. 650 9. Acknowledgments 652 We would like to thank Francois Audet, Don Wade, Hamid Syed, 653 Kwok Ho Chan and many others for their valuable comments. 655 In addition, we would like to thank S. Yadav, et al, for their 656 efforts on RFC 2752, as this document borrows heavily from their 657 work. 659 10. References 661 [I-REP] S. Yadav et al, "Identity Representation for 662 RSVP", Internet-draft, 663 draft-ietf-rap-rsvp-better-identity-00.txt, 664 June 2001 666 [S-AUTH] Hamer, L-N. and Gage, B, "Framework for 667 session setup with media authorization", 668 Internet-Draft, 669 draft-hamer-rap-session-auth-02.txt, 670 November 2001. 672 [ASCII] Coded Character Set -- 7-Bit American Standard 673 Code for Information Interchange, ANSI X3.4- 674 1986. 676 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 677 Writing an IANA Considerations Section in 678 RFCs", BCP 26, RFC 2434, October 1998. 680 [POL-EXT] Herzog, S., "RSVP Extensions for Policy 681 Control", RFC 2750, January 2000. 683 [POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A 684 Framework for Policy-based Admission Control 685 RSVP", RFC 2753, January 2000. 687 [RFC-1305] Mills, David L., "Network Time Protocol 688 (Version 3) Specification, Implementation, and 689 Analysis", RFC 1305, March 1992. 691 [RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network 692 Authentication Service (V5)", RFC 1510, 693 September 1993. 695 [RFC-1633] Braden, R., Clark, D., Shenker, S., 696 "Integrated Services in the Internet 697 Architecture: An Overview", RFC 1633, 698 June 1994. 700 [RFC-1779] Killie, S., "A String Representation of 701 Distinguished Names", RFC 1779, March 1995. 703 [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. 704 and S. Jamin, "Resource ReSerVation Protocol 705 (RSVP) - Version 1 Functional Specification", 706 RFC 2205, September 1997. 708 [RFC-2209] Braden, R. and L. Zhang, "Resource ReSerVation 709 Protocol (RSVP) - Version 1 Message Processing 710 Rules", RFC 2209, September 1997. 712 [RFC-2327] Handley, M., Jacobson, V., "SDP: Session 713 Description Protocol", RFC 2327, October 1998. 715 [RFC-2396] Berners-Lee, T., Fielding, R., Irvine, U.C., 716 Masinter, L., "Uniform Resource Identifiers 717 (URI): Generic Syntax", RFC 2396, August 1998. 719 [RFC-2474] Nichols, K., Blake, S., Baker, F., Black, D., 720 "Definition of the Differentiated Services 721 Field (DS Field) in the IPv4 and IPv6 722 Headers", RFC 2474, December 1998. 724 [RFC-2998] Bernet, Y., Ford, P., Yavatkar, R., Baker, F., 725 Zhang, L., Speer, M., Braden, R., Davie, B., 726 Wroclawski, J., Felstaine, E., "A Framework 727 for Integrated Services Operation over 728 Diffserv Networks", RFC 2998, November 2000. 730 [UNICODE] The Unicode Consortium, "The Unicode Standard, 731 Version 2.0", Addison-Wesley, Reading, MA, 732 1996. 734 [X.509] Housley, R., Ford, W., Polk, W. and D. Solo, 735 "Internet X.509 Public Key Infrastructure 736 Certificate and CRL Profile", RFC 2459, January 737 1999. 739 [X.509-ITU] ITU-T (formerly CCITT) Information technology - 740 Open Systems Interconnection - The Directory: 741 Authentication Framework Recommendation X.509 742 ISO/IEC 9594-8 744 11. Author Information 746 Louis-Nicolas Hamer 747 Nortel Networks 748 Ottawa, Canada 749 EMail: nhamer@nortelnetworks.com 751 Brett Kosinski 752 University of Alberta 753 Edmonton, Canada 754 EMail: kosinski@cs.ualberta.ca 756 Bill Gage 757 Nortel Networks 758 Ottawa, Canada 759 EMail: gageb@nortelnetworks.com 761 Matt Broda 762 Nortel Networks 763 Ottawa, Canada 764 EMail: mbroda@nortelnetworks.com 766 Hugh Shieh 767 AT&T Wireless 768 Redmond, USA 769 Email: hugh.shieh@attws.com 771 12. Full Copyright Statement 773 Copyright (C) The Internet Society (2001). All Rights Reserved. This 774 document and translations of it may be copied and furnished to 775 others, and derivative works that comment on or otherwise explain it 776 or assist in its implementation may be prepared, copied, published 777 and distributed, in whole or in part, without restriction of any 778 kind, provided that the above copyright notice and this paragraph 779 are included on all such copies and derivative works. However, this 780 document itself may not be modified in any way, such as by removing 781 the copyright notice or references to the Internet Society or other 782 Internet organisations, except as needed for the purpose of 783 developing Internet standards in which case the procedures for 784 copyrights defined in the Internet Standards process must be 785 followed, or as required to translate it into. 787 Expiration Date 789 This memo is filed as , and 790 expires April 31, 2002.