idnits 2.17.1 draft-ietf-rap-rsvp-identity-04.txt: ** The Abstract section seems to be numbered 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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 1) 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 489 has weird spacing: '...form of a Dis...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The AUTH_DATA policy element in the PATH or RSVP message SHOULD not contain the POLICY_ERROR_OBJECT attribute. These are only inserted into PATH_ERROR and RESV_ERROR messages when generated by policy aware intermediate nodes. -- 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 (July 1999) is 9050 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 229, but not defined ** Obsolete undefined reference: RFC 1509 (Obsoleted by RFC 2744) == Missing Reference: 'RFC2205' is mentioned on line 568, but not defined == Unused Reference: 'ASCII' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC 1704' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC 2209' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 682, 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' ** 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: 13 errors (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Satyendra Yadav 2 Expiration: December 1999 Raj Yavatkar 3 File: draft-ietf-rap-rsvp-identity-04.txt Intel 4 Ramesh Pabbati 5 Peter Ford 6 Tim Moore 7 Microsoft 8 Shai Herzog 9 IPHighway 11 Identity Representation for RSVP 12 July 1999 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 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 and the 45 application of the communicating process (e.g. user id) and convey 46 this information in RSVP messages (PATH or RESV) in a secure manner. 47 We describe the encoding of identities as RSVP policy element. We 48 describe the processing rules to generate identity policy elements 49 for multicast merged flows. Subsequently, we describe 50 representations of user identities for Kerberos and Public Key based 51 user authentication mechanisms. In summary we describe the use of 52 this identity 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 or application is one of the prime 77 requirements. 79 In order to solve these problems and implement identity based policy 80 control it is required to identify the user and/or application 81 making a RSVP request. 83 This document proposes a mechanism for sending identification 84 information in the RSVP messages and enables authorization decisions 85 based on policy and identity. 87 We describe the authentication policy element (AUTH_DATA) contained 88 in the POLICY_DATA object. User process can generate an AUTH_DATA 89 policy element and gives it to RSVP process (service) on the 90 originating host. RSVP service inserts AUTH_DATA into the RSVP 91 message to identify the owner (user and/or application) making the 92 request for network resources. Network elements, such as routers, 93 authenticate request using the credentials presented in the 94 AUTH_DATA and admit the RSVP message based on admission policy. 95 After a request has been authenticated, first hop router installs 96 the RSVP state and forwards the new policy element returned by the 97 Policy Decision Point (PDP) [POL-FRAME]. 99 Yadav, et al. 2 100 4. Policy Element for Authentication Data 102 4.1 Policy Data Object Format 104 POLICY_DATA objects contain policy information and are carried by 105 RSVP messages. A detail description of the format of POLICY_DATA 106 object can be found in "RSVP Extensions for Policy Control" [POL- 107 EXT]. 109 4.2 Authentication Data Policy Element 111 In this section, we describe a policy element (PE) called 112 authentication data (AUTH_DATA). AUTH_DATA policy element contains a 113 list of authentication attributes. 115 +-------------+-------------+-------------+-------------+ 116 | Length | P-Type = Identity Type | 117 +-------------+-------------+-------------+-------------+ 118 // Authentication Attribute List // 119 +-------------------------------------------------------+ 121 Length 122 The length of the policy element (including the Length and P- 123 Type) is in number of octets (MUST be a multiple of 4) and 124 indicates the end of the authentication attribute list. 126 P-Type (Identity Type) 127 Type of identity information contained in this Policy Element 128 supplied as the Policy element type (P-type). The Internet 129 Assigned Numbers Authority (IANA) acts as a registry for policy 130 element types for identity as described in the [POL-EXT]. 131 Initially, the registry contains the following P-Types for 132 identity: 134 1 AUTH_USER Authentication scheme to identify users 136 2 AUTH_APP Authentication scheme to identify 137 applications 139 Authentication Attribute List 141 Authentication attributes contain information specific to 142 authentication method and type of AUTH_DATA. The policy element 143 provides the mechanism for grouping a collection of 144 authentication attributes. 146 Yadav, et al. 3 147 4.3 Authentication Attributes 149 Authentication attributes MUST be encoded as a multiple of 4 octets, 150 attributes that are not a multiple of 4 octets long MUST be padded 151 to a 4-octet boundary. 153 +--------+--------+--------+--------+ 154 | Length | A-Type |SubType | 155 +--------+--------+--------+--------+ 156 | Value ... 157 +--------+--------+--------+--------+ 159 Length 160 The length field is two octets and indicates the actual length 161 of the attribute (including the Length and A-Type fields) in 162 number of octets. The length does not include any bytes padding 163 to the value field to make the attribute multiple of 4 octets 164 long. 166 A-Type 167 Authentication attribute type (A-Type) field is one octet. IANA 168 acts as a registry for A-Types as described in the section 9, 169 IANA Considerations. Initially, the registry contains the 170 following A-Types: 172 1 POLICY_LOCATOR Unique string for locating the 173 admission policy (such as X.500 DN 174 described in [RFC 1779]). 176 2 CREDENTIAL User credential such as Kerberos 177 ticket, or digital certificate. 178 Application credential such as 179 application ID. 181 3 DIGITAL_SIGNATURE Digital signature of the 182 authentication data policy element. 184 4 POLICY_ERROR_OBJECT Detailed information on policy 185 failures. 187 SubType 188 Authentication attribute sub-type field is one octet. Value of 189 SubType depends on A-type. 191 Value: 192 The value field contains the attribute specific information. 194 Yadav, et al. 4 195 4.3.1 Policy Locator 197 POLICY_LOCATOR is used to locate the admission policy for the user 198 or application. Distinguished Name (DN) is unique for each User or 199 application hence a DN is used as policy locator. 201 +-------+-------+-------+-------+ 202 | Length |A-Type |SubType| 203 +-------+-------+-------+-------+ 204 | OctetString ... 205 +-------+-------+-------+-------- 207 Length 208 Length of the attribute, which MUST be >= 4. 210 A-Type 211 POLICY_LOCATOR 213 SubType 214 Following sub types for POLICY_LOCATOR are defined. IANA acts as 215 a registry for POLICY_LOCATOR sub types as described in the 216 section 9, IANA Considerations. Initially, the registry contains 217 the following sub types for POLICY_LOCATOR: 219 1 ASCII_DN OctetString contains the X.500 DN as described 220 in the RFC 1779 as an ASCII string. 222 2 UNICODE_DN OctetString contains the X.500 DN described in 223 the RFC 1779 as an UNICODE string. 225 3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500 226 DN. The Kerberos session key or digital 227 certificate private key is used for encryption. 228 For Kerberos encryption the format is the same 229 as returned from gss_seal [RFC 1509]. 231 4 UNICODE_DN_ENCRYPT OctetString contains the encrypted 232 UNICODE X.500 DN. The Kerberos session key or 233 digital certificate private key is used for 234 encryption. For Kerberos encryption the format 235 is the same as returned from gss_seal [RFC 236 1509]. 238 OctetString 239 The OctetString field contains the DN. 241 Yadav, et al. 5 242 4.3.2 Credential 244 CREDENTIAL indicates the credential of the user or application to be 245 authenticated. For Kerberos authentication method the CREDENTIAL 246 object contains the Kerberos session ticket. For public key based 247 authentication this field contains a digital certificate. 249 A summary of the CREDENTIAL attribute format is shown below. The 250 fields are transmitted from left to right. 252 +-------+-------+-------+-------+ 253 | Length |A-Type |SubType| 254 +-------+-------+-------+-------+ 255 | OctetString ... 256 +-------+-------+-------+-------- 258 Length 259 Length of the attribute, which MUST be >= 4. 261 A-Type 262 CREDENTIAL 264 SubType 265 IANA acts as a registry for CREDENTIAL sub types as described in 266 the section 9, IANA Considerations. Initially, the registry 267 contains the following sub types for CREDENTIAL: 269 1 ASCII_ID OctetString contains user or application 270 identification in plain ASCII text string. 272 2 UNICODE_ID OctetString contains user or application 273 identification in plain UNICODE text string. 275 3 KERBEROS_TKT OctetString contains Kerberos ticket. 277 4 X509_V3_CERT OctetString contains X.509 V3 digital 278 certificate [X.509]. 280 5 PGP_CERT OctetString contains PGP digital certificate. 282 OctetString 283 The OctetString contains the user or application credential. 285 4.3.3 Digital Signature 287 The DIGITAL_SIGNATURE attribute MUST be the last attribute in the 288 attribute list and contains the digital signature of the AUTH_DATA 289 policy element. The digital signature signs all data in the 290 AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm 291 used to compute the digital signature depends on the authentication 292 method specified by the CREDENTIAL SubType field. 294 Yadav, et al. 6 295 A summary of DIGITAL_SIGNATURE attribute format is described below. 297 +-------+-------+-------+-------+ 298 | Length |A-Type |SubType| 299 +-------+-------+-------+-------+ 300 | OctetString ... 301 +-------+-------+-------+-------- 303 Length 304 Length of the attribute, which MUST be >= 4. 306 A-Type 307 DIGITAL_SIGNATURE 309 SubType 310 No sub types for DIGITAL_SIGNATURE are currently defined. This 311 field MUST be set to 0. 313 OctetString 314 OctetString contains the digital signature of the AUTH_DATA. 316 4.3.4 Policy Error Object 318 This attribute is used to specify any errors associated with the 319 policy element. When a RSVP policy node (local policy decision point 320 or remote PDP) encounters a request that fails policy control due to 321 its Authentication Policy Element, it MAY add a POLICY_ERROR_CODE 322 containing additional information about the reason the failure 323 occurred into the policy element. This will then cause an 324 appropriate PATH_ERROR or RESV_ERROR message to be generated with 325 the policy element and appropriate RSVP error code in the message, 326 which is returned to the request's source. 328 The AUTH_DATA policy element in the PATH or RSVP message SHOULD not 329 contain the POLICY_ERROR_OBJECT attribute. These are only inserted 330 into PATH_ERROR and RESV_ERROR messages when generated by policy 331 aware intermediate nodes. 333 +----------+----------+----------+----------+ 334 | Length | A-Type |SubType(0)| 335 +----------+----------+----------+----------+ 336 | 0 (Reserved) | ErrorValue | 337 +----------+----------+----------+----------+ 338 | OctetString ... 339 +----------+----------+----------+----------+ 341 Length 342 Length of the attribute, which MUST be >= 8. 344 Yadav, et al. 7 345 A-Type 346 POLICY_ERROR_CODE 348 ErrorValue 349 A 32-bit bit code containing the reason that the policy decision 350 point failed to process the policy element. Following values 351 have been defined. 353 1 ERROR_NO_MORE_INFO No information is available. 354 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is 355 not supported. 357 3 INSUFFICIENT_PRIVILEGES The credentials do not have 358 sufficient privilege. 360 4 EXPIRED_CREDENTIAL The credential has expired. 362 5 IDENTITY_CHANGED Identity has changed. 364 OctetString 365 The OctetString field contains information from the policy 366 decision point that MAY contain additional information about 367 the policy failure. For example, it may include a human- 368 readable message in the ASCII text. 370 5. Authentication Data Formats 372 Authentication attributes are grouped in a policy element to 373 represent the identity credentials. 375 5.1 Simple User Authentication 377 In simple user authentication method the user login ID (in plain 378 ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary 379 of the simple user AUTH_DATA policy element is shown below. 381 +--------------+--------------+--------------+--------------+ 382 | Length | P-type = AUTH_USER | 383 +--------------+--------------+--------------+--------------+ 384 | Length |POLICY_LOCATOR| SubType | 385 +--------------+--------------+--------------+--------------+ 386 | OctetString (User's Distinguished Name) ... 387 +--------------+--------------+--------------+--------------+ 388 | Length |CREDENTIAL | ASCII_ID | 389 +--------------+--------------+--------------+--------------+ 390 | OctetString (User's login ID) ... 391 +--------------+--------------+--------------+--------------+ 393 Yadav, et al. 8 394 5.2 Kerberos User Authentication 396 Kerberos [RFC 1510] authentication uses a trusted third party (the 397 Kerberos Distribution Center - KDC) to provide for authentication of 398 the user to a network server. It is assumed that a KDC is present 399 and both host and verifier of authentication information (router or 400 PDP) implement Kerberos authentication. 402 A summary of the Kerberos AUTH_DATA policy element is shown below. 404 +--------------+--------------+--------------+--------------+ 405 | Length | P-type = AUTH_USER | 406 +--------------+--------------+--------------+--------------+ 407 | Length |POLICY_LOCATOR| SubType | 408 +--------------+--------------+--------------+--------------+ 409 | OctetString (User's Distinguished Name) ... 410 +--------------+--------------+--------------+--------------+ 411 | Length | CREDENTIAL | KERBEROS_TKT | 412 +--------------+--------------+--------------+--------------+ 413 | OctetString (Kerberos Session Ticket) ... 414 +--------------+--------------+--------------+--------------+ 416 5.2.1. Operational Setting using Kerberos Identities 418 An RSVP enabled host is configured to construct and insert AUTH_DATA 419 policy element into RSVP messages that designate use of the Kerberos 420 authentication method (KERBEROS_TKT). Upon RSVP session 421 initialization, the user application contacts the KDC to obtain a 422 Kerberos ticket for the next network node or its PDP. A router when 423 generating a RSVP message contacts the KDC to obtain a Kerberos 424 ticket for the next hop network node or its PDP. The identity of the 425 PDP or next network hop can be statically configured, learned via 426 DHCP or maintained in a directory service. The Kerberos ticket is 427 sent to the next network node (which may be a router or host) in a 428 RSVP message. The KDC is used to validate the ticket and 429 authentication the user sending RSVP message. 431 Yadav, et al. 9 432 5.3 Public Key based User Authentication 434 In public key based user authentication method digital certificate 435 is encoded as user credentials. The digital signature is used for 436 authenticating the user. A summary of the public key user AUTH_DATA 437 policy element is shown below. 439 +--------------+--------------+--------------+--------------+ 440 | Length | P-type = AUTH_USER | 441 +--------------+--------------+--------------+--------------+ 442 | Length |POLICY_LOCATOR| SubType | 443 +--------------+--------------+--------------+--------------+ 444 | OctetString (User's Distinguished Name) ... 445 +--------------+--------------+--------------+--------------+ 446 | Length | CREDENTIAL | SubType | 447 +--------------+--------------+--------------+--------------+ 448 | OctetString (User's Digital Certificate) ... 449 +--------------+--------------+--------------+--------------+ 450 | Length |DIGITAL_SIGN. | 0 | 451 +--------------+--------------+--------------+--------------+ 452 | OctetString (Digital signature) ... 453 +--------------+--------------+--------------+--------------+ 455 5.3.1. Operational Setting for public key based authentication 457 Public key based authentication assumes following: 459 - RSVP service requestors have a pair of keys (private key and 460 public key). 462 - Private key is secured with the user. 464 - Public keys are stored in digital certificates and a trusted 465 party, certificate authority (CA) issues these digital 466 certificates. 468 - The verifier (PDP or router) has the ability to verify the 469 digital certificate. 471 RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. 472 User Authenticators (router, PDP) use the user's public key (stored 473 in the digital certificate) to verify the signature and authenticate 474 the user. 476 Yadav, et al. 10 477 5.4 Simple Application Authentication 479 The application authentication method encodes the application 480 identification such as an executable filename as plain ASCII or 481 UNICODE text. 483 +----------------+--------------+--------------+--------------+ 484 | Length | P-type = AUTH_APP | 485 +----------------+--------------+--------------+--------------+ 486 | Length |POLICY_LOCATOR| SubType | 487 +----------------+--------------+--------------+--------------+ 488 | OctetString (Application Identity attributes in 489 | the form of a Distinguished Name) ... 490 +----------------+--------------+--------------+--------------+ 491 | Length | CREDENTIAL | ASCII_ID | 492 +----------------+--------------+--------------+--------------+ 493 | OctetString (Application Id, e.g., vic.exe) 494 +----------------+--------------+--------------+--------------+ 496 6. Operation 498 +-----+ +-----+ 499 | PDP |-------+ | PDP | 500 +-----+ | ................... +-----+ 501 | : : | 502 +--------+ : Transit : +-------+ 503 +----| Router |------: Network : -------| Router|--+ 504 | +--------+ : : +-------+ | 505 | | :.................: | | 506 | | | | 507 Host A B C D 509 Figure 1: User and Application Authentication using AUTH_DATA PE 511 Network nodes (hosts/routers) generate AUTH_DATA policy elements, 512 contents of which are depend on the identity type used and the 513 authentication method used. These generally contain authentication 514 credentials (Kerberos ticket or digital certificate) and policy 515 locators (which can be the X.500 Distinguished Name of the user or 516 network node or application names). Network nodes generate AUTH_DATA 517 policy element containing the authentication identity when making the 518 RSVP request or forwarding a RSVP message. 520 Network nodes generate user AUTH_DATA policy element using the 521 following rules 523 1. For unicast sessions the user policy locator is copied from the 524 previous hop. The authentication credentials are for the current 525 network node identity. 527 Yadav, et al. 11 528 2. For multicast messages the user policy locator is for the current 529 network node identity. The authentication credentials are for the 530 current network node. 532 Network nodes generate application AUTH_DATA policy element using the 533 following rules: 535 1. For unicast sessions the application AUTH_DATA is copied from the 536 previous hop. 538 2. For multicast messages the application AUTH_DATA is either the 539 first application AUTH_DATA in the message or chosen by the PDP. 541 7. Message Processing Rules 543 7.1 Message Generation (RSVP Host) 545 An RSVP message is created as specified in [RFC2205] with following 546 modifications. 548 1. RSVP message MAY contain multiple AUTH_DATA policy elements. 550 2. Authentication policy element (AUTH_DATA) is created and the 551 IdentityType field is set to indicate the identity type in the 552 policy element. 554 - DN is inserted as POLICY_LOCATOR attribute. 556 - Credentials such as Kerberos ticket or digital certificate 557 are inserted as the CREDENTIAL attribute. 559 3. POLICY_DATA object (containing the AUTH_DATA policy element) is 560 inserted in the RSVP message in appropriate place. If INTEGRITY 561 object is not computed for the RSVP message then an INTEGRITY 562 object SHOULD be computed for this POLICY_DATA object, as 563 described in the [POL_EXT], and SHOULD be inserted as a Policy 564 Data option. 566 7.2 Message Reception (Router) 568 RSVP message is processed as specified in [RFC2205] with following 569 modifications. 571 1. If router is not policy aware then it SHOULD send the RSVP 572 message to the PDP and wait for response. If the router is policy 573 unaware then it ignores the policy data objects and continues 574 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 Yadav, et al. 12 581 7.3 Authentication (Router/PDP) 583 1. Retrieve the AUTH_DATA policy element. Check the PE type field 584 and return an error if the identity type is not supported. 586 2. Verify user credential 588 - Simple authentication: e.g. Get user ID and validate it, or 589 get executable name and validate it. 591 - Kerberos: Send the Kerberos ticket to the KDC to obtain the 592 session key. Using the session key authenticate the user. 594 - Public Key: Validate the certificate that it was issued by a 595 trusted Certificate Authority (CA) and authenticate the user 596 or application by verifying the digital signature. 598 8. Error Signaling 600 If PDP fails to verify the AUTH_DATA policy element then it MUST 601 return policy control failure (Error Code = 02) to the PEP. The 602 error values are described in [RFC 2205] and [POL-EXT]. Also PDP 603 SHOULD supply a policy data object containing the AUTH_DATA Policy 604 Element with more details on the Policy Control failures in the 605 policy error object attribute. The PEP will include this Policy Data 606 object in the outgoing RSVP Error message. 608 9. IANA Considerations 610 Following the policies outlined in [IANA-CONSIDERATIONS], 611 authentication attribute types (A-Type)in the range 0-127 are 612 allocated an IETF Consensus action, A-Type values between 128-255 613 are reserved for Private Use and are not assigned by IANA. 615 Following the policies outlined in [IANA-CONSIDERATIONS], 616 POLICY_LOCATOR SubType values in the range 0-127 are allocated an 617 IETF Consensus action, POLICY_LOCATOR SubType values between 128-255 618 are reserved for Private Use and are not assigned by IANA. 620 Following the policies outlined in [IANA-CONSIDERATIONS], 621 CREDENTIAL SubType values in the range 0-127 are allocated an IETF 622 Consensus action, CREDENTIAL SubType values between 128-255 are 623 reserved for Private Use and are not assigned by IANA. 625 Yadav, et al. 13 626 10. Security Considerations 628 The purpose of this draft is to describe a mechanism to authenticate 629 RSVP requests based on user identity in a secure manner. RSVP 630 INTEGRITY object is used to protect the policy object containing 631 user identity information from security (replay) attacks. Combining 632 the AUTH_DATA policy element and the INTEGRITY object results in a 633 secure access control that enforces authentication based on both the 634 identity of the user and the identity of the originating node. 636 Simple authentication does not contain credential that can be 637 securely authenticated and is inherently less secured. 639 The Kerberos authentication mechanism is reasonably well secured. 641 User authentication using a public key certificate is known to 642 provide the strongest security. 644 11. Acknowledgments 646 We would like to thank Andrew Smith, Bob Lindell and many others for 647 their valuable comments on this draft. 649 Yadav, et al. 14 650 12. References 652 [ASCII] Coded Character Set -- 7-Bit American Standard Code for 653 Information Interchange, ANSI X3.4-1986. 655 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 656 Writing an IANA Considerations Section in RFCs", BCP 26, 657 RFC 2434, October 1998. 659 [POL-EXT] Herzog, S., "RSVP Extensions for Policy Control." 660 Internet-Draft, draft-ietf-rap-policy-ext-06.txt, April 661 1999. 663 [POL-FRAME] Yavatkar, R., et.al. "A Framework for Policy-based 664 Admission Control RSVP." Internet-Draft, draft-ietf-rap- 665 framework-03.txt, April 1999. 667 [RFC 1510] The Kerberos Network Authentication Service (V5). Kohl 668 J., Neuman, C. RFC 1510. 670 [RFC 1704] On Internet Authentication. Haller, N, Atkinson, R., 671 RFC 1704. 673 [RFC 1779] A String Representation of Distinguished Names. S. 674 Kille. RFC 1779 676 [RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol 677 (RSVP) - Version 1 Functional Specification." RFC 2205. 679 [RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol 680 (RSVP) - Version 1 Message Processing Rules." RFC 2209. 682 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 683 2.0", Addison-Wesley, Reading, MA, 1996. 685 [X.509] R. Housley, et. al., "Internet X.509 Public Key 686 Infrastructure Certificate and CRL Profile", Internet- 687 Draft, draft-ietf-pkix-ipki-part1-11.txt, September 688 1998. 690 [X.509-ITU] ITU-T (formerly CCITT) Information technology - Open 691 Systems Interconnection - The Directory: Authentication 692 Framework Recommendation X.509 ISO/IEC 9594-8 694 Yadav, et al. 15 695 13. Author Information 697 Satyendra Yadav 698 Intel, JF3-206 699 2111 NE 25th Avenue 700 Hillsboro, OR 97124 702 Satyendra.Yadav@intel.com 704 Raj Yavatkar 705 Intel, JF3-206 706 2111 NE 25th Avenue 707 Hillsboro, OR 97124 709 Raj.Yavatkar@intel.com 711 Ramesh Pabbati 712 Microsoft 713 1 Microsoft Way 714 Redmond, WA 98054 716 rameshpa@microsoft.com 718 Peter Ford 719 Microsoft 720 1 Microsoft Way 721 Redmond, WA 98054 723 peterf@microsoft.com 725 Tim Moore 726 Microsoft 727 1 Microsoft Way 728 Redmond, WA 98054 730 timmoore@microsoft.com 732 Shai Herzog 733 IPHighway 734 2055 Gateway Pl., Suite 400 735 San Jose, CA 95110 737 herzog@iphighway.com 739 Yadav, et al. 16 740 14. Full Copyright Statement 742 Copyright (C) The Internet Society (1999). All Rights Reserved. 744 This document and translations of it may be copied and furnished to 745 others, and derivative works that comment on or otherwise explain it 746 or assist in its implementation may be prepared, copied, published 747 and distributed, in whole or in part, without restriction of any 748 kind, provided that the above copyright notice and this paragraph 749 are included on all such copies and derivative works. However, this 750 document itself may not be modified in any way, such as by removing 751 the copyright notice or references to the Internet Society or other 752 Internet organizations, except as needed for the purpose of 753 developing Internet standards in which case the procedures for 754 copyrights defined in the Internet Standards process must be 755 followed, or as required to translate it into languages other than 756 English. 758 The limited permissions granted above are perpetual and will not be 759 revoked by the Internet Society or its successors or assigns. 761 This document and the information contained herein is provided on an 762 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 763 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 764 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 765 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 766 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 768 Yadav, et al. 17