idnits 2.17.1 draft-ietf-rap-rsvp-better-identity-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC2205], [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 -- 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 2001) is 8318 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 1633' is mentioned on line 69, but not defined == Missing Reference: 'RFC 1509' is mentioned on line 268, but not defined ** Obsolete undefined reference: RFC 1509 (Obsoleted by RFC 2744) == Unused Reference: 'ASCII' is defined on line 756, but no explicit reference was found in the text == Unused Reference: 'RFC 1704' is defined on line 781, but no explicit reference was found in the text == Unused Reference: 'RFC 2209' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 800, 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') -- Unexpected draft version: The latest known version of draft-ietf-rap-auth-policy-data is -00, but you're referring to -01. -- 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: 13 errors (**), 0 flaws (~~), 8 warnings (==), 8 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 January 2002 Intel 6 R. Pabbati 7 P. Ford 8 T. Moore 9 Microsoft 10 S. Herzog 11 IPHighway 12 July 2001 14 Identity Representation for RSVP 16 draft-ietf-rap-rsvp-better-identity-01.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 January 31, 39 2002. 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 [RFC 2205]. The goal of identity representation is 50 to allow a process on a system to securely identify the owner and the 51 application of the communicating process (e.g. user id) and to convey 52 this information in RSVP PATH or RESV messages 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 authentication mechanisms. In summary we describe the use of this 58 identity information in an operational setting. 60 1. Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC 2119]. 66 2. Introduction 68 RSVP [RFC 2205] is a resource reservation protocol designed for an 69 integrated services Internet [RFC 1633]. A host uses RSVP to request 70 a specific quality of service (QoS) from the network for a particular 71 application's data flows. RSVP is also used by routers to deliver 72 QoS requests to all nodes along the path(s) of the flows and to 73 establish and maintain state in order to provide the requested 74 service. RSVP requests will generally result in resources being 75 reserved in each node along the data path. RSVP allows particular 76 users to obtain preferential access to network resources, under the 77 control of an admission control mechanism. Permission to make a 78 reservation is based both upon the availability of the requested 79 resources along the data path and upon satisfaction of policy rules. 80 Providing policy based admission control mechanism based on user or 81 application identity is one of the primary requirements of RSVP. 83 In order to solve these problems and implement identity based policy 84 control it is necessary to identify the user or application making 85 the RSVP request. 87 This document proposes a mechanism for sending identification 88 information in an RSVP message, thereby enabling authorization 89 decisions to be based on policy and identity. 91 We describe the authentication policy element (AUTH_DATA) contained 92 in a POLICY_DATA object [POL-EXT]. A user process generates an 93 AUTH_DATA policy element and hands it off to a policy aware RSVP 94 service on the originating host. The RSVP service encapsulates the 95 AUTH_DATA policy element into a POLICY_DATA object. It then inserts 96 this object into the RSVP PATH or RESV message to permit 97 identification of the owner (e.g. user or application) making the 98 request for network resources. Policy aware RSVP systems, also 99 referred to by this memo as Policy Enforcement Points (PEPs), forward 100 the policy elements to their Policy Decision Points (PDPs) [POL-FRAME]. 102 Each PDP along the data path authenticates the request using the 103 credentials present in the AUTH_DATA policy element. The PDP makes 104 an admission policy decision along with other policy decisions as 105 warranted by policy configuration. The admit or deny decision is 106 returned to the PEP, who either installs the necessary RSVP state or 107 rejects the RSVP request. Furthermore, with an admit decision, the 108 PDP also returns to the PEP a new policy element list in which exists 109 a new AUTH_DATA policy element amongst other possible policy elements. 110 This new AUTH_DATA contains the identity credentials of this PDP for 111 authentication by the next PDP in the data path. The PEP forwards 112 the RSVP message with the new policy elements to the next RSVP hop. 113 In this manner, network resources can be allocated or reserved based 114 on policy and identity. 116 3. Policy Element for Authentication Data 118 3.1. Policy Data Object Format 120 POLICY_DATA objects contain policy information and are carried by 121 RSVP messages. A detail description of the format of the POLICY_DATA 122 object can be found in "RSVP Extensions for Policy Control" [POL- 123 EXT]. 125 3.2. Authentication Data Policy Element 127 In this section, we describe a policy element (PE) called 128 authentication data (AUTH_DATA). AUTH_DATA policy elements contain a 129 list of authentication attributes. 131 +-------------+-------------+-------------+-------------+ 132 | Length | P-Type = Identity Type | 133 +-------------+-------------+-------------+-------------+ 134 | | 135 // Authentication Attribute List // 136 | | 137 +-------------+-------------+-------------+-------------+ 139 Length: 16 bits 141 The length of the policy element (including the Length and P- 142 Type fields) in number of octets (MUST be a multiple of 4) and 143 indicates the end of the authentication attribute list. 145 P-Type (Identity Type): 16 bits 147 Type of identity information contained in this Policy Element 148 supplied as the Policy Element Type (P-Type). The Internet 149 Assigned Numbers Authority (IANA) acts as a registry for Policy 150 Element Types for identity as described in the [POL-EXT]. 152 Initially, the registry contains the following P-Types for 153 identity: 155 2 AUTH_USER Authentication scheme to identify users 157 3 AUTH_APP Authentication scheme to identify 158 applications 160 Authentication Attribute List: Variable length 162 Authentication attributes contain information specific to the 163 authentication method and the type of AUTH_DATA. The policy 164 element definition [POL-EXT] provides the mechanism for grouping 165 a collection of authentication attributes. 167 3.3. Authentication Attributes 169 Authentication attributes MUST be encoded as a multiple of 4 octets; 170 attributes that are not a multiple of 4 octets long MUST be padded to 171 a 4-octet boundary. 173 +-------------+-------------+-------------+-------------+ 174 | Length | A-Type | SubType | 175 +-------------+-------------+-------------+-------------+ 176 | | 177 // Value // 178 | | 179 +-------------+-------------+-------------+-------------+ 181 Length: 16 bits 183 The length field indicates the actual length of the attribute 184 (including the Length and A-Type fields) in number of octets. 185 The length does not include any octet padding to the Value field 186 to make the attribute a multiple of 4 octets long. 188 A-Type: 8 bits 190 Authentication attribute type (A-Type) field is one octet. IANA 191 acts as a registry for A-Types as described in the section 9, 192 IANA Considerations. Initially, the registry contains the 193 following A-Types: 195 1 POLICY_LOCATOR Unique string for locating the 196 admission policy (such as X.500 DN 197 described in [RFC 1779]). 199 2 CREDENTIAL User credential such as a Kerberos 200 ticket, or a digital certificate. 201 Application credential such as an 202 application ID. 204 3 DIGITAL_SIGNATURE Digital signature of the 205 authentication data policy element. 207 4 POLICY_ERROR_OBJECT Detailed information on policy 208 failures. 210 SubType: 8 bits 212 Authentication attribute sub-type field is one octet. Value of 213 SubType depends on A-type. 215 Value: Variable length 217 The value field contains the attribute specific information. 219 3.3.1. POLICY_LOCATOR A-Type 221 POLICY_LOCATOR is used to locate the admission policy for the user 222 or application. Distinguished Name (DN) is unique for each User or 223 application hence a DN is used as for the policy locator. 225 +-------------+-------------+-------------+-------------+ 226 | Length | A-Type | SubType | 227 +-------------+-------------+-------------+-------------+ 228 | | 229 // OctetSting // 230 | | 231 +-------------+-------------+-------------+-------------+ 233 Length: 16 bits 235 Length of the attribute, which MUST be >= 4. 237 A-Type: 8 bits 239 This field MUST contain the value POLICY_LOCATOR. 241 SubType: 8 bits 243 The following SubTypes for POLICY_LOCATOR are defined. IANA acts 244 As a registry for POLICY_LOCATOR SubTypes as described in Section 245 9, IANA Considerations. Initially, the registry contains 246 the following SubTypes for POLICY_LOCATOR: 248 1 ASCII_DN OctetString contains the X.500 DN as 249 described in the RFC 1779 as an ASCII 250 string. 252 2 UNICODE_DN OctetString contains the X.500 DN 253 described in the RFC 1779 as an UNICODE 254 string. 256 3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500 257 DN. The Kerberos session key or digital 258 certificate private key is used for 259 encryption. For Kerberos encryption the 260 format is the same as returned from 261 gss_seal [RFC 1509]. 263 4 UNICODE_DN_ENCRYPT OctetString contains the encrypted 264 UNICODE X.500 DN. The Kerberos session 265 key or digital certificate private key 266 is used for encryption. For Kerberos 267 encryption the format is the same as 268 returned from gss_seal [RFC 1509]. 270 OctetString: Variable length 272 The OctetString field contains the DN. 274 3.3.2. CREDENTIAL A-Type 276 CREDENTIAL indicates the credentials of the user or application to be 277 authenticated. For Kerberos authentication method the CREDENTIAL 278 object contains the Kerberos session ticket. For public-key based 279 authentication this field contains a digital certificate. 281 A summary of the CREDENTIAL attribute format is shown below. The 282 fields are transmitted from left to right. 284 +-------------+-------------+-------------+-------------+ 285 | Length | A-Type | SubType | 286 +-------------+-------------+-------------+-------------+ 287 | | 288 // OctetSting // 289 | | 290 +-------------+-------------+-------------+-------------+ 292 Length: 16 bits 294 Length of the attribute, which MUST be >= 4. 296 A-Type: 8 bits 298 This field MUST contain the value CREDENTIAL. 300 SubType: 8 bits 302 IANA acts as a registry for CREDENTIAL SubTypes as described in 303 Section 9, IANA Considerations. Initially, the registry contains 304 the following SubTypes for CREDENTIAL: 306 1 ASCII_ID OctetString contains user or application 307 identification in a plain ASCII text string. 309 2 UNICODE_ID OctetString contains user or application 310 identification in a plain UNICODE text string. 312 3 KERBEROS_TKT OctetString contains a Kerberos ticket. 314 4 X509_V3_CERT OctetString contains a X.509 V3 digital 315 certificate [X.509]. 317 5 PGP_CERT OctetString contains a PGP digital 318 certificate. 320 OctetString: Variable length 322 The OctetString contains the user or application credentials. 324 3.3.3. DIGITAL_SIGNATURE A-Type 326 The DIGITAL_SIGNATURE attribute MUST be the last attribute in the 327 attribute list and contains the digital signature of the AUTH_DATA 328 policy element. The digital signature signs all data in the 329 AUTH_DATA policy element up to, but not including, the 330 DIGITAL_SIGNATURE. The algorithm used to compute the digital 331 signature depends on the authentication method specified by the 332 CREDENTIAL SubType field. 334 A summary of DIGITAL_SIGNATURE attribute format is described below. 336 +-------------+-------------+-------------+-------------+ 337 | Length | A-Type | SubType | 338 +-------------+-------------+-------------+-------------+ 339 | | 340 // OctetSting // 341 | | 342 +-------------+-------------+-------------+-------------+ 344 Length: 16 bits 346 Length of the attribute, which MUST be >= 4. 348 A-Type: 8 bits 350 This field MUST contain the value DIGITAL_SIGNATURE. 352 SubType: 8 bits 354 No SubTypes for DIGITAL_SIGNATURE are currently defined. This 355 field MUST be set to 0. 357 OctetString: Variable length 359 OctetString contains the digital signature of the AUTH_DATA. 361 3.3.4. POLICY_ERROR_CODE A-Type 363 This attribute is used to carry any specific policy control errors 364 generated by a node when processing/validating an Authentication Data 365 Policy Element. When a RSVP policy node (local policy decision point 366 or remote PDP) encounters a request that fails policy control due to 367 its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE 368 containing additional information about the reason the failure 369 occurred into the policy element. This will then cause an appropriate 370 PATH_ERROR or RESV_ERROR message to be generated with the policy 371 element and appropriate RSVP error code in the message, which is 372 returned to the request's source. 374 The AUTH_DATA policy element in a PATH or RSVP message SHOULD NOT 375 contain the POLICY_ERROR_OBJECT attribute. These are only inserted 376 into PATH_ERROR and RESV_ERROR messages when generated by policy 377 aware intermediate nodes. 379 +-------------+-------------+-------------+-------------+ 380 | Length | A-Type | SubType | 381 +-------------+-------------+-------------+-------------+ 382 | Reserved (0) | ErrorValue | 383 +-------------+-------------+-------------+-------------+ 384 | | 385 // OctetSting // 386 | | 387 +-------------+-------------+-------------+-------------+ 389 Length: 16 bits 391 Length of the attribute, which MUST be >= 8. 393 A-Type: 8 bits 395 This field MUST contain the value POLICY_ERROR_CODE 397 SubType: 8 bits 399 No SubTypes for POLICY_ERROR_CODE are currently defined. This 400 field MUST be set to 0. 402 Reserved: 16 bits 404 This field MUST be set to 0. 406 ErrorValue: 16 bits 408 A 16-bit code containing the reason that the Policy Decision 409 Point failed to process the policy element. IANA acts as a 410 registry for ErrorValues as described in Section 9, IANA 411 Considerations. The following values have been defined. 413 1 ERROR_NO_MORE_INFO No information is available. 415 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is 416 not supported. 418 3 INSUFFICIENT_PRIVILEGES The credentials do not have 419 sufficient privilege. 421 4 EXPIRED_CREDENTIAL The credential has expired. 423 5 IDENTITY_CHANGED Identity has changed. 425 OctetString: Variable length 427 The OctetString field contains information from the Policy 428 Decision Point that MAY contain additional information about the 429 policy failure. For example, it may include a human readable 430 message in the ASCII text. 432 4. Authentication Data Formats 434 Authentication attributes are grouped together in a policy element to 435 represent the identity credentials. 437 4.1. Simple User Authentication 439 In the simple user authentication method, the user's login ID, in 440 either plain ASCII or UNICODE text, is encoded as a CREDENTIAL 441 attribute. A summary of the simple user AUTH_DATA policy element is 442 shown below. 444 +-------------+-------------+--------------+-------------+ 445 | Length | P-Type = AUTH_USER | 446 +-------------+-------------+--------------+-------------+ 447 | Length |POLICY_LOCATOR| SubType | 448 +-------------+-------------+--------------+-------------+ 449 | | 450 // OctetSting (User's Distinguished Name) // 451 | | 452 +-------------+-------------+--------------+-------------+ 453 | Length | CREDENTIAL | ASCII_ID | 454 +-------------+-------------+--------------+-------------+ 455 | | 456 // OctetSting (User's login ID) // 457 | | 458 +-------------+-------------+--------------+-------------+ 460 4.2. Kerberos User Authentication 462 Kerberos [RFC 1510] authentication utilizes a trusted third party, 463 the Kerberos Distribution Center (KDC), to provide for authentication 464 of the user to a policy aware network element. For this method of 465 authentication to work, a KDC must be present, and both the host and 466 the policy aware network element (re: PDP) implement the Kerberos 467 authentication protocol. 469 An example of a user Kerberos AUTH_DATA policy element is shown 470 below. 472 +-------------+-------------+--------------+-------------+ 473 | Length | P-Type = AUTH_USER | 474 +-------------+-------------+--------------+-------------+ 475 | Length |POLICY_LOCATOR| SubType | 476 +-------------+-------------+--------------+-------------+ 477 | | 478 // OctetSting (User's Distinguished Name) // 479 | | 480 +-------------+-------------+--------------+-------------+ 481 | Length | CREDENTIAL | KERBEROS_TKT| 482 +-------------+-------------+--------------+-------------+ 483 | | 484 // OctetSting (Kerberos Session Ticket) // 485 | | 486 +-------------+-------------+--------------+-------------+ 488 4.2.1. Operational Setting using Kerberos Identities 490 A policy aware RSVP enabled host is configured to construct and 491 insert AUTH_DATA policy objects into RSVP messages that designate use 492 of the Kerberos authentication method (KERBEROS_TKT). Upon a RSVP 493 session initialization, the initiating application, be it a user 494 and/or an application, contacts the KDC to obtain a Kerberos ticket 495 for the next policy aware RSVP system or its PDP on the data path. 496 The identity of the next hop may have been statically configured, 497 learned via DHCP or maintained in a directory service. Once the 498 ticket is acquired, the host constructs a Kerberos AUTH_DATA policy 499 object, encapsulates it into a RSVP message, and sends it to the next 500 hop RSVP system. Once received by the PDP, the Kerberos ticket is 501 used to authenticate the user and/or application initiating the RSVP 502 session. 504 4.3. Public-Key Based User Authentication 506 In the public-key based user authentication method, the digital 507 certificate is encoded as the user's and/or application's 508 credentials. The digital signature is used for authenticating the 509 user and/or application. 511 An example of a user public-key AUTH_DATA policy element is show 512 below. 514 +-------------+-------------+--------------+-------------+ 515 | Length | P-Type = AUTH_USER | 516 +-------------+-------------+--------------+-------------+ 517 | Length |POLICY_LOCATOR| SubType | 518 +-------------+-------------+--------------+-------------+ 519 | | 520 // OctetSting (User's Distinguished Name) // 521 | | 522 +-------------+-------------+--------------+-------------+ 523 | Length | CREDENTIAL | PGP_CERT | 524 +-------------+-------------+--------------+-------------+ 525 | | 526 // OctetSting (User's digital certificate) // 527 | | 528 +-------------+-------------+--------------+-------------+ 529 | Length |DIGITAL_SIGN. | 0 | 530 +-------------+-------------+--------------+-------------+ 531 | | 532 // OctetSting (Digital signature) // 533 | | 534 +-------------+-------------+--------------+-------------+ 536 4.3.1. Operational Setting for Public-Key Based Authentication 538 Public-key based authentication assumes the following: 540 - RSVP service requestors have a pair of keys, one private and 541 one public. 543 - The private key is secured with the user. 545 - Public keys are stored in digital certificates. A trusted 546 third party, the certificate authority (CA), issues these 547 digital certificates upon request. 549 - The PDP has the ability to verify digital certificates. 551 A policy aware RSVP enabled host is configured to construct and 552 insert AUTH_DATA policy objects into RSVP messages that designate use 553 of a public-key authentication method. When constructing the 554 AUTH_DATA policy element, the host uses the user's private key to 555 generate the digital signature. The host then encapsulates the 556 AUTH_DATA policy object into a RSVP message and sends it to the next 557 hop RSVP system. Once received by the PDP, authentication of the 558 user is accomplished by verifying the digital signature using the 559 user's public key stored in the digital certificate. 561 4.4. Simple Application Authentication 563 The application authentication method encodes the application 564 identification such as an executable filename as plain ASCII or 565 UNICODE text. 567 +-------------+-------------+--------------+-------------+ 568 | Length | P-Type = AUTH_APP | 569 +-------------+-------------+--------------+-------------+ 570 | Length |POLICY_LOCATOR| SubType | 571 +-------------+-------------+--------------+-------------+ 572 | | 573 // OctetSting (Application's identity attributes in // 574 | the form of a Distinguished Name) | 575 | | 576 +-------------+-------------+--------------+-------------+ 577 | Length | CREDENTIAL | ASCII_ID | 578 +-------------+-------------+--------------+-------------+ 579 | | 580 // OctetSting (Application ID, e.g. vic.exe) // 581 | | 582 +-------------+-------------+--------------+-------------+ 584 5. AUTH_DATA Construction at Intermediary PDP Nodes 586 As described in Section 2, each PDP along the data path constructs a 587 new AUTH_DATA for the next PDP. More specifically, generation of the 588 user AUTH_DATA policy element follows these rules: 590 1. For unicast RSVP sessions, the user policy locator is copied from 591 the previous hop. For authentication credentials, the PDP uses 592 its own instead of the previous hop's. 594 2. For multicast messages, the PDP discards data from the previous 595 hop and uses its own policy locator and authentication 596 credentials instead. 598 For application AUTH_DATA policy elements, the PDP follows these 599 rules: 601 1. For unicast sessions, the application AUTH_DATA is copied from 602 the previous hop. 604 2. For multicast messages the application AUTH_DATA is either the 605 first application AUTH_DATA in the message or chosen by the PDP. 607 6. Message Processing Rules 609 6.1. Message Generation 611 A RSVP message is created by a policy aware RSVP host as specified in 612 [RFC 2205] and [POL-EXT] with the following modifications. 614 1. A RSVP message MAY contain multiple AUTH_DATA policy elements in 615 one or more POLICY_DATA objects. 617 2. When an AUTH_DATA PE is created, the P-Type field is set to 618 indicate the identity type, e.g. user. The DN is inserted as a 619 POLICY_LOCATOR attribute. Authentication credentials such as a 620 Kerberos ticket or a digital certificate are inserted as a 621 CREDENTIAL attribute. 623 3. The AUTH_DATA PE is encapsulated into a POLICY_DATA object as 624 described in [POL-EXT]. The INTEGRITY option of a POLICY_DATA 625 object SHOULD be included if protection against corruption and 626 replay attacks is desired [POLICY-MD5]. 628 4. The policy object is inserted into the RSVP message at the 629 appropriate place. 631 6.2. Message Reception 633 RSVP messages are processed as specified by [RFC 2205] with the 634 following modifications. 636 1. If a RSVP system is policy unaware, it MUST ignore any policy data 637 objects it finds in a RSVP message [POL-EXT]. Processing of the 638 RSVP message occurs normally as specified in [RFC 2205] and 639 [POL-EXT]. 641 If a RSVP system is policy aware, that is, it is also a policy 642 enforcement point (PEP), then it SHOULD send the policy elements 643 from the POLICY_DATA objects to its PDP (or LDP, as appropriate) 644 and wait for a response. 646 2. Reject the RSVP message if the response from the PDP is negative. 647 Otherwise, continue processing the RSVP message. 649 6.3. Authentication 651 1. The PDP retrieves the AUTH_DATA PE from the list of policy 652 elements. Check the P-Type field and return an error if the 653 identity type is unsupported (see Section 7). 655 2. Verify user credentials. If the authentication method is 656 unsupported, return an error as described in Section 7. 658 - For simple authentication, this means validating the user ID or 659 executable name. 661 - For the Kerberos method, use the enclosed Kerberos ticket to 662 validate the user. 664 - For the public-key method, first, validate the digital 665 certificate that should have been issued by a trusted 666 certificate authority. Then, retrieve the user's public key 667 from the certificate, and verify the digital signature. 669 7. Error Signaling 671 If the PDP fails to verify the AUTH_DATA policy element, then it MUST 672 return a policy control failure (Error Code = 02) to the PEP. The 673 error values are described in [RFC 2205] and [POL-EXT]. Furthermore, 674 the PDP SHOULD supply a policy data object containing an AUTH_DATA PE 675 with a POLICY_ERROR_CODE attribute containing more details on the 676 policy control failure (see Section 3.3.4). The PEP will include 677 this policy data object in the outgoing RSVP Error message. 679 8. IANA Considerations 681 Following the policies outlined in [IANA-CONSIDERATIONS], Standard 682 RSVP Policy Elements (P-type values) are assigned by IETF Consensus 683 action as described in [POL-EXT]. 685 P-Type AUTH_USER is assigned the value 2. P-Type AUTH_APP is assigned 686 the value 3. 688 Following the policies outlined in [IANA-CONSIDERATIONS], 689 authentication attribute types (A-Type) in the range 0-127 are 690 allocated through an IETF Consensus action, A-Type values between 691 128-255 are reserved for Private Use and are not assigned by IANA. 693 A-Type POLICY_LOCATOR is assigned the value 1. A-Type CREDENTIAL is 694 assigned the value 2. A-Type DIGITAL_SIGNATURE is assigned the value 695 3. A-Type POLICY_ERROR_OBJECT is assigned the value 4. 697 Following the policies outlined in [IANA-CONSIDERATIONS], 698 POLICY_LOCATOR SubType values in the range 0-127 are allocated 699 through an IETF Consensus action, POLICY_LOCATOR SubType values 700 between 128-255 are reserved for Private Use and are not assigned by 701 IANA. 703 POLICY_LOCATOR SubType ASCII_DN is assigned the value 1, SubType 704 UNICODE_DN is assigned the value 2, SubType ASCII_DN_ENCRYPT is 705 assigned the value 3 and SubType UNICODE_DN_ENCRYPT is assigned the 706 value 4. 708 Following the policies outlined in [IANA-CONSIDERATIONS], ErrorValue 709 assignments for the POLICY_ERROR_CODE attribute are assigned by IETF 710 Consensus action. 712 The ErrorValue ERROR_NO_MORE_INFO is assigned the value 1, 713 UNSUPPORTED_CREDENTIAL_TYPE is assigned the value 2, 714 INSUFFICIENT_PRIVILEGES is assigned the value 3, EXPIRED_CREDENTIAL 715 is assigned the value 4, and the ErrorValue IDENTITY_CHANGED is 716 assigned the value 5. 718 Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL 719 SubType values in the range 0-127 are allocated through an IETF 720 Consensus action, CREDENTIAL SubType values between 128-255 are 721 reserved for Private Use and are not assigned by IANA. 723 CREDENTIAL SubType ASCII_ID is assigned the value 1, SubType 724 UNICODE_ID is assigned the value 2, SubType KERBEROS_TKT is assigned 725 the value 3, SubType X509_V3_CERT is assigned the value 4, SubType 726 PGP_CERT is assigned the value 5. 728 9. Security Considerations 730 The purpose of this memo is to describe a mechanism to authenticate 731 RSVP requests based on user identity in a secure manner. The 732 INTEGRITY Option of a RSVP POLICY_DATA object can be used to protect 733 the policy object containing user identity information from 734 corruption or replay attacks [POLICY-MD5]. Combining a policy 735 object containing the AUTH_DATA policy element and an INTEGRITY 736 option with an RSVP's INTEGRITY Object can result in a secure 737 admission control mechanism that enforces authentication based on 738 both the identity of the user and the identity of the originating 739 node. 741 Simple authentication does not contain credentials that can be 742 securely authenticated and is inherently less secured. 744 The Kerberos authentication mechanism is reasonably well secured. 746 User authentication using a public-key certificate is known to 747 provide the strongest security. 749 10. Acknowledgments 751 We would like to thank Andrew Smith, Bob Lindell and many others for 752 their valuable comments on this memo. 754 11. References 756 [ASCII] Coded Character Set -- 7-Bit American Standard 757 Code for Information Interchange, ANSI X3.4- 758 1986. 760 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 761 Writing an IANA Considerations Section in 762 RFCs", BCP 26, RFC 2434, October 1998. 764 [POL-EXT] Hess, R., Ed., and Herzog, S., "RSVP Extensions 765 for Policy Control", work in progress, draft- 766 ietf-rap-new-rsvp-ext-00.txt, June 2001. 768 [POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A 769 Framework for Policy-based Admission Control 770 RSVP", RFC 2753, January 2000. 772 [POLICY-MD5] Hess, R., "Cryptographic Authentication for 773 RSVP POLICY_DATA Objects", work in progress, 774 draft-ietf-rap-auth-policy-data-01.txt, 775 July 2001. 777 [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network 778 Authentication Service (V5)", RFC 1510, 779 September 1993. 781 [RFC 1704] Haller, N. and R. Atkinson, "On Internet 782 Authentication", RFC 1704, October 1994. 784 [RFC 1779] Killie, S., "A String Representation of 785 Distinguished Names", RFC 1779, March 1995. 787 [RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. 788 and S. Jamin, "Resource ReSerVation Protocol 789 (RSVP) - Version 1 Functional Specification", 790 RFC 2205, September 1997. 792 [RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation 793 Protocol (RSVP) - Version 1 Message Processing 794 Rules", RFC 2209, September 1997. 796 [RFC 2119] Bradner, S., "Key Words for use in RFCs to 797 Indicate Requirement Levels," RFC 2119, March 798 1997. 800 [UNICODE] The Unicode Consortium, "The Unicode Standard, 801 Version 2.0", Addison-Wesley, Reading, MA, 802 1996. 804 [X.509] Housley, R., Ford, W., Polk, W. and D. Solo, 805 "Internet X.509 Public Key Infrastructure 806 Certificate and CRL Profile", RFC 2459, January 807 1999. 808 [X.509-ITU] ITU-T (formerly CCITT) Information technology - 809 Open Systems Interconnection - The Directory: 810 Authentication Framework Recommendation X.509 811 ISO/IEC 9594-8 813 12. Author Information 815 Rodney Hess 816 Intel, BD1 817 28 Crosby Drive 818 Bedford, MA 01730 820 EMail: rodney.hess@intel.com 822 Satyendra Yadav 823 Intel, JF3-206 824 2111 NE 25th Avenue 825 Hillsboro, OR 97124 827 EMail: Satyendra.Yadav@intel.com 828 Raj Yavatkar 829 Intel, JF3-206 830 2111 NE 25th Avenue 831 Hillsboro, OR 97124 833 Email: Raj.Yavatkar@intel.com 835 Ramesh Pabbati 836 Microsoft 837 1 Microsoft Way 838 Redmond, WA 98054 840 Email: rameshpa@microsoft.com 842 Peter Ford 843 Microsoft 844 1 Microsoft Way 845 Redmond, WA 98054 847 Email: peterf@microsoft.com 848 Tim Moore 849 Microsoft 850 1 Microsoft Way 851 Redmond, WA 98054 853 Email: timmoore@microsoft.com 855 Shai Herzog 856 IPHighway, Inc. 857 55 New York Avenue 858 Framingham, MA 01701 860 Email: herzog@iphighway.com 862 Appendix A: Revision History 864 Revision 01 866 1. Corrected an error in the processing of Kerberos credentials in 867 AUTH_DATA policy objects by the PDP (Section 4.2.1 and Section 868 6.3). 870 2. Corrected the length of the ErrorValue field for a 871 POLICY_ERROR_OBJECT attribute (Section 3.3.4). 873 3. Specified the IANA considerations for ErrorValue in Section 874 3.3.4 and Section 9. 876 4. Expanded Section 2, Introduction. 878 5. Rewrote the text for Section 5 to better follow Section 2. 880 6. Updated Step 3 in Section 6.1 to correctly reflect how security 881 issues are addressed. 883 Revision 00 885 1. Updated the Security Considerations Section to correctly 886 reflect how various security issues are addressed. 888 Full Copyright Statement 890 Copyright (C) The Internet Society (2001). All Rights Reserved. 892 This document and translations of it may be copied and furnished to 893 others, and derivative works that comment on or otherwise explain it 894 or assist in its implementation may be prepared, copied, published 895 and distributed, in whole or in part, without restriction of any 896 kind, provided that the above copyright notice and this paragraph are 897 included on all such copies and derivative works. However, this 898 document itself may not be modified in any way, such as by removing 899 the copyright notice or references to the Internet Society or other 900 Internet organizations, except as needed for the purpose of 901 developing Internet standards in which case the procedures for 902 copyrights defined in the Internet Standards process must be 903 followed, or as required to translate it into languages other than 904 English. 906 The limited permissions granted above are perpetual and will not be 907 revoked by the Internet Society or its successors or assigns. 909 This document and the information contained herein is provided on an 910 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 911 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 912 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 913 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 914 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 916 Acknowledgement 918 Funding for the RFC Editor function is currently provided by the 919 Internet Society.