idnits 2.17.1 draft-ietf-rap-rsvp-authsession-02.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 15) being 77 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 lines with control characters in the document. ** 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 (February 2002) is 8105 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 540, but not defined == Unused Reference: 'ASCII' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'POL-FRAME' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC-1305' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC-1510' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC-2253' is defined on line 699, 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 -- Unexpected draft version: The latest known version of draft-hamer-rap-session-auth is -00, but you're referring to -03. -- 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 2253 (Obsoleted by RFC 4510, RFC 4514) ** 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 (~~), 16 warnings (==), 7 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 August 31, 2002 M. Broda 4 Nortel Networks 5 B. Kosinski 6 University of Alberta 7 Hugh Shieh 8 AT&T Wireless 9 February 2002 11 Session Authorization for RSVP 13 draft-ietf-rap-rsvp-authsession-02.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 August 31, 35 2002. Please send comments to the authors. 37 Copyright Notice 39 Copyright (C) The Internet Society (2002). 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-2253 as an ASCII string. 237 5 UNICODE_DN X.500 Distinguished name as defined 238 in RFC-2253 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 8 KRB_REALM Kerberos realm as defined in RFC-1510. 248 OctetString 249 Contains the authorizing entity identifier. 251 3.3.2 Authorizing Entity Credentials 253 AUTH_ENT_CRED contains the credentials of the authorizing entity, 254 which can then be used by the network to ensure that the entity 255 which generated this session authorization policy element is a 256 valid trusted entity. 258 +-------+-------+-------+-------+ 259 | Length |S-Type |SubType| 260 +-------+-------+-------+-------+ 261 | OctetString ... 262 +-------+-------+-------+-------+ 264 Length 265 Length of the attribute, which MUST be >= 4. 267 S-Type 268 AUTH_ENT_CRED 270 SubType 271 The type of credentials contained in this attribute. IANA 272 SHALL act as a registry for AUTH_ENT_CRED sub-types as 273 described in section 7, IANA Considerations. Initially, the 274 registry contains the following sub-types: 276 1 ASCII_ID The authorizing entity identification in a 277 plain ASCII text string. 279 2 UNICODE_ID The authorizing entity identification in a 280 plain UNICODE text string. 282 3 X509_V3_CERT A chain of authorizing entity's X.509 V3 283 digital certificates. 285 4 PGP_CERT The PGP digital certificate of the 286 authorizing entity. 288 OctetString 289 Contains the authorizing entity credentials. 291 3.3.3 Session Identifier 293 SESSION_ID is a unique identifier for this session. It may be used 294 for a number of purposes, including replay detection, or even 295 mapping this request to a policy decision entry made by the 296 authorizing entity. The SESSION_ID can be based on simple sequence 297 number or on a standard NTP timestamp. 299 +-------+-------+-------+-------+ 300 | Length |S-Type |SubType| 301 +-------+-------+-------+-------+ 302 | OctetString ... 303 +-------+-------+-------+-------+ 304 Length 305 Length of the attribute, which MUST be >= 4. 306 Dependant on the environment, the session identifier will have 307 different lengths in order to ensure uniqueness during the 308 lifetime of a token (equal to the lifetime of the session). 309 We recommend using an octet string of a minimum of 32 bit, but 310 a value of 64 bit may be required in some environments. 312 S-Type 313 SESSION_ID 315 SubType 316 The following sub-types for SESSION_ID are defined. IANA 317 SHALL act as a registry for SESSION_ID sub-types as described 318 in section 7, IANA Considerations. Initially, the registry 319 contains the following sub-types of SESSION_ID: 321 1 ASCII_ID Simple plain ASCII string identifier. 323 2 UNICODE_ID Simple plain UNICODE string identifier. 325 3 OCTET_ID Raw octet string identifier. 327 4 NTP_TIMESTAMP NTP Timestamp Format as defined in 328 RFC-1305. 330 OctetString 331 Contains the actual session identifier. 333 3.3.4 Source Address 335 SOURCE_ADDR is used to identify the source address specification of 336 the authorized session. This S-Type MAY be useful in some scenarios 337 to make sure the resource request has been authorized for that 338 particular source IP address and/or port. 340 +-------+-------+-------+-------+ 341 | Length |S-Type |SubType| 342 +-------+-------+-------+-------+ 343 | OctetString ... 344 +-------+-------+-------+-------+ 346 Length 347 Length of the attribute, which MUST be >= 4. 349 S-Type 350 SOURCE_ADDR 352 SubType 353 The following sub types for SOURCE_ADDR are defined. IANA 354 SHALL act as a registry for SOURCE_ADDR sub-types as 355 described in section 7, IANA Considerations. Initially, the 356 registry contains the following sub types for SOURCE_ADDR: 358 1 IPV4_ADDRESS IPv4 address 360 2 IPV6_ADDRESS IPv6 address 361 3 UDP_PORT UDP port specification 363 4 TCP_PORT TCP port specification 365 OctetString 366 The OctetString contains the source address information. 368 3.3.5 Destination Address 370 DEST_ADDR is used to identify the destination address of the 371 authorized session. This S-Type MAY be useful in some scenarios to 372 make sure the resource request has been authorized for that 373 particular destination IP address and/or port. 375 +-------+-------+-------+-------+ 376 | Length |S-Type |SubType| 377 +-------+-------+-------+-------+ 378 | OctetString ... 379 +-------+-------+-------+-------+ 381 Length 382 Length of the attribute, which MUST be >= 4. 384 S-Type 385 DEST_ADDR 387 SubType 388 The following sub types for DEST_ADDR are defined. IANA SHALL 389 act as a registry for DEST_ADDR sub-types as described in 390 section 7, IANA Considerations. Initially, the registry 391 contains the following sub types for DEST_ADDR: 393 1 IPV4_ADDRESS IPv4 address 395 2 IPV6_ADDRESS IPv6 address 397 3 UDP_PORT UDP port specification 399 4 TCP_PORT TCP port specification 401 OctetString 402 The OctetString contains the destination address specification. 404 3.3.6 Start time 406 START_TIME is used to identify the start time of the authorized 407 session. This S-Type MAY be useful in some scenarios to specify a 408 start time for the authorized session. 410 +-------+-------+-------+-------+ 411 | Length |S-Type |SubType| 412 +-------+-------+-------+-------+ 413 | OctetString ... 414 +-------+-------+-------+-------+ 416 Length 417 Length of the attribute, which MUST be >= 4. 419 S-Type 420 START_TIME 422 SubType 423 The following sub types for START_TIME are defined. IANA SHALL 424 act as a registry for START_TIME sub-types as described in 425 section 7, IANA Considerations. Initially, the registry 426 contains the following sub types for START_TIME: 428 1 NTP_TIMESTAMP NTP Timestamp Format as defined in 429 RFC-1305. 431 OctetString 432 The OctetString contains the start time. 434 3.3.7 End time 436 END_TIME is used to identify the end time of the authorized 437 session. This S-Type MAY be useful in some scenarios to specify a 438 end time for the authorized session. 440 +-------+-------+-------+-------+ 441 | Length |S-Type |SubType| 442 +-------+-------+-------+-------+ 443 | OctetString ... 444 +-------+-------+-------+-------+ 446 Length 447 Length of the attribute, which MUST be >= 4. 449 S-Type 450 END_TIME 452 SubType 453 The following sub types for END_TIME are defined. IANA SHALL 454 act as a registry for END_TIME sub-types as described in 455 section 7, IANA Considerations. Initially, the registry 456 contains the following sub types for END_TIME: 458 1 NTP_TIMESTAMP NTP Timestamp Format as defined in 459 RFC-1305. 461 OctetString 462 The OctetString contains the end time. 464 3.3.8 Resources Authorized 466 RESOURCES is used to define the characteristics of the authorized 467 session. This S-Type MAY be useful in some scenarios to specify the 468 specific resources authorized to ensure the request fits the 469 authorized specifications. 471 +-------+-------+-------+-------+ 472 | Length |S-Type |SubType| 473 +-------+-------+-------+-------+ 474 | OctetString ... 475 +-------+-------+-------+-------+ 477 Length 478 Length of the attribute, which MUST be >= 4. 480 S-Type 481 RESOURCES 483 SubType 484 The following sub-types for RESOURCES are defined. IANA SHALL 485 act as a registry for RESOURCES sub-types as described in 486 section 7, IANA Considerations. Initially, the registry 487 contains the following sub types for RESOURCES: 489 1 BANDWIDTH Maximum bandwidth (kbps) authorized. 491 2 FLOW_SPEC Flow spec specification as defined in 492 RFC-2205. 494 3 SDP SDP Media Descriptor as defined in 495 RFC-2327. 497 4 DSCP Differentiated services codepoint as 498 defined in RFC-2474. 500 OctetString 501 The OctetString contains the resources specification. 503 3.3.9 Digital Signature 505 The DIGITAL_SIGNATURE attribute contains the digital signature of 506 the AUTH_SESSION policy element and signs all the data in the 507 policy element up to the DIGITAL_SIGNATURE. If the 508 DIGITAL_SIGNATURE attribute has been included in the AUTH_SESSION 509 policy element, it MUST be the last attribute in the list. 511 A summary of DIGITAL_SIGNATURE attribute format is described below. 513 +-------+-------+-------+-------+ 514 | Length |S-Type |SubType| 515 +-------+-------+-------+-------+ 516 | OctetString ... 517 +-------+-------+-------+-------+ 519 Length 520 Length of the attribute, which MUST be >= 4. 522 S-Type 523 DIGITAL_SIGNATURE 525 SubType 526 The following sub-types for DIGITAL_SIGNATURE are 527 defined. IANA SHALL act as a registry for DIGITAL_SIGNATURE 528 sub-types as described in section 7, IANA 529 Considerations. Initially, the registry contains the following 530 sub types for DIGITAL_SIGNATURE: 532 1 DSA_SHA1 DSA signature using SHA1 [X.509]. 534 2 RSA_SHA1 RSA signature using SHA1 [X.509]. 536 3 RSA_MD5 RSA signature using MD5 [X.509]. 538 4 HMAC_SHA1 HMAC with SHA1 [RFC 2104]. 540 5 HMAC_MD5 HMAC with MD5 [RFC 2104]. 542 OctetString 543 OctetString contains the digital signature of the AUTH_SESSION. 545 4. Framework 547 [S-AUTH] describes a framework in which the session authorization 548 policy element may be utilized to transport information for use in 549 authorizing resource reservation for media flows. 551 5. Message Processing Rules 553 5.1 Message Generation (RSVP Host) 555 An RSVP message is created as specified in [RFC-2205] with following 556 modifications. 558 1. RSVP message MUST contain at most one AUTH_SESSION policy element. 560 2. A Session Authorization policy element (AUTH_SESSION) is created 561 and the IdentityType field is set to indicate the identity type 562 in the policy element. Only the required Session Authorization 563 attributes are added. 565 3. POLICY_DATA object (containing the AUTH_SESSION policy element) 566 is inserted in the RSVP message in the appropriate place. 568 5.2 Message Reception (Router) 570 RSVP message is processed as specified in [RFC-2205] with following 571 modifications. 573 1. If router is policy aware then it SHOULD send the RSVP 574 message to the PDP and wait for response. If the router is 575 policy unaware then it ignores the policy data objects and 576 continues processing the RSVP message. 578 2. Reject the message if the response from the PDP is negative. 580 3. Continue processing the RSVP message. 582 5.3 Authorization (Router/PDP) 584 1. Retrieve the AUTH_SESSION policy element. Check the PE type 585 field and return an error if the identity type is not supported. 587 2. Verify the authorizing entity credentials and message integrity. 589 - Pre-shared key authentication: Get entity ID, identify 590 appropriate pre-shared key for the authorizing entity, and 591 validate signature. 593 - Public Key: Validate the certificate chain against 594 trusted Certificate Authority (CA) and valide the 595 message signature using the public key. 597 - Kerberos Ticket: Request a ticket for the authorizing entity 598 from the local KDC. Use the ticket to access the authorizing 599 entity and obtain authentication data for the message (e.g. 600 the signing key) or the data itself. 602 3. Verify the requested QoS does not exceed the authorized QoS. 604 6. Error Signaling 606 If PDP fails to verify the AUTH_SESSION policy element then it MUST 607 return policy control failure (Error Code = 02) to the PEP. The 608 error values are described in [RFC-2205] and [POL-EXT]. Also PDP 609 SHOULD supply a policy data object containing an AUTH_DATA 610 Policy Element with A-Type=POLICY_ERROR_CODE containing more 611 details on the Policy Control failure [I-REP]. The PEP 612 will include this Policy Data object in the outgoing RSVP Error 613 message. 615 7. IANA Considerations 617 Following the policies outlined in [IANA-CONSIDERATIONS], session 618 authorization attribute types (S-Type)in the range 0-127 are 619 allocated through an IETF Consensus action, S-Type values between 620 128-255 are reserved for Private Use and are not assigned by IANA. 622 Following the policies outlined in [IANA-CONSIDERATIONS], 623 AUTH_ENT_ID, AUTH_ENT_CRED, SESSION_ID, START_TIME, STOP_TIME, 624 SOURCE_IP, DEST_IP, RESOURCES and DIGITAL_SIGNATURE SubType values 625 in the range 0-127 are allocated through an IETF Consensus action, 626 SubType values between 128-255 are reserved for Private Use and are 627 not assigned by IANA. 629 8. Security Considerations 631 The purpose of this draft is to describe a mechanism for session 632 authorization to prevent theft of service. 634 In order to ensure that the integrity of the token is preserved in 635 some environments, the digital signature attribute SHOULD be used. 636 In fact, since the token is to be relayed through the end host, 637 which is usually considered untrusted, we strongly recommend the 638 use of the digital signature attribute. 640 Simple authentication (e.g. plain ASCII or UNICODE) does not 641 contain credential that can be securely authenticated and is 642 inherently less secured. 644 The Kerberos authentication mechanism is reasonably well secured. 645 Kerberos is more efficient than the PKI mechanism from 646 computational point of view. 648 PKI authentication option should provide highest level of 649 security and good scalability, however it requires infrastructure 650 support and may have performance impacts. 652 9. Acknowledgments 654 We would like to thank Francois Audet, Don Wade, Hamid Syed, 655 Kwok Ho Chan and many others for their valuable comments. 657 In addition, we would like to thank S. Yadav, et al, for their 658 efforts on RFC 3182, as this document borrows from their work. 660 10. References 662 [I-REP] S. Yadav et al, "Identity Representation for 663 RSVP", RFC 3182, October 2001 665 [S-AUTH] L-N. Hamer et al., "Framework for 666 session setup with media authorization", 667 Internet-Draft, 668 draft-hamer-rap-session-auth-03.txt, 669 February 2002. 671 [ASCII] Coded Character Set -- 7-Bit American Standard 672 Code for Information Interchange, ANSI X3.4- 673 1986. 675 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 676 Writing an IANA Considerations Section in 677 RFCs", BCP 26, RFC 2434, October 1998. 679 [POL-EXT] Herzog, S., "RSVP Extensions for Policy 680 Control", RFC 2750, January 2000. 682 [POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A 683 Framework for Policy-based Admission Control 684 RSVP", RFC 2753, January 2000. 686 [RFC-1305] Mills, David L., "Network Time Protocol 687 (Version 3) Specification, Implementation, and 688 Analysis", RFC 1305, March 1992. 690 [RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network 691 Authentication Service (V5)", RFC 1510, 692 September 1993. 694 [RFC-1633] Braden, R., Clark, D., Shenker, S., 695 "Integrated Services in the Internet 696 Architecture: An Overview", RFC 1633, 697 June 1994. 699 [RFC-2253] Wahl, M. et al., "UTF-8 String 700 Representation of Distinguished Names", 701 RFC 2253, December 1997. 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 (2002). 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 August 31, 2002.