idnits 2.17.1 draft-ietf-rap-rsvp-newidentity-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 64 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. ** 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 ([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 496 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 (January 2000) is 8867 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 54, but not defined == Missing Reference: 'RFC 1633' is mentioned on line 63, 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 576, but not defined == Unused Reference: 'ASCII' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC 1704' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC 2209' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 698, 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) ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'POL-FRAME') ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 1704 ** Obsolete normative reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 2209 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 16 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Yadav 2 Request for Comments: R. Yavatkar 3 Obsoletes: 2752 Intel 4 Category: Standards Track R. Pabbati 5 P. Ford 6 T. Moore 7 Microsoft 8 S. Herzog 9 IPHighway 10 January 2000 12 Identity Representation for RSVP 14 draft-ietf-rap-rsvp-newidentity-01.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2000). All Rights Reserved. 34 Abstract 36 This document describes the representation of identity information in 37 POLICY_DATA object [POL-EXT] for supporting policy based admission 38 control in RSVP. The goal of identity representation is to allow a 39 process on a system to securely identify the owner and the 40 application of the communicating process (e.g. user id) and convey 41 this information in RSVP messages (PATH or RESV) in a secure manner. 42 We describe the encoding of identities as RSVP policy element. We 43 describe the processing rules to generate identity policy elements 44 for multicast merged flows. Subsequently, we describe representations 45 of user identities for Kerberos and Public Key based user 46 authentication mechanisms. In summary we describe the use of this 47 identity information in an operational setting. 49 1. Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC-2119]. 55 This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment 56 error in RFC2752. 58 RFC xxxx Identity Representation for RSVP January 2000 60 2. Introduction 62 RSVP [RFC 2205] is a resource reservation setup protocol designed for 63 an integrated services Internet [RFC 1633]. RSVP is used by a host to 64 request specific quality of service (QoS) from the network for 65 particular application data streams or flows. RSVP is also used by 66 routers to deliver QoS requests to all nodes along the path(s) of the 67 flows and to establish and maintain state to provide the requested 68 service. RSVP requests will generally result in resources being 69 reserved in each node along the data path. RSVP allows particular 70 users to obtain preferential access to network resources, under the 71 control of an admission control mechanism. Permission to make a 72 reservation is based both upon the availability of the requested 73 resources along the path of the data and upon satisfaction of policy 74 rules. Providing policy based admission control mechanism based on 75 user identity or application is one of the prime requirements. 77 In order to solve these problems and implement identity based policy 78 control it is required to identify the user and/or application making 79 a RSVP request. 81 This document proposes a mechanism for sending identification 82 information in the RSVP messages and enables authorization decisions 83 based on policy and identity. 85 We describe the authentication policy element (AUTH_DATA) contained 86 in the POLICY_DATA object. User process can generate an AUTH_DATA 87 policy element and gives it to RSVP process (service) on the 88 originating host. RSVP service inserts AUTH_DATA into the RSVP 89 message to identify the owner (user and/or application) making the 90 request for network resources. Network elements, such as routers, 91 authenticate request using the credentials presented in the AUTH_DATA 92 and admit the RSVP message based on admission policy. After a request 93 has been authenticated, first hop router installs the RSVP state and 94 forwards the new policy element returned by the Policy Decision Point 95 (PDP) [POL-FRAME]. 97 3. Policy Element for Authentication Data 99 3.1 Policy Data Object Format 101 POLICY_DATA objects contain policy information and are carried by 102 RSVP messages. A detail description of the format of POLICY_DATA 103 object can be found in "RSVP Extensions for Policy Control" [POL- 104 EXT]. 106 RFC xxxx Identity Representation for RSVP January 2000 108 3.2 Authentication Data Policy Element 110 In this section, we describe a policy element (PE) called 111 authentication data (AUTH_DATA). AUTH_DATA policy element contains a 112 list of authentication attributes. 114 +-------------+-------------+-------------+-------------+ 115 | Length | P-Type = Identity Type | 116 +-------------+-------------+-------------+-------------+ 117 // Authentication Attribute List // 118 +-------------------------------------------------------+ 120 Length 121 The length of the policy element (including the Length and P- 122 Type) is in number of octets (MUST be a multiple of 4) and 123 indicates the end of the authentication attribute list. 125 P-Type (Identity Type) 126 Type of identity information contained in this Policy Element 127 supplied as the Policy element type (P-type). The Internet 128 Assigned Numbers Authority (IANA) acts as a registry for policy 129 element types for identity as described in the [POL-EXT]. 130 Initially, the registry contains the following P-Types for 131 identity: 133 2 AUTH_USER Authentication scheme to identify users 135 3 AUTH_APP Authentication scheme to identify 136 applications 138 Authentication Attribute List 140 Authentication attributes contain information specific to 141 authentication method and type of AUTH_DATA. The policy element 142 provides the mechanism for grouping a collection of 143 authentication attributes. 145 3.3 Authentication Attributes 147 Authentication attributes MUST be encoded as a multiple of 4 octets, 148 attributes that are not a multiple of 4 octets long MUST be padded to 149 a 4-octet boundary. 151 +--------+--------+--------+--------+ 152 | Length | A-Type |SubType | 153 +--------+--------+--------+--------+ 154 | Value ... 155 +--------+--------+--------+--------+ 157 RFC xxxx Identity Representation for RSVP January 2000 159 Length 160 The length field is two octets and indicates the actual length of 161 the attribute (including the Length and A-Type fields) in number 162 of octets. The length does not include any bytes padding to the 163 value field to make the attribute multiple of 4 octets long. 165 A-Type 166 Authentication attribute type (A-Type) field is one octet. IANA 167 acts as a registry for A-Types as described in the section 9, 168 IANA Considerations. Initially, the registry contains the 169 following A-Types: 171 1 POLICY_LOCATOR Unique string for locating the 172 admission policy (such as X.500 DN 173 described in [RFC 1779]). 175 2 CREDENTIAL User credential such as Kerberos 176 ticket, or digital certificate. 177 Application credential such as 178 application ID. 180 3 DIGITAL_SIGNATURE Digital signature of the 181 authentication data policy element. 183 4 POLICY_ERROR_OBJECT Detailed information on policy 184 failures. 186 SubType 187 Authentication attribute sub-type field is one octet. Value of 188 SubType depends on A-type. 190 Value: 191 The value field contains the attribute specific information. 193 3.3.1 Policy Locator 195 POLICY_LOCATOR is used to locate the admission policy for the user 196 or application. Distinguished Name (DN) is unique for each User or 197 application hence a DN is used as policy locator. 199 +-------+-------+-------+-------+ 200 | Length |A-Type |SubType| 201 +-------+-------+-------+-------+ 202 | OctetString ... 203 +-------+-------+-------+-------- 205 RFC xxxx Identity Representation for RSVP January 2000 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 3.3.2 Credential 243 CREDENTIAL indicates the credential of the user or application to be 244 authenticated. For Kerberos authentication method the CREDENTIAL 245 object contains the Kerberos session ticket. For public key based 246 authentication this field contains a digital certificate. 248 A summary of the CREDENTIAL attribute format is shown below. The 249 fields are transmitted from left to right. 251 RFC xxxx Identity Representation for RSVP January 2000 253 +-------+-------+-------+-------+ 254 | Length |A-Type |SubType| 255 +-------+-------+-------+-------+ 256 | OctetString ... 257 +-------+-------+-------+-------- 259 Length 260 Length of the attribute, which MUST be >= 4. 262 A-Type 263 CREDENTIAL 265 SubType 266 IANA acts as a registry for CREDENTIAL sub types as described in 267 the section 9, IANA Considerations. Initially, the registry 268 contains the following sub types for CREDENTIAL: 270 1 ASCII_ID OctetString contains user or application 271 identification in plain ASCII text string. 273 2 UNICODE_ID OctetString contains user or application 274 identification in plain UNICODE text string. 276 3 KERBEROS_TKT OctetString contains Kerberos ticket. 278 4 X509_V3_CERT OctetString contains X.509 V3 digital 279 certificate [X.509]. 281 5 PGP_CERT OctetString contains PGP digital certificate. 283 OctetString 284 The OctetString contains the user or application credential. 286 3.3.3 Digital Signature 288 The DIGITAL_SIGNATURE attribute MUST be the last attribute in the 289 attribute list and contains the digital signature of the AUTH_DATA 290 policy element. The digital signature signs all data in the 291 AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm 292 used to compute the digital signature depends on the authentication 293 method specified by the CREDENTIAL SubType field. 295 A summary of DIGITAL_SIGNATURE attribute format is described below. 297 RFC xxxx Identity Representation for RSVP January 2000 299 +-------+-------+-------+-------+ 300 | Length |A-Type |SubType| 301 +-------+-------+-------+-------+ 302 | OctetString ... 303 +-------+-------+-------+-------- 305 Length 306 Length of the attribute, which MUST be >= 4. 308 ti3 A-Type 309 DIGITAL_SIGNATURE 311 SubType 312 No sub types for DIGITAL_SIGNATURE are currently defined. This 313 field MUST be set to 0. 315 OctetString 316 OctetString contains the digital signature of the AUTH_DATA. 318 3.3.4 Policy Error Object 320 This attribute is used to carry any specific policy control errors 321 generated by a node when processing/validating an Authentication Data 322 Policy Element. When a RSVP policy node (local policy decision point 323 or remote PDP) encounters a request that fails policy control due to 324 its Authentication Policy Element, it SHOULD add a POLICY_ERROR_CODE 325 containing additional information about the reason the failure 326 occurred into the policy element. This will then cause an appropriate 327 PATH_ERROR or RESV_ERROR message to be generated with the policy 328 element and appropriate RSVP error code in the message, which is 329 returned to the request's source. 331 The AUTH_DATA policy element in the PATH or RSVP message SHOULD not 332 contain the POLICY_ERROR_OBJECT attribute. These are only inserted 333 into PATH_ERROR and RESV_ERROR messages when generated by policy 334 aware intermediate nodes. 336 +----------+----------+----------+----------+ 337 | Length | A-Type |SubType(0)| 338 +----------+----------+----------+----------+ 339 | 0 (Reserved) | ErrorValue | 340 +----------+----------+----------+----------+ 341 | OctetString ... 342 +----------+----------+----------+----------+ 344 Length 345 Length of the attribute, which MUST be >= 8. 347 RFC xxxx Identity Representation for RSVP January 2000 349 A-Type 350 POLICY_ERROR_CODE 352 ErrorValue 353 A 32-bit bit code containing the reason that the policy decision 354 point failed to process the policy element. Following values have 355 been defined. 357 1 ERROR_NO_MORE_INFO No information is available. 358 2 UNSUPPORTED_CREDENTIAL_TYPE This type of credentials is 359 not supported. 361 3 INSUFFICIENT_PRIVILEGES The credentials do not have 362 sufficient privilege. 364 4 EXPIRED_CREDENTIAL The credential has expired. 366 5 IDENTITY_CHANGED Identity has changed. 368 OctetString 369 The OctetString field contains information from the policy 370 decision point that MAY contain additional information about the 371 policy failure. For example, it may include a human-readable 372 message in the ASCII text. 374 4. Authentication Data Formats 376 Authentication attributes are grouped in a policy element to 377 represent the identity credentials. 379 4.1 Simple User Authentication 381 In simple user authentication method the user login ID (in plain 382 ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary 383 of the simple user AUTH_DATA policy element is shown below. 385 +--------------+--------------+--------------+--------------+ 386 | Length | P-type = AUTH_USER | 387 +--------------+--------------+--------------+--------------+ 388 | Length |POLICY_LOCATOR| SubType | 389 +--------------+--------------+--------------+--------------+ 390 | OctetString (User's Distinguished Name) ... 391 +--------------+--------------+--------------+--------------+ 392 | Length |CREDENTIAL | ASCII_ID | 393 +--------------+--------------+--------------+--------------+ 394 | OctetString (User's login ID) ... 395 +--------------+--------------+--------------+--------------+ 397 RFC xxxx Identity Representation for RSVP January 2000 399 4.2 Kerberos User Authentication 401 Kerberos [RFC 1510] authentication uses a trusted third party (the 402 Kerberos Distribution Center - KDC) to provide for authentication of 403 the user to a network server. It is assumed that a KDC is present and 404 both host and verifier of authentication information (router or PDP) 405 implement Kerberos authentication. 407 A summary of the Kerberos AUTH_DATA policy element is shown below. 409 +--------------+--------------+--------------+--------------+ 410 | Length | P-type = AUTH_USER | 411 +--------------+--------------+--------------+--------------+ 412 | Length |POLICY_LOCATOR| SubType | 413 +--------------+--------------+--------------+--------------+ 414 | OctetString (User's Distinguished Name) ... 415 +--------------+--------------+--------------+--------------+ 416 | Length | CREDENTIAL | KERBEROS_TKT | 417 +--------------+--------------+--------------+--------------+ 418 | OctetString (Kerberos Session Ticket) ... 419 +--------------+--------------+--------------+--------------+ 421 4.2.1. Operational Setting using Kerberos Identities 423 An RSVP enabled host is configured to construct and insert AUTH_DATA 424 policy element into RSVP messages that designate use of the Kerberos 425 authentication method (KERBEROS_TKT). Upon RSVP session 426 initialization, the user application contacts the KDC to obtain a 427 Kerberos ticket for the next network node or its PDP. A router when 428 generating a RSVP message contacts the KDC to obtain a Kerberos 429 ticket for the next hop network node or its PDP. The identity of the 430 PDP or next network hop can be statically configured, learned via 431 DHCP or maintained in a directory service. The Kerberos ticket is 432 sent to the next network node (which may be a router or host) in a 433 RSVP message. The KDC is used to validate the ticket and 434 authentication the user sending RSVP message. 436 4.3 Public Key based User Authentication 438 In public key based user authentication method digital certificate is 439 encoded as user credentials. The digital signature is used for 440 authenticating the user. A summary of the public key user AUTH_DATA 441 policy element is shown below. 443 RFC xxxx Identity Representation for RSVP January 2000 445 +--------------+--------------+--------------+--------------+ 446 | Length | P-type = AUTH_USER | 447 +--------------+--------------+--------------+--------------+ 448 | Length |POLICY_LOCATOR| SubType | 449 +--------------+--------------+--------------+--------------+ 450 | OctetString (User's Distinguished Name) ... 451 +--------------+--------------+--------------+--------------+ 452 | Length | CREDENTIAL | SubType | 453 +--------------+--------------+--------------+--------------+ 454 | OctetString (User's Digital Certificate) ... 455 +--------------+--------------+--------------+--------------+ 456 | Length |DIGITAL_SIGN. | 0 | 457 +--------------+--------------+--------------+--------------+ 458 | OctetString (Digital signature) ... 459 +--------------+--------------+--------------+--------------+ 461 4.3.1. Operational Setting for public key based authentication 463 Public key based authentication assumes following: 465 - RSVP service requestors have a pair of keys (private key and 466 public key). 468 - Private key is secured with the user. 470 - Public keys are stored in digital certificates and a trusted 471 party, certificate authority (CA) issues these digital 472 certificates. 474 - The verifier (PDP or router) has the ability to verify the 475 digital certificate. 477 RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. 478 User Authenticators (router, PDP) use the user's public key (stored 479 in the digital certificate) to verify the signature and authenticate 480 the user. 482 4.4 Simple Application Authentication 484 The application authentication method encodes the application 485 identification such as an executable filename as plain ASCII or 486 UNICODE text. 488 RFC xxxx Identity Representation for RSVP January 2000 490 +----------------+--------------+--------------+--------------+ 491 | Length | P-type = AUTH_APP | 492 +----------------+--------------+--------------+--------------+ 493 | Length |POLICY_LOCATOR| SubType | 494 +----------------+--------------+--------------+--------------+ 495 | OctetString (Application Identity attributes in 496 | the form of a Distinguished Name) ... 497 +----------------+--------------+--------------+--------------+ 498 | Length | CREDENTIAL | ASCII_ID | 499 +----------------+--------------+--------------+--------------+ 500 | OctetString (Application Id, e.g., vic.exe) 501 +----------------+--------------+--------------+--------------+ 503 5. Operation 505 +-----+ +-----+ 506 | PDP |-------+ | PDP | 507 +-----+ | ................... +-----+ 508 | : : | 509 +--------+ : Transit : +-------+ 510 +----| Router |------: Network : -------| Router|--+ 511 | +--------+ : : +-------+ | 512 | | :.................: | | 513 | | | | 514 Host A B C D 516 Figure 1: User and Application Authentication using AUTH_DATA PE 518 Network nodes (hosts/routers) generate AUTH_DATA policy elements, 519 contents of which are depend on the identity type used and the 520 authentication method used. These generally contain authentication 521 credentials (Kerberos ticket or digital certificate) and policy 522 locators (which can be the X.500 Distinguished Name of the user or 523 network node or application names). Network nodes generate AUTH_DATA 524 policy element containing the authentication identity when making the 525 RSVP request or forwarding a RSVP message. 527 Network nodes generate user AUTH_DATA policy element using the 528 following rules 530 1. For unicast sessions the user policy locator is copied from the 531 previous hop. The authentication credentials are for the current 532 network node identity. 534 2. For multicast messages the user policy locator is for the current 535 network node identity. The authentication credentials are for the 536 current network node. 538 RFC xxxx Identity Representation for RSVP January 2000 540 Network nodes generate application AUTH_DATA policy element using the 541 following rules: 543 1. For unicast sessions the application AUTH_DATA is copied from the 544 previous hop. 546 2. For multicast messages the application AUTH_DATA is either the 547 first application AUTH_DATA in the message or chosen by the PDP. 549 6. Message Processing Rules 551 6.1 Message Generation (RSVP Host) 553 An RSVP message is created as specified in [RFC2205] with following 554 modifications. 556 1. RSVP message MAY contain multiple AUTH_DATA policy elements. 558 2. Authentication policy element (AUTH_DATA) is created and the 559 IdentityType field is set to indicate the identity type in the 560 policy element. 562 - DN is inserted as POLICY_LOCATOR attribute. 564 - Credentials such as Kerberos ticket or digital certificate are 565 inserted as the CREDENTIAL attribute. 567 3. POLICY_DATA object (containing the AUTH_DATA policy element) is 568 inserted in the RSVP message in appropriate place. If INTEGRITY 569 object is not computed for the RSVP message then an INTEGRITY 570 object SHOULD be computed for this POLICY_DATA object, as 571 described in the [POL_EXT], and SHOULD be inserted as a Policy 572 Data option. 574 6.2 Message Reception (Router) 576 RSVP message is processed as specified in [RFC2205] with following 577 modifications. 579 1. If router is not policy aware then it SHOULD send the RSVP message 580 to the PDP and wait for response. If the router is policy unaware 581 then it ignores the policy data objects and continues processing 582 the RSVP message. 584 2. Reject the message if the response from the PDP is negative. 586 3. Continue processing the RSVP message. 588 RFC xxxx Identity Representation for RSVP January 2000 590 6.3 Authentication (Router/PDP) 592 1. Retrieve the AUTH_DATA policy element. Check the PE type field and 593 return an error if the identity type is not supported. 595 2. Verify user credential 597 - Simple authentication: e.g. Get user ID and validate it, or get 598 executable name and validate it. 600 - Kerberos: Send the Kerberos ticket to the KDC to obtain the 601 session key. Using the session key authenticate the user. 603 - Public Key: Validate the certificate that it was issued by a 604 trusted Certificate Authority (CA) and authenticate the user or 605 application by verifying the digital signature. 607 7. Error Signaling 609 If PDP fails to verify the AUTH_DATA policy element then it MUST 610 return policy control failure (Error Code = 02) to the PEP. The error 611 values are described in [RFC 2205] and [POL-EXT]. Also PDP SHOULD 612 supply a policy data object containing an AUTH_DATA Policy Element 613 with A-Type=POLICY_ERROR_CODE containing more details on the Policy 614 Control failure (see section 3.3.4). The PEP will include this Policy 615 Data object in the outgoing RSVP Error message. 617 8. IANA Considerations 619 Following the policies outlined in [IANA-CONSIDERATIONS], 620 authentication attribute types (A-Type)in the range 0-127 are 621 allocated through an IETF Consensus action, A-Type values between 622 128-255 are reserved for Private Use and are not assigned by IANA. 624 Following the policies outlined in [IANA-CONSIDERATIONS], 625 POLICY_LOCATOR SubType values in the range 0-127 are allocated 626 through an IETF Consensus action, POLICY_LOCATOR SubType values 627 between 128-255 are reserved for Private Use and are not assigned by 628 IANA. 630 Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL 631 SubType values in the range 0-127 are allocated through an IETF 632 Consensus action, CREDENTIAL SubType values between 128-255 are 633 reserved for Private Use and are not assigned by IANA. 635 RFC xxxx Identity Representation for RSVP January 2000 637 9. Security Considerations 639 The purpose of this memo is to describe a mechanism to authenticate 640 RSVP requests based on user identity in a secure manner. RSVP 641 INTEGRITY object is used to protect the policy object containing user 642 identity information from security (replay) attacks. Combining the 643 AUTH_DATA policy element and the INTEGRITY object results in a secure 644 access control that enforces authentication based on both the 645 identity of the user and the identity of the originating node. 647 Simple authentication does not contain credential that can be 648 securely authenticated and is inherently less secured. 650 The Kerberos authentication mechanism is reasonably well secured. 652 User authentication using a public key certificate is known to 653 provide the strongest security. 655 10. Acknowledgments 657 We would like to thank Andrew Smith, Bob Lindell and many others for 658 their valuable comments on this memo. 660 11. References 662 [ASCII] Coded Character Set -- 7-Bit American Standard 663 Code for Information Interchange, ANSI X3.4- 664 1986. 666 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 667 Writing an IANA Considerations Section in 668 RFCs", BCP 26, RFC 2434, October 1998. 670 [POL-EXT] Herzog, S., "RSVP Extensions for Policy 671 Control", RFC 2750, January 2000. 673 [POL-FRAME] Yavatkar, R., Pendarakis, D. and R. Guerin, "A 674 Framework for Policy-based Admission Control 675 RSVP", RFC 2753, January 2000. 677 [RFC 1510] Kohl, J. and C. Neuman, "The Kerberos Network 678 Authentication Service (V5)", RFC 1510, 679 September 1993. 681 [RFC 1704] Haller, N. and R. Atkinson, "On Internet 682 Authentication", RFC 1704, October 1994. 684 RFC xxxx Identity Representation for RSVP January 2000 686 [RFC 1779] Killie, S., "A String Representation of 687 Distinguished Names", RFC 1779, March 1995. 689 [RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. 690 and S. Jamin, "Resource ReSerVation Protocol 691 (RSVP) - Version 1 Functional Specification", 692 RFC 2205, September 1997. 694 [RFC 2209] Braden, R. and L. Zhang, "Resource ReSerVation 695 Protocol (RSVP) - Version 1 Message Processing 696 Rules", RFC 2209, September 1997. 698 [UNICODE] The Unicode Consortium, "The Unicode Standard, 699 Version 2.0", Addison-Wesley, Reading, MA, 700 1996. 702 [X.509] Housley, R., Ford, W., Polk, W. and D. Solo, 703 "Internet X.509 Public Key Infrastructure 704 Certificate and CRL Profile", RFC 2459, January 705 1999. 707 [X.509-ITU] ITU-T (formerly CCITT) Information technology - 708 Open Systems Interconnection - The Directory: 709 Authentication Framework Recommendation X.509 710 ISO/IEC 9594-8 712 RFC xxxx Identity Representation for RSVP January 2000 714 12. Author Information 716 Satyendra Yadav 717 Intel, JF3-206 718 2111 NE 25th Avenue 719 Hillsboro, OR 97124 721 EMail: Satyendra.Yadav@intel.com 723 Raj Yavatkar 724 Intel, JF3-206 725 2111 NE 25th Avenue 726 Hillsboro, OR 97124 728 EMail: Raj.Yavatkar@intel.com 730 Ramesh Pabbati 731 Microsoft 732 1 Microsoft Way 733 Redmond, WA 98054 735 EMail: rameshpa@microsoft.com 737 Peter Ford 738 Microsoft 739 1 Microsoft Way 740 Redmond, WA 98054 742 EMail: peterf@microsoft.com 744 Tim Moore 745 Microsoft 746 1 Microsoft Way 747 Redmond, WA 98054 749 EMail: timmoore@microsoft.com 751 Shai Herzog 752 IPHighway, Inc. 753 55 New York Avenue 754 Framingham, MA 01701 756 EMail: herzog@iphighway.com 758 RFC xxxx Identity Representation for RSVP January 2000 760 13. Full Copyright Statement 762 Copyright (C) The Internet Society (2000). All Rights Reserved. 764 This document and translations of it may be copied and furnished to 765 others, and derivative works that comment on or otherwise explain it 766 or assist in its implementation may be prepared, copied, published 767 and distributed, in whole or in part, without restriction of any 768 kind, provided that the above copyright notice and this paragraph are 769 included on all such copies and derivative works. However, this 770 document itself may not be modified in any way, such as by removing 771 the copyright notice or references to the Internet Society or other 772 Internet organizations, except as needed for the purpose of 773 developing Internet standards in which case the procedures for 774 copyrights defined in the Internet Standards process must be 775 followed, or as required to translate it into languages other than 776 English. 778 The limited permissions granted above are perpetual and will not be 779 revoked by the Internet Society or its successors or assigns. 781 This document and the information contained herein is provided on an 782 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 783 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 784 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 785 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 786 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 788 Acknowledgement 790 Funding for the RFC Editor function is currently provided by the 791 Internet Society.