idnits 2.17.1 draft-ietf-rap-rsvp-better-identity-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 1 longer page, the longest (page 16) being 63 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. -- The draft header indicates that this document obsoletes RFC2752, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 491 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 (June 2001) is 8350 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 68, but not defined == Missing Reference: 'RFC 1633' is mentioned on line 72, but not defined == Missing Reference: 'RFC 1509' is mentioned on line 232, but not defined ** Obsolete undefined reference: RFC 1509 (Obsoleted by RFC 2744) == Missing Reference: 'RFC2205' is mentioned on line 569, but not defined == Unused Reference: 'ASCII' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC 1704' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'RFC 2209' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 715, 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) -- Possible downref: Normative reference to a draft: ref. 'POL-EXT' ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'POL-FRAME') -- Possible downref: Normative reference to a draft: ref. 'POLICY-MD5' ** 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: 12 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAP Working Group R. Hess, Ed. 3 Internet-Draft S. Yadav 4 Obsoletes: 2752 R. Yavatkar 5 Expires December 2001 Intel 6 R. Pabbati 7 P. Ford 8 T. Moore 9 Microsoft 10 S. Herzog 11 IPHighway 12 June 2001 14 Identity Representation for RSVP 16 draft-ietf-rap-rsvp-better-identity-00.txt 18 Status of this Memo 20 This document is an Internet-Draft and is subject to all provisions 21 of Section 10 of RFC2026. Internet-Drafts are working documents of 22 the Internet Engineering Task Force (IETF), its areas, and its 23 working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 The distribution of this memo is unlimited. This memo is filed as 38 and expires December 31, 39 2001. Please send comments to the author. 41 Copyright Notice 43 Copyright (C) The Internet Society (2001). All Rights Reserved. 45 Abstract 47 This document describes the representation of identity information in 48 POLICY_DATA objects [POL-EXT] for supporting policy based admission 49 control in RSVP. The goal of identity representation is to allow a 50 process on a system to securely identify the owner and the 51 application of the communicating process (e.g. user id) and convey 52 this information in RSVP messages (PATH or RESV) in a secure manner. 53 We describe the encoding of identities as a RSVP policy element. We 54 describe the processing rules to generate identity policy elements 55 for multicast merged flows. Subsequently, we describe 56 representations of user identities for Kerberos and Public Key based 57 user authentication mechanisms. In summary we describe the use of 58 this identity information in an operational setting. 60 This memo updates the Security Considerations Section to correctly 61 reflect how various security issues are addressed. 63 1. Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC-2119]. 69 2. Introduction 71 RSVP [RFC 2205] is a resource reservation setup protocol designed for 72 an integrated services Internet [RFC 1633]. RSVP is used by a host to 73 request specific quality of service (QoS) from the network for 74 particular application data streams or flows. RSVP is also used by 75 routers to deliver QoS requests to all nodes along the path(s) of the 76 flows and to establish and maintain state to provide the requested 77 service. RSVP requests will generally result in resources being 78 reserved in each node along the data path. RSVP allows particular 79 users to obtain preferential access to network resources, under the 80 control of an admission control mechanism. Permission to make a 81 reservation is based both upon the availability of the requested 82 resources along the path of the data and upon satisfaction of policy 83 rules. Providing policy based admission control mechanism based on 84 user identity or application is one of the prime requirements. 86 In order to solve these problems and implement identity based policy 87 control it is required to identify the user and/or application making 88 a RSVP request. 90 This document proposes a mechanism for sending identification 91 information in the RSVP messages and enables authorization decisions 92 based on policy and identity. 94 We describe the authentication policy element (AUTH_DATA) contained 95 in the POLICY_DATA object. User process can generate an AUTH_DATA 96 policy element and gives it to RSVP process (service) on the 97 originating host. RSVP service inserts AUTH_DATA into the RSVP 98 message to identify the owner (user and/or application) making the 99 request for network resources. Network elements, such as routers, 100 authenticate request using the credentials presented in the AUTH_DATA 101 and admit the RSVP message based on admission policy. After a request 102 has been authenticated, first hop router installs the RSVP state and 103 forwards the new policy element returned by the Policy Decision Point 104 (PDP) [POL-FRAME]. 106 3. Policy Element for Authentication Data 108 3.1 Policy Data Object Format 110 POLICY_DATA objects contain policy information and are carried by 111 RSVP messages. A detail description of the format of POLICY_DATA 112 object can be found in "RSVP Extensions for Policy Control" [POL- 113 EXT]. 115 3.2 Authentication Data Policy Element 117 In this section, we describe a policy element (PE) called 118 authentication data (AUTH_DATA). AUTH_DATA policy element contains a 119 list of authentication attributes. 121 +-------------+-------------+-------------+-------------+ 122 | Length | P-Type = Identity Type | 123 +-------------+-------------+-------------+-------------+ 124 // Authentication Attribute List // 125 +-------------------------------------------------------+ 127 Length 128 The length of the policy element (including the Length and P- 129 Type) is in number of octets (MUST be a multiple of 4) and 130 indicates the end of the authentication attribute list. 132 P-Type (Identity Type) 133 Type of identity information contained in this Policy Element 134 supplied as the Policy element type (P-type). The Internet 135 Assigned Numbers Authority (IANA) acts as a registry for policy 136 element types for identity as described in the [POL-EXT]. 137 Initially, the registry contains the following P-Types for 138 identity: 140 2 AUTH_USER Authentication scheme to identify users 142 3 AUTH_APP Authentication scheme to identify 143 applications 145 Authentication Attribute List 147 Authentication attributes contain information specific to 148 authentication method and type of AUTH_DATA. The policy element 149 provides the mechanism for grouping a collection of 150 authentication attributes. 152 3.3 Authentication Attributes 154 Authentication attributes MUST be encoded as a multiple of 4 octets, 155 attributes that are not a multiple of 4 octets long MUST be padded to 156 a 4-octet boundary. 158 +--------+--------+--------+--------+ 159 | Length | A-Type |SubType | 160 +--------+--------+--------+--------+ 161 | Value ... 162 +--------+--------+--------+--------+ 164 Length 165 The length field is two octets and indicates the actual length of 166 the attribute (including the Length and A-Type fields) in number 167 of octets. The length does not include any bytes padding to the 168 value field to make the attribute multiple of 4 octets long. 170 A-Type 171 Authentication attribute type (A-Type) field is one octet. IANA 172 acts as a registry for A-Types as described in the section 9, 173 IANA Considerations. Initially, the registry contains the 174 following A-Types: 176 1 POLICY_LOCATOR Unique string for locating the 177 admission policy (such as X.500 DN 178 described in [RFC 1779]). 180 2 CREDENTIAL User credential such as Kerberos 181 ticket, or digital certificate. 182 Application credential such as 183 application ID. 185 3 DIGITAL_SIGNATURE Digital signature of the 186 authentication data policy element. 188 4 POLICY_ERROR_OBJECT Detailed information on policy 189 failures. 191 SubType 192 Authentication attribute sub-type field is one octet. Value of 193 SubType depends on A-type. 195 Value: 196 The value field contains the attribute specific information. 198 3.3.1 Policy Locator 200 POLICY_LOCATOR is used to locate the admission policy for the user 201 or application. Distinguished Name (DN) is unique for each User or 202 application hence a DN is used as policy locator. 204 +-------+-------+-------+-------+ 205 | Length |A-Type |SubType| 206 +-------+-------+-------+-------+ 207 | OctetString ... 208 +-------+-------+-------+-------- 210 Length 211 Length of the attribute, which MUST be >= 4. 213 A-Type 214 POLICY_LOCATOR 216 SubType 217 Following sub types for POLICY_LOCATOR are defined. IANA acts as 218 a registry for POLICY_LOCATOR sub types as described in the 219 section 9, IANA Considerations. Initially, the registry contains 220 the following sub types for POLICY_LOCATOR: 222 1 ASCII_DN OctetString contains the X.500 DN as described 223 in the RFC 1779 as an ASCII string. 225 2 UNICODE_DN OctetString contains the X.500 DN described in 226 the RFC 1779 as an UNICODE string. 228 3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500 229 DN. The Kerberos session key or digital 230 certificate private key is used for encryption. 231 For Kerberos encryption the format is the same 232 as returned from gss_seal [RFC 1509]. 234 4 UNICODE_DN_ENCRYPT OctetString contains the encrypted 235 UNICODE X.500 DN. The Kerberos session key or 236 digital certificate private key is used for 237 encryption. For Kerberos encryption the format 238 is the same as returned from gss_seal [RFC 239 1509]. 241 OctetString 242 The OctetString field contains the DN. 244 3.3.2 Credential 246 CREDENTIAL indicates the credential of the user or application to be 247 authenticated. For Kerberos authentication method the CREDENTIAL 248 object contains the Kerberos session ticket. For public key based 249 authentication this field contains a digital certificate. 251 A summary of the CREDENTIAL attribute format is shown below. The 252 fields are transmitted from left to right. 254 +-------+-------+-------+-------+ 255 | Length |A-Type |SubType| 256 +-------+-------+-------+-------+ 257 | OctetString ... 258 +-------+-------+-------+-------- 260 Length 261 Length of the attribute, which MUST be >= 4. 263 A-Type 264 CREDENTIAL 266 SubType 267 IANA acts as a registry for CREDENTIAL sub types as described in 268 the section 9, IANA Considerations. Initially, the registry 269 contains the following sub types for CREDENTIAL: 271 1 ASCII_ID OctetString contains user or application 272 identification in plain ASCII text string. 274 2 UNICODE_ID OctetString contains user or application 275 identification in plain UNICODE text string. 277 3 KERBEROS_TKT OctetString contains Kerberos ticket. 279 4 X509_V3_CERT OctetString contains X.509 V3 digital 280 certificate [X.509]. 282 5 PGP_CERT OctetString contains PGP digital certificate. 284 OctetString 285 The OctetString contains the user or application credential. 287 3.3.3 Digital Signature 289 The DIGITAL_SIGNATURE attribute MUST be the last attribute in the 290 attribute list and contains the digital signature of the AUTH_DATA 291 policy element. The digital signature signs all data in the 292 AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm 293 used to compute the digital signature depends on the authentication 294 method specified by the CREDENTIAL SubType field. 296 A summary of DIGITAL_SIGNATURE attribute format is described below. 298 +-------+-------+-------+-------+ 299 | Length |A-Type |SubType| 300 +-------+-------+-------+-------+ 301 | OctetString ... 302 +-------+-------+-------+-------- 304 Length 305 Length of the attribute, which MUST be >= 4. 307 A-Type 308 DIGITAL_SIGNATURE 310 SubType 311 No sub types for DIGITAL_SIGNATURE are currently defined. This 312 field MUST be set to 0. 314 OctetString 315 OctetString contains the digital signature of the AUTH_DATA. 317 3.3.4 Policy Error Object 319 This attribute is used to carry any specific policy control errors 320 generated by a node when processing/validating an Authentication Data 321 Policy Element. When a RSVP policy node (local policy decision point 322 or remote PDP) encounters a request that fails policy control due to 323 its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE 324 containing additional information about the reason the failure 325 occurred into the policy element. This will then cause an appropriate 326 PATH_ERROR or RESV_ERROR message to be generated with the policy 327 element and appropriate RSVP error code in the message, which is 328 returned to the request's source. 330 The AUTH_DATA policy element in the PATH or RSVP message SHOULD not 331 contain the POLICY_ERROR_OBJECT attribute. These are only inserted 332 into PATH_ERROR and RESV_ERROR messages when generated by policy 333 aware intermediate nodes. 335 +----------+----------+----------+----------+ 336 | Length | A-Type | SubType | 337 +----------+----------+----------+----------+ 338 | 0 (Reserved) | ErrorValue | 339 +----------+----------+----------+----------+ 340 | OctetString ... 341 +----------+----------+----------+----------+ 343 Length 344 Length of the attribute, which MUST be >= 8. 346 A-Type 347 POLICY_ERROR_CODE 349 SubType 350 No sub types for POLICY_ERROR_CODE are currently defined. This 351 field MUST be set to 0. 353 ErrorValue 354 A 32-bit bit code containing the reason that the policy decision 355 point failed to process the policy element. Following values have 356 been defined. 358 1 ERROR_NO_MORE_INFO No information is available. 359 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is 360 not supported. 362 3 INSUFFICIENT_PRIVILEGES The credentials do not have 363 sufficient privilege. 365 4 EXPIRED_CREDENTIAL The credential has expired. 367 5 IDENTITY_CHANGED Identity has changed. 369 OctetString 370 The OctetString field contains information from the policy 371 decision point that MAY contain additional information about the 372 policy failure. For example, it may include a human-readable 373 message in the ASCII text. 375 4. Authentication Data Formats 377 Authentication attributes are grouped in a policy element to 378 represent the identity credentials. 380 4.1 Simple User Authentication 382 In simple user authentication method the user login ID (in plain 383 ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary 384 of the simple user AUTH_DATA policy element is shown below. 386 +--------------+--------------+--------------+--------------+ 387 | Length | P-type = AUTH_USER | 388 +--------------+--------------+--------------+--------------+ 389 | Length |POLICY_LOCATOR| SubType | 390 +--------------+--------------+--------------+--------------+ 391 | OctetString (User's Distinguished Name) ... 392 +--------------+--------------+--------------+--------------+ 393 | Length |CREDENTIAL | ASCII_ID | 394 +--------------+--------------+--------------+--------------+ 395 | OctetString (User's login ID) ... 396 +--------------+--------------+--------------+--------------+ 398 4.2 Kerberos User Authentication 400 Kerberos [RFC 1510] authentication uses a trusted third party (the 401 Kerberos Distribution Center - KDC) to provide for authentication of 402 the user to a network server. It is assumed that a KDC is present and 403 both host and verifier of authentication information (router or PDP) 404 implement Kerberos authentication. 406 A summary of the Kerberos AUTH_DATA policy element is shown below. 408 +--------------+--------------+--------------+--------------+ 409 | Length | P-type = AUTH_USER | 410 +--------------+--------------+--------------+--------------+ 411 | Length |POLICY_LOCATOR| SubType | 412 +--------------+--------------+--------------+--------------+ 413 | OctetString (User's Distinguished Name) ... 414 +--------------+--------------+--------------+--------------+ 415 | Length | CREDENTIAL | KERBEROS_TKT | 416 +--------------+--------------+--------------+--------------+ 417 | OctetString (Kerberos Session Ticket) ... 418 +--------------+--------------+--------------+--------------+ 420 4.2.1. Operational Setting using Kerberos Identities 422 An RSVP enabled host is configured to construct and insert AUTH_DATA 423 policy element into RSVP messages that designate use of the Kerberos 424 authentication method (KERBEROS_TKT). Upon RSVP session 425 initialization, the user application contacts the KDC to obtain a 426 Kerberos ticket for the next network node or its PDP. A router when 427 generating a RSVP message contacts the KDC to obtain a Kerberos 428 ticket for the next hop network node or its PDP. The identity of the 429 PDP or next network hop can be statically configured, learned via 430 DHCP or maintained in a directory service. The Kerberos ticket is 431 sent to the next network node (which may be a router or host) in a 432 RSVP message. The KDC is used to validate the ticket and 433 authentication the user sending RSVP message. 435 4.3 Public Key based User Authentication 437 In public key based user authentication method digital certificate is 438 encoded as user credentials. The digital signature is used for 439 authenticating the user. A summary of the public key user AUTH_DATA 440 policy element is shown below. 442 +--------------+--------------+--------------+--------------+ 443 | Length | P-type = AUTH_USER | 444 +--------------+--------------+--------------+--------------+ 445 | Length |POLICY_LOCATOR| SubType | 446 +--------------+--------------+--------------+--------------+ 447 | OctetString (User's Distinguished Name) ... 448 +--------------+--------------+--------------+--------------+ 449 | Length | CREDENTIAL | SubType | 450 +--------------+--------------+--------------+--------------+ 451 | OctetString (User's Digital Certificate) ... 452 +--------------+--------------+--------------+--------------+ 453 | Length |DIGITAL_SIGN. | 0 | 454 +--------------+--------------+--------------+--------------+ 455 | OctetString (Digital signature) ... 456 +--------------+--------------+--------------+--------------+ 458 4.3.1. Operational Setting for public key based authentication 460 Public key based authentication assumes following: 462 - RSVP service requestors have a pair of keys (private key and 463 public key). 465 - Private key is secured with the user. 467 - Public keys are stored in digital certificates and a trusted 468 party, certificate authority (CA) issues these digital 469 certificates. 471 - The verifier (PDP or router) has the ability to verify the 472 digital certificate. 474 RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. 475 User Authenticators (router, PDP) use the user's public key (stored 476 in the digital certificate) to verify the signature and authenticate 477 the user. 479 4.4 Simple Application Authentication 481 The application authentication method encodes the application 482 identification such as an executable filename as plain ASCII or 483 UNICODE text. 485 +----------------+--------------+--------------+--------------+ 486 | Length | P-type = AUTH_APP | 487 +----------------+--------------+--------------+--------------+ 488 | Length |POLICY_LOCATOR| SubType | 489 +----------------+--------------+--------------+--------------+ 490 | OctetString (Application Identity attributes in 491 | the form of a Distinguished Name) ... 492 +----------------+--------------+--------------+--------------+ 493 | Length | CREDENTIAL | ASCII_ID | 494 +----------------+--------------+--------------+--------------+ 495 | OctetString (Application Id, e.g., vic.exe) 496 +----------------+--------------+--------------+--------------+ 498 5. Operation 500 +-----+ +-----+ 501 | PDP |-------+ | PDP | 502 +-----+ | ................... +-----+ 503 | : : | 504 +--------+ : Transit : +-------+ 505 +----| Router |------: Network : -------| Router|--+ 506 | +--------+ : : +-------+ | 507 | | :.................: | | 508 | | | | 509 Host A B C D 511 Figure 1: User and Application Authentication using AUTH_DATA PE 513 Network nodes (hosts/routers) generate AUTH_DATA policy elements, 514 contents of which are depend on the identity type used and the 515 authentication method used. These generally contain authentication 516 credentials (Kerberos ticket or digital certificate) and policy 517 locators (which can be the X.500 Distinguished Name of the user or 518 network node or application names). Network nodes generate AUTH_DATA 519 policy element containing the authentication identity when making the 520 RSVP request or forwarding a RSVP message. 522 Network nodes generate user AUTH_DATA policy element using the 523 following rules 525 1. For unicast sessions the user policy locator is copied from the 526 previous hop. The authentication credentials are for the current 527 network node identity. 529 2. For multicast messages the user policy locator is for the current 530 network node identity. The authentication credentials are for the 531 current network node. 533 Network nodes generate application AUTH_DATA policy element using the 534 following rules: 536 1. For unicast sessions the application AUTH_DATA is copied from the 537 previous hop. 539 2. For multicast messages the application AUTH_DATA is either the 540 first application AUTH_DATA in the message or chosen by the PDP. 542 6. Message Processing Rules 544 6.1 Message Generation (RSVP Host) 546 An RSVP message is created as specified in [RFC2205] with following 547 modifications. 549 1. RSVP message MAY contain multiple AUTH_DATA policy elements. 551 2. Authentication policy element (AUTH_DATA) is created and the 552 IdentityType field is set to indicate the identity type in the 553 policy element. 555 - DN is inserted as POLICY_LOCATOR attribute. 557 - Credentials such as Kerberos ticket or digital certificate are 558 inserted as the CREDENTIAL attribute. 560 3. POLICY_DATA object (containing the AUTH_DATA policy element) is 561 inserted in the RSVP message in appropriate place. If INTEGRITY 562 object is not computed for the RSVP message then an INTEGRITY 563 object SHOULD be computed for this POLICY_DATA object, as 564 described in the [POL_EXT], and SHOULD be inserted as a Policy 565 Data option. 567 6.2 Message Reception (Router) 569 RSVP message is processed as specified in [RFC2205] with following 570 modifications. 572 1. If router is not policy aware then it SHOULD send the RSVP message 573 to the PDP and wait for response. If the router is policy unaware 574 then it ignores the policy data objects and continues processing 575 the RSVP message. 577 2. Reject the message if the response from the PDP is negative. 579 3. Continue processing the RSVP message. 581 6.3 Authentication (Router/PDP) 583 1. Retrieve the AUTH_DATA policy element. Check the PE type field and 584 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 get 589 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 or 596 application by verifying the digital signature. 598 7. 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 error 602 values are described in [RFC 2205] and [POL-EXT]. Also PDP SHOULD 603 supply a policy data object containing an AUTH_DATA Policy Element 604 with A-Type=POLICY_ERROR_CODE containing more details on the Policy 605 Control failure (see section 3.3.4). The PEP will include this Policy 606 Data object in the outgoing RSVP Error message. 608 8. IANA Considerations 610 Following the policies outlined in [IANA-CONSIDERATIONS], Standard 611 RSVP Policy Elements (P-type values) are assigned by IETF Consensus 612 action as described in [POL-EXT]. 614 P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP is assigned 615 the value 3. 617 Following the policies outlined in [IANA-CONSIDERATIONS], 618 authentication attribute types (A-Type) in the range 0-127 are 619 allocated through an IETF Consensus action, A-Type values between 620 128-255 are reserved for Private Use and are not assigned by IANA. 622 A-Type POLICY_LOCATOR is assigned the value 1. A-Type CREDENTIAL is 623 assigned the value 2. A-Type DIGITAL_SIGNATURE is assigned the value 624 3. A-Type POLICY_ERROR_OBJECT is assigned the value 4. 626 Following the policies outlined in [IANA-CONSIDERATIONS], 627 POLICY_LOCATOR SubType values in the range 0-127 are allocated 628 through an IETF Consensus action, POLICY_LOCATOR SubType values 629 between 128-255 are reserved for Private Use and are not assigned by 630 IANA. 632 POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType 633 UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is 634 assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the 635 value 4. 637 Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL 638 SubType values in the range 0-127 are allocated through an IETF 639 Consensus action, CREDENTIAL SubType values between 128-255 are 640 reserved for Private Use and are not assigned by IANA. 642 CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType 643 UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is assigned 644 the value 3, SubType X509_V3_CERT is assigned the value 4, SubType 645 PGP_CERT is assigned the value 5. 647 9. Security Considerations 649 The purpose of this memo is to describe a mechanism to authenticate 650 RSVP requests based on user identity in a secure manner. The 651 INTEGRITY Option of a RSVP POLICY_DATA object can be used to protect 652 the policy object containing user identity information from 653 corruption or replay attacks [POLICY-MD5]. Combining a policy 654 object containing the AUTH_DATA policy element and an INTEGRITY 655 option with an RSVP's INTEGRITY Object can result in a secure 656 admission control mechanism that enforces authentication based on 657 both the identity of the user and the identity of the originating 658 node. 660 Simple authentication does not contain credentials that can be 661 securely authenticated and is inherently less secured. 663 The Kerberos authentication mechanism is reasonably well secured. 665 User authentication using a public key certificate is known to 666 provide the strongest security. 668 10. Acknowledgments 670 We would like to thank Andrew Smith, Bob Lindell and many others for 671 their valuable comments on this memo. 673 11. References 675 [ASCII] Coded Character Set -- 7-Bit American Standard 676 Code for Information Interchange, ANSI X3.4- 677 1986. 679 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 680 Writing an IANA Considerations Section in 681 RFCs", BCP 26, RFC 2434, October 1998. 683 [POL-EXT] Hess, R., Ed., and Herzog, S., "RSVP Extensions 684 for Policy Control", work in progress, draft- 685 ietf-rap-new-rsvp-ext-00.txt, June 2001. 687 [POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A 688 Framework for Policy-based Admission Control 689 RSVP", RFC 2753, January 2000. 691 [POLICY-MD5] Hess, R., "Cryptographic Authentication for 692 RSVP POLICY_DATA Objects", work in progress, 693 draft-ietf-rap-auth-policy-data-00.txt, 694 June 2001. 696 [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network 697 Authentication Service (V5)", RFC 1510, 698 September 1993. 700 [RFC 1704] Haller, N. and R. Atkinson, "On Internet 701 Authentication", RFC 1704, October 1994. 703 [RFC 1779] Killie, S., "A String Representation of 704 Distinguished Names", RFC 1779, March 1995. 706 [RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. 707 and S. Jamin, "Resource ReSerVation Protocol 708 (RSVP) - Version 1 Functional Specification", 709 RFC 2205, September 1997. 711 [RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation 712 Protocol (RSVP) - Version 1 Message Processing 713 Rules", RFC 2209, September 1997. 715 [UNICODE] The Unicode Consortium, "The Unicode Standard, 716 Version 2.0", Addison-Wesley, Reading, MA, 717 1996. 719 [X.509] Housley, R., Ford, W., Polk, W. and D. Solo, 720 "Internet X.509 Public Key Infrastructure 721 Certificate and CRL Profile", RFC 2459, January 722 1999. 724 [X.509-ITU] ITU-T (formerly CCITT) Information technology - 725 Open Systems Interconnection - The Directory: 726 Authentication Framework Recommendation X.509 727 ISO/IEC 9594-8 729 12. Author Information 731 Rodney Hess 732 Intel, BD1 733 28 Crosby Drive 734 Bedford, MA 01730 736 EMail: rodney.hess@intel.com 738 Satyendra Yadav 739 Intel, JF3-206 740 2111 NE 25th Avenue 741 Hillsboro, OR 97124 743 EMail: Satyendra.Yadav@intel.com 745 Raj Yavatkar 746 Intel, JF3-206 747 2111 NE 25th Avenue 748 Hillsboro, OR 97124 750 EMail: Raj.Yavatkar@intel.com 752 Ramesh Pabbati 753 Microsoft 754 1 Microsoft Way 755 Redmond, WA 98054 757 EMail: rameshpa@microsoft.com 759 Peter Ford 760 Microsoft 761 1 Microsoft Way 762 Redmond, WA 98054 764 EMail: peterf@microsoft.com 766 Tim Moore 767 Microsoft 768 1 Microsoft Way 769 Redmond, WA 98054 771 EMail: timmoore@microsoft.com 772 Shai Herzog 773 IPHighway, Inc. 774 55 New York Avenue 775 Framingham, MA 01701 777 EMail: herzog@iphighway.com 779 13. Full Copyright Statement 781 Copyright (C) The Internet Society (2001). All Rights Reserved. 783 This document and translations of it may be copied and furnished to 784 others, and derivative works that comment on or otherwise explain it 785 or assist in its implementation may be prepared, copied, published 786 and distributed, in whole or in part, without restriction of any 787 kind, provided that the above copyright notice and this paragraph are 788 included on all such copies and derivative works. However, this 789 document itself may not be modified in any way, such as by removing 790 the copyright notice or references to the Internet Society or other 791 Internet organizations, except as needed for the purpose of 792 developing Internet standards in which case the procedures for 793 copyrights defined in the Internet Standards process must be 794 followed, or as required to translate it into languages other than 795 English. 797 The limited permissions granted above are perpetual and will not be 798 revoked by the Internet Society or its successors or assigns. 800 This document and the information contained herein is provided on an 801 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 802 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 803 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 804 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 805 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 807 Acknowledgement 809 Funding for the RFC Editor function is currently provided by the 810 Internet Society.