idnits 2.17.1 draft-ietf-rap-rsvp-identity-01.txt: ** The Abstract section seems to be numbered -(350): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(458): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(463): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(651): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(665): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 20 instances of lines with non-ascii characters in the document. == 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 2) being 59 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 == Line 47 has weird spacing: '...ding of ident...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (January 1999) is 9225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 60, but not defined == Missing Reference: 'RFC 1633' is mentioned on line 64, but not defined == Missing Reference: 'RFC 1509' is mentioned on line 234, but not defined ** Obsolete undefined reference: RFC 1509 (Obsoleted by RFC 2744) == Missing Reference: 'RFC2205' is mentioned on line 526, but not defined == Unused Reference: 'ASCII' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC 1704' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC 2209' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 656, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- No information found for draft-ietf-rap-policy-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'POL-EXT' == Outdated reference: A later version (-03) exists of draft-ietf-rap-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. 'POL-FRAME') ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 1704 ** Obsolete normative reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 2209 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 16 errors (**), 0 flaws (~~), 15 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Satyendra Yadav 2 File: Intel 3 Ramesh Pabbati 4 Peter Ford 5 Tim Moore 6 Microsoft 7 Shai Herzog 8 IPHighway 10 Identity Representation for RSVP 11 January 1999 13 Status of this Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a 24 "working draft" or "work in progress". 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 A Revised Version of this draft document will be submitted to the 30 RFC editor as a Proposed Standard for the Internet Community. 31 Discussion and suggestions for improvement are requested. This 32 document will expire in July 1999. Distribution of this draft is 33 unlimited. 35 Copyright Notice 37 Copyright (C) The Internet Society (1999). All Rights Reserved. 39 1. Abstract 41 This document describes the representation of identity information 42 in POLICY_DATA object [POL-EXT] for supporting policy based 43 admission control in RSVP. The goal of identity representation is to 44 allow a process on a system to securely identify the owner of the 45 communicating process (e.g. user id) and convey this information in 46 RSVP messages (PATH or RESV) in a secure manner. We describe the 47 encoding of identities as RSVP policy element. We describe the 48 processing rules to generate identity policy elements for multicast 49 merged flows. Subsequently, we describe representations of user 50 identities for Kerberos and Public Key based user authentication 51 mechanisms. In summary we describe the use of this identity 52 information in an operational setting. 54 Yadav, et al. 1 55 2. Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 59 this document are to be interpreted as described in [RFC-2119]. 61 3. Introduction 63 RSVP [RFC 2205] is a resource reservation setup protocol designed 64 for an integrated services Internet [RFC 1633]. RSVP is used by a 65 host to request specific quality of service (QoS) from the network 66 for particular application data streams or flows. RSVP is also used 67 by routers to deliver 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 resources 70 being reserved in each node along the data path. RSVP allows 71 particular users to obtain preferential access to network resources, 72 under the control of an admission control mechanism. Permission to 73 make a reservation is based both upon the availability of the 74 requested resources along the path of the data and upon satisfaction 75 of policy rules. Providing policy based admission control mechanism 76 based on user identity is one of the prime requirements. 78 In order to solve these problems and implement user based policy 79 control it is required to identify the user making an RSVP request. 80 This document proposes a mechanism for sending identification 81 information in the RSVP requests and enables authorization decisions 82 based on policy and identity of the user requesting resources from 83 the network. 85 We describe the authentication policy element (AUTH_DATA) contained 86 in the POLICY_DATA object. User process generates an AUTH_DATA 87 policy element and gives it to RSVP process (service) on the 88 originating host. RSVP process inserts AUTH_DATA into the RSVP 89 message to identify the owner (user) making the request for network 90 resources. Network elements, such as routers, authenticate user 91 using the credentials presented in the AUTH_DATA and admit the RSVP 92 message based on admission policy. After a request has been 93 authenticated, first hop router installs the RSVP state and forwards 94 the new policy element returned by the Policy Decision Point (PDP) 95 [POL-FRAME]. 97 Yadav, et al. 2 98 4. Policy Element for Authentication Data 100 4.1 Policy Data Object Format 102 POLICY_DATA objects contain policy information and are carried by 103 RSVP messages. A detail description of the format of POLICY_DATA 104 object can be found in �RSVP Extensions for Policy Control� [POL- 105 EXT]. 107 4.2 Authentication Data Policy Element 109 In this section, we describe a policy element (PE) called 110 authentication data (AUTH_DATA). AUTH_DATA policy element contains a 111 list of authentication attributes. Policy object containing 112 AUTH_DATA must be protected against replay attacks using INTEGRITY 113 object option as described in the [POL-EXT]. 115 +-------------+-------------+-------------+-------------+ 116 | Length | P-Type = AUTH_DATA | 117 +-------------+-------------+-------------+-------------+ 118 | IdentityType | 0 (Reserved) | 119 +-------------+-------------+-------------+-------------+ 120 // Authentication Attribute List // 121 | | 122 +-------------------------------------------------------+ 124 Length 125 The length of the policy element (including the Length and P- 126 Type) is in number of octets (must be a multiple of 4) and 127 indicates the end of the authentication attribute list. 129 AUTH_DATA 130 Policy element type (P-type) for the authentication data as 131 registered with Internet Assigned Numbers Authority (IANA). 133 IdentityType 134 This field describes the identity type used for authentication. 135 The Internet Assigned Numbers Authority (IANA) acts as a 136 registry for identity types as described in the section 10, IANA 137 Considerations. Initially, the registry contains the following 138 identity types: 140 1 AUTH_USER authentication scheme to identify users 142 2 AUTH_APP authentication scheme to identify 143 applications 145 Reserved 146 Must be set to 0. 148 Yadav, et al. 3 149 Authentication Attribute List 151 Authentication attributes contain information specific to 152 authentication methods. The policy element provides the 153 mechanism for grouping a collection of authentication 154 attributes. 156 4.3 Authentication Attributes 158 Authentication attributes must be encoded as a multiple of 4 octets, 159 attributes that are not a multiple of 4 octets long must be padded 160 to a 4-octet boundary. 162 +--------+--------+--------+--------+ 163 | Length | A-Type |SubType | 164 +--------+--------+--------+--------+ 165 | Value � 166 +--------+--------+--------+--------+ 168 Length 169 The length field is two octets and indicates the actual length 170 of the attribute (including the Length and A-Type fields) in 171 number of octets. The length does not include any bytes padding 172 the attribute to make it multiple of 4 octets long. 174 A-Type 175 Authentication attribute type (A-Type) field is one octet. IANA 176 acts as a registry for A-Types as described in the section 10, 177 IANA Considerations. Initially, the registry contains the 178 following A-Types: 180 1 POLICY_LOCATOR Unique string for locating the 181 admission policy (such as X.500 DN 182 described in [RFC 1779]). 184 2 CREDENTIAL User credential such as Kerberos 185 ticket, or digital certificate. 186 Application credential such as 187 application ID. 189 3 DIGITAL_SIGNATURE Digital signature of the 190 authentication data policy element. 192 SubType 193 Authentication attribute sub-type field is one octet. Value of 194 SubType depends on A-type. 196 Value: 197 The value field contains 0-65351 octets. 199 Yadav, et al. 4 200 4.3.1 Policy Locator 202 POLICY_LOCATOR is used to locate the admission policy for the user 203 or application. Distinguished Name (DN) is unique for each User or 204 application hence a DN is used as policy locator. 206 +-------+-------+-------+-------+ 207 | Length |A-Type |SubType| 208 +-------+-------+-------+-------+ 209 | OctetString � 210 +-------+-------+-------+-------- 212 Length 213 > 4 215 A-Type 216 POLICY_LOCATOR 218 SubType 219 Following sub types for POLICY_LOCATOR are defined.IANA acts as 220 a registry for POLICY_LOCATOR sub types as described in the 221 section 10, IANA Considerations. Initially, the registry 222 contains the following sub types for POLICY_LOCATOR: 224 1 X500_DN OctetString contains the X.500 DN as described 225 in the RFC 1779 as an ASCII string. 227 2 UNICODE_DN OctetString contains the X.500 DN described in 228 the RFC 1779 as an UNICODE string. 230 3 X500_DN_ENCRYPT OctetString contains the encrypted X.500 DN. 231 The Kerberos session key or digital certificate 232 private key is used for encryption. For 233 Kerberos encryption the format is the same as 234 returned from gss_seal [RFC 1509]. 236 4 X500_UNICODE_DN_ENCRYPT OctetString contains the encrypted 237 UNICODE X.500 DN. The Kerberos session key or 238 digital certificate private key is used for 239 encryption. For Kerberos encryption the format 240 is the same as returned from gss_seal [RFC 241 1509]. 243 OctetString 244 The OctetString field contains the DN. 246 Yadav, et al. 5 247 4.3.2 Credential 249 CREDENTIAL indicates the credential of the user or application to be 250 authenticated. For Kerberos authentication method the CREDENTIAL 251 object contains the Kerberos session ticket. For public key based 252 authentication this field contains a digital certificate. 254 A summary of the CREDENTIAL attribute format is shown below. The 255 fields are transmitted from left to right. 257 +-------+-------+-------+-------+ 258 | Length |A-Type |SubType| 259 +-------+-------+-------+-------+ 260 | OctetString � 261 +-------+-------+-------+-------- 263 Length 264 > 4 266 A-Type 267 CREDENTIAL 269 SubType 270 IANA acts as a registry for CREDENTIAL sub types as described in 271 the section 10, IANA Considerations. Initially, the registry 272 contains the following sub types for CREDENTIAL: 274 1 ASCII_ID OctetString contains user or application 275 identification in plain ASCII text string. 277 2 UNICODE_ID OctetString contains user or application 278 identification in plain UNICODE text string. 280 3 KERBEROS_TKT OctetString contains Kerberos ticket. 282 4 X509_V3_CERT OctetString contains X.509 V3 digital 283 certificate [X.509]. 285 5 PGP_CERT OctetString contains PGP digital certificate. 287 OctetString 288 The OctetString contains the user or application credential. 290 4.3.3 Digital Signature 292 The DIGITAL_SIGNATURE attribute must be the last attribute in the 293 attribute list and contains the digital signature of the AUTH_DATA 294 policy element. The digital signature signs all data in the 295 AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm 296 used to compute the digital signature depends on the authentication 297 method specified by the CREDENTIAL SubType field. 299 Yadav, et al. 6 300 A summary of DIGITAL_SIGNATURE attribute format is described below. 302 +-------+-------+-------+-------+ 303 | Length |A-Type |SubType| 304 +-------+-------+-------+-------+ 305 | OctetString � 306 +-------+-------+-------+-------- 308 Length 309 > 4 311 A-Type 312 DIGITAL_SIGNATURE 314 SubType 315 No sub types for DIGITAL_SIGNATURE are currently defined. This 316 field must be set to 0. 318 OctetString 319 OctetString contains the digital signature of the AUTH_DATA. 321 5. Authentication Data Formats 323 Authentication attributes are grouped in a policy element to 324 represent the identity credentials. 326 5.1 Simple User Authentication 328 In simple user authentication method the user login ID (in plain 329 ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary 330 of the simple user AUTH_DATA policy element is shown below. 332 +--------------+--------------+--------------+--------------+ 333 | Length | P-type = AUTH_DATA | 334 +--------------+--------------+--------------+--------------+ 335 | IdentityType = AUTH_USER | 0 | 336 +--------------+--------------+--------------+--------------+ 337 | Length |POLICY_LOCATOR| SubType | 338 +--------------+--------------+--------------+--------------+ 339 | OctetString (User�s Distinguished Name) � 340 +--------------+--------------+--------------+--------------+ 341 | Length |CREDENTIAL | ASCII_ID | 342 +--------------+--------------+--------------+--------------+ 343 | OctetString (User�s login ID) � 344 +--------------+--------------+--------------+--------------+ 346 Yadav, et al. 7 347 5.2 Kerberos User Authentication 349 Kerberos [RFC 1510] authentication uses a trusted third party (the 350 Kerberos Distribution Center � KDC) to provide for authentication of 351 the user to a network server. It is assumed that a KDC is present 352 and both host and verifier of authentication information (router or 353 PDP) implement Kerberos authentication. 355 A summary of the Kerberos AUTH_DATA policy element is shown below. 357 +--------------+--------------+--------------+--------------+ 358 | Length | P-type (AUTH_DATA) | 359 +--------------+--------------+--------------+--------------+ 360 | IdentityType = AUTH_USER | 0 | 361 +--------------+--------------+--------------+--------------+ 362 | Length |POLICY_LOCATOR| SubType | 363 +--------------+--------------+--------------+--------------+ 364 | OctetString (User�s Distinguished Name) � 365 +--------------+--------------+--------------+--------------+ 366 | Length | CREDENTIAL | KERBEROS_TKT | 367 +--------------+--------------+--------------+--------------+ 368 | OctetString (Kerberos Session Ticket) � 369 +--------------+--------------+--------------+--------------+ 371 5.2.1. Operational Setting using Kerberos Identities 373 An RSVP enabled host is configured to construct and insert AUTH_DATA 374 policy element into RSVP messages that designate use of the Kerberos 375 authentication method (KERBEROS_TKT). Upon RSVP session 376 initialization, the user application contacts the KDC to obtain a 377 Kerberos ticket for the next network node or its PDP. A router when 378 generating a RSVP message contacts the KDC to obtain a Kerberos 379 ticket for the next hop network node or its PDP. The identity of the 380 PDP or next network hop can be statically configured, learned via 381 DHCP or maintained in a directory service. The Kerberos ticket is 382 sent to the next network node (which may be a router or host) in a 383 RSVP message. The KDC is used to validate the ticket and 384 authentication the user sending RSVP message. 386 5.3 Public Key based User Authentication 388 In public key based user authentication method digital certificate 389 is encoded as user credentials. The digital signature is used for 390 authenticating the user. A summary of the public key user AUTH_DATA 391 policy element is shown below. 393 Yadav, et al. 8 394 +--------------+--------------+--------------+--------------+ 395 | Length | P-type (AUTH_DATA) | 396 +--------------+--------------+--------------+--------------+ 397 | IdentityType = AUTH_USER | 0 | 398 +--------------+--------------+--------------+--------------+ 399 | Length |POLICY_LOCATOR| SubType | 400 +--------------+--------------+--------------+--------------+ 401 | OctetString (User�s Distinguished Name) � 402 +--------------+--------------+--------------+--------------+ 403 | Length | CREDENTIAL | SubType | 404 +--------------+--------------+--------------+--------------+ 405 | OctetString (User�s Digital Certificate)� 406 +--------------+--------------+--------------+--------------+ 407 | Length |DIGITAL_SIGN. | 0 | 408 +--------------+--------------+--------------+--------------+ 409 | OctetString (Digital signature) � 410 +--------------+--------------+--------------+--------------+ 412 5.3.1. Operational Setting for public key based authentication 414 Public key based authentication assumes following: 416 - RSVP service requestors have a pair of keys (private key and 417 public key). 419 - Private key is secured with the user. 421 - Public keys are stored in digital certificates and a trusted 422 party, certificate authority (CA) issues these digital 423 certificates. 425 - The verifier (PDP or router) has the ability to verify the 426 digital certificate. 428 RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. 429 User Authenticators (router, PDP) use the user�s public key (stored 430 in the digital certificate) to verify the signature and authenticate 431 the user. 433 Yadav, et al. 9 434 5.4 Simple Application Authentication 436 The application authentication method encodes the application 437 identification such as an executable filename as plain ASCII or 438 UNICODE text. 440 +----------------+--------------+--------------+--------------+ 441 | Length | P-type = AUTH_DATA | 442 +----------------+--------------+--------------+--------------+ 443 | IdentityType = AUTH_APP | 0 | 444 +----------------+--------------+--------------+--------------+ 445 | Length |POLICY_LOCATOR| SubType | 446 +----------------+--------------+--------------+--------------+ 447 | OctetString (Application Distinguished Name) � 448 +----------------+--------------+--------------+--------------+ 449 | Length | CREDENTIAL | ASCII_ID | 450 +----------------+--------------+--------------+--------------+ 451 | OctetString (Application Identification) 452 +----------------+--------------+--------------+--------------+ 454 6. Operation 456 +-----+ +-----+ 457 | PDP |-------+ | PDP | 458 +-----+ | �������������.��. +-----+ 459 | : : | 460 +--------+ : Transit : +-------+ 461 +----| Router |------: Network : -------| Router|--+ 462 | +--------+ : : +-------+ | 463 | | :��������������...: | | 464 | | | | 465 Host A B C D 467 Figure 1: User and Application Authentication using AUTH_DATA PE 469 Network nodes (hosts/routers) generate AUTH_DATA policy elements, 470 contents of which are depends on the identity type used and the 471 authentication method used. But generally contains authentication 472 credentials (Kerberos ticket or digital certificate) and policy 473 locators (which can be the X.500 Distinguished Name of the user or 474 network node or application names). Network nodes generate AUTH_DATA 475 policy element containing the authentication identity when making 476 the RSVP request or forwarding an RSVP message. 478 Network nodes generate user AUTH_DATA policy element using the 479 following rules 481 1. For unicast sessions the user policy locator is the copied from 482 the previous hop. The authentication credentials are for the 483 current network node identity. 485 Yadav, et al. 10 486 2. For multicast messages the user policy locator is for the current 487 network node identity. The authentication credentials are for the 488 current network node. 490 Network nodes generate application AUTH_DATA policy element using 491 the following rules: 493 1. For unicast sessions the application AUTH_DATA is the copied from 494 the previous hop. 496 2. For multicast messages the application AUTH_DATA is either the 497 first application AUTH_DATA in the message or chosen by the PDP. 499 7. Message Processing Rules 501 7.1 Message Generation (RSVP Host) 503 An RSVP message is created as specified in [RFC2205] with following 504 modifications. 506 1. RSVP message may contain multiple AUTH_DATA policy elements. Only 507 one AUTH_DATA of each IdentityType is allowed. 509 2. Authentication policy element (AUTH_DATA) is created and the 510 IdentityType field is modified to indicate the authentication 511 identity type being used. 513 - DN is inserted as POLICY_LOCATOR attribute. 515 - Credentials such as Kerberos ticket or digital certificate 516 are inserted as the CREDENTIAL attribute. 518 3. POLICY_DATA object is inserted in the RSVP message in appropriate 519 place with AUTH_DATA as one of the policy elements. If INTEGRITY 520 object is not computed for the RSVP message then an INTEGRITY 521 object must be computed for this POLICY_DATA object, as described 522 in the [POL_EXT], and must be inserted as an option. 524 7.2 Message Reception (Router) 526 RSVP message is processed as specified in [RFC2205] with following 527 modifications. 529 1. If router is not policy aware then it should send the RSVP 530 message to the PDP and wait for response. If the router is policy 531 unaware then it ignores the policy data objects and continues 532 processing the RSVP message. 534 2. Reject the message if the response from the PDP is negative. 536 Yadav, et al. 11 537 3. Continue processing the RSVP message. 539 7.3 Authentication (Router/PDP) 541 1. Retrieve the AUTH_DATA policy element. 543 2. Check the IdentityType field and return an error if the identity 544 type is not supported. 546 3. Verify credential 548 - Simple authentication: e.g. Get user ID and validate it, or 549 get executable name and validate it. 551 - Kerberos: Send the Kerberos ticket to the KDC to obtain the 552 session key. Using the session key authenticate the user. 554 - Public Key: Validate the certificate that it was issued by a 555 trusted Certificate Authority (CA) and authenticate the user 556 or application by verifying the digital signature. 558 8. Error Signaling 560 If PDP fails to verify the AUTH_DATA policy element then it must 561 indicate to the first hop router the Error Code = 02 (Policy control 562 failure). The PDP may specify error value field. These typically 563 include: 565 - Authentication method not supported 567 - Authentication failure 569 - Required attribute (specify) missing. For example CREDENTIAL 570 attribute missing. 572 - Unknown attribute (specify) type. 574 - Unknown attribute (specify) sub type. 576 9. IANA Considerations 578 Following the policies outlined in [IANA-CONSIDERATIONS], 579 IdentityType values in the range 0-32767 are allocated an IETF 580 Consensus action, IdentityType values between 32768-65535 are 581 reserved for Private Use and are not assigned by IANA. 583 Yadav, et al. 12 584 Following the policies outlined in [IANA-CONSIDERATIONS], 585 authentication attribute types (A-Type)in the range 0-127 are 586 allocated an IETF Consensus action, A-Type values between 128-255 587 are reserved for Private Use and are not assigned by IANA. 589 Following the policies outlined in [IANA-CONSIDERATIONS], 590 POLICY_LOCATOR SubType values in the range 0-127 are allocated an 591 IETF Consensus action, POLICY_LOCATOR SubType values between 128-255 592 are reserved for Private Use and are not assigned by IANA. 594 Following the policies outlined in [IANA-CONSIDERATIONS], 595 CREDENTIAL SubType values in the range 0-127 are allocated an IETF 596 Consensus action, CREDENTIAL SubType values between 128-255 are 597 reserved for Private Use and are not assigned by IANA. 599 10. Security Considerations 601 The purpose of this draft is to describe a mechanism to authenticate 602 RSVP requests based on user identity in a secure manner. RSVP 603 INTEGRITY object is used to protect the policy object containing 604 user identity information from security (replay) attacks. Combining 605 the AUTH_DATA policy element and the INTEGRITY object results in a 606 secure access control that enforces authentication based on both the 607 identity of the user and the identity of the originating node. 609 Simple authentication does not contain credential that can be 610 securely authenticated and is inherently less secured. 612 The Kerberos authentication mechanism is reasonably well secured. 614 User authentication using a public key certificate is known to 615 provide the strongest security. 617 11. Acknowledgments 619 We would like to thank Raj Yavatkar, Bob Linden and many others for 620 their valuable comments on this draft. 622 12. References 624 Yadav, et al. 13 626 [ASCII] Coded Character Set -- 7-Bit American Standard Code for 627 Information Interchange, ANSI X3.4-1986. 629 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 630 Writing an IANA Considerations Section in RFCs", BCP 26, 631 RFC 2434, October 1998. 633 [POL-EXT] Herzog, S., "RSVP Extensions for Policy Control." 634 Internet-Draft, draft-ietf-rap-policy-ext-01.txt, 635 November 1998. 637 [POL-FRAME] Yavatkar, R., et.al. "A Framework for Policy-based 638 Admission Control RSVP." Internet-Draft, draft-ietf-rap- 639 framework-01.txt, November 1998. 641 [RFC 1510] The Kerberos Network Authentication Service (V5). Kohl 642 J., Neuman, C. RFC 1510. 644 [RFC 1704] On Internet Authentication. Haller, N, Atkinson, R., 645 RFC 1704. 647 [RFC 1779] A String Representation of Distinguished Names. S. 648 Kille. RFC 1779 650 [RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol 651 (RSVP) � Version 1 Functional Specification." RFC 2205. 653 [RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol 654 (RSVP) - Version 1 Message Processing Rules." RFC 2209. 656 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 657 2.0", Addison-Wesley, Reading, MA, 1996. 659 [X.509] R. Housley, et. al., "Internet X.509 Public Key 660 Infrastructure Certificate and CRL Profile", Internet- 661 Draft, draft-ietf-pkix-ipki-part1-11.txt, September 662 1998. 664 [X.509-ITU] ITU-T (formerly CCITT) Information technology � Open 665 Systems Interconnection � The Directory: Authentication 666 Framework Recommendation X.509 ISO/IEC 9594-8 668 Yadav, et al. 14 669 13. Author Information 671 Satyendra Yadav 672 Intel, JF3-206 673 2111 NE 25th Avenue 674 Hillsboro, OR 97124 676 Satyendra.Yadav@intel.com 678 Ramesh Pabbati 679 Microsoft 680 1 Microsoft Way 681 Redmond, WA 98054 683 rameshpa@microsoft.com 685 Peter Ford 686 Microsoft 687 1 Microsoft Way 688 Redmond, WA 98054 690 peterf@microsoft.com 692 Tim Moore 693 Microsoft 694 1 Microsoft Way 695 Redmond, WA 98054 697 timmoore@microsoft.com 699 Shai Herzog 700 IPHighway 701 2055 Gateway Pl., Suite 400 702 San Jose, CA 95110 704 herzog@iphighway.com 706 Yadav, et al. 15 707 14. Full Copyright Statement 709 Copyright (C) The Internet Society (1999). All Rights Reserved. 711 This document and translations of it may be copied and furnished to 712 others, and derivative works that comment on or otherwise explain it 713 or assist in its implementation may be prepared, copied, published 714 and distributed, in whole or in part, without restriction of any 715 kind, provided that the above copyright notice and this paragraph 716 are included on all such copies and derivative works. However, this 717 document itself may not be modified in any way, such as by removing 718 the copyright notice or references to the Internet Society or other 719 Internet organizations, except as needed for the purpose of 720 developing Internet standards in which case the procedures for 721 copyrights defined in the Internet Standards process must be 722 followed, or as required to translate it into languages other than 723 English. 725 The limited permissions granted above are perpetual and will not be 726 revoked by the Internet Society or its successors or assigns. 728 This document and the information contained herein is provided on an 729 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 730 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 731 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 732 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 733 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 735 Yadav, et al. 16