idnits 2.17.1 draft-ietf-rap-rsvp-identity-02.txt: ** The Abstract section seems to be numbered -(495): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 19 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 825 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 22 instances of lines with control characters in the document. ** The abstract seems to contain references ([POL-EXT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1999) is 9233 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 60, but not defined == Missing Reference: 'RFC 1633' is mentioned on line 64, but not defined == Missing Reference: 'RFC 1509' is mentioned on line 230, but not defined ** Obsolete undefined reference: RFC 1509 (Obsoleted by RFC 2744) == Missing Reference: 'RFC2205' is mentioned on line 560, but not defined == Unused Reference: 'ASCII' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC 1704' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'RFC 2209' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 671, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- No information found for draft-ietf-rap-policy-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'POL-EXT' == Outdated reference: A later version (-03) exists of draft-ietf-rap-framework-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. 'POL-FRAME') ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 1704 ** Obsolete normative reference: RFC 1779 (Obsoleted by RFC 2253, RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 2209 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' Summary: 17 errors (**), 0 flaws (~~), 14 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Satyendra Yadav 2 File: Raj Yavatkar 3 Intel 4 Ramesh Pabbati 5 Peter Ford 6 Tim Moore 7 Microsoft 8 Shai Herzog 9 IPHighway 11 Identity Representation for RSVP 12 January 1999 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a 25 "working draft" or "work in progress". 27 To view the list Internet-Draft Shadow Directories, see 28 http://www.ietf.org/shadow.html. 30 A Revised Version of this draft document will be submitted to the 31 RFC editor as a Proposed Standard for the Internet Community. 32 Discussion and suggestions for improvement are requested. This 33 document will expire in July 1999. Distribution of this draft is 34 unlimited. 36 Copyright Notice 38 Copyright (C) The Internet Society (1999). All Rights Reserved. 40 1. Abstract 42 This document describes the representation of identity information 43 in POLICY_DATA object [POL-EXT] for supporting policy based 44 admission control in RSVP. The goal of identity representation is to 45 allow a process on a system to securely identify the owner and the 46 application of the communicating process (e.g. user id) and convey 47 this information in RSVP messages (PATH or RESV) in a secure manner. 48 We describe the encoding of identities as RSVP policy element. We 49 describe the processing rules to generate identity policy elements 50 for multicast merged flows. Subsequently, we describe 51 representations of user identities for Kerberos and Public Key based 52 user authentication mechanisms. In summary we describe the use of 53 this identity information in an operational setting. 55 2. Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 59 this document are to be interpreted as described in [RFC-2119]. 61 3. Introduction 63 RSVP [RFC 2205] is a resource reservation setup protocol designed 64 for an integrated services Internet [RFC 1633]. RSVP is used by a 65 host to request specific quality of service (QoS) from the network 66 for particular application data streams or flows. RSVP is also used 67 by routers to deliver QoS requests to all nodes along the path(s) of 68 the flows and to establish and maintain state to provide the 69 requested service. RSVP requests will generally result in resources 70 being reserved in each node along the data path. RSVP allows 71 particular users to obtain preferential access to network resources, 72 under the control of an admission control mechanism. Permission to 73 make a reservation is based both upon the availability of the 74 requested resources along the path of the data and upon satisfaction 75 of policy rules. Providing policy based admission control mechanism 76 based on user identity or application is one of the prime 77 requirements. 79 In order to solve these problems and implement user based policy 80 control it is required to identify the user making an 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 of the user requesting resources from 84 the network. 86 We describe the authentication policy element (AUTH_DATA) contained 87 in the POLICY_DATA object. User process can generates an AUTH_DATA 88 policy element and gives it to RSVP process (service) on the 89 originating host. RSVP service inserts AUTH_DATA into the RSVP 90 message to identify the owner (user) making the request for network 91 resources. Network elements, such as routers, authenticate user 92 using the credentials presented in the AUTH_DATA and admit the RSVP 93 message based on admission policy. After a request has been 94 authenticated, first hop router installs the RSVP state and forwards 95 the new policy element returned by the Policy Decision Point (PDP) 96 [POL-FRAME]. 98 4. Policy Element for Authentication Data 100 4.1 Policy Data Object Format 102 POLICY_DATA objects contain policy information and are carried by 103 RSVP messages. A detail description of the format of POLICY_DATA 104 object can be found in "RSVP Extensions for Policy Control" [POL- 105 EXT]. 107 4.2 Authentication Data Policy Element 109 In this section, we describe a policy element (PE) called 110 authentication data (AUTH_DATA). AUTH_DATA policy element contains a 111 list of authentication attributes. Policy object containing 112 AUTH_DATA must be protected against replay attacks using INTEGRITY 113 object option as described in the [POL-EXT]. 115 +-------------+-------------+-------------+-------------+ 116 | Length | P-Type = Identity Type | 117 +-------------+-------------+-------------+-------------+ 118 // Authentication Attribute List // 119 | | 120 +-------------------------------------------------------+ 122 Length 123 The length of the policy element (including the Length and P- 124 Type) is in number of octets (must be a multiple of 4) and 125 indicates the end of the authentication attribute list. 127 Identity Type 128 Type of identity information contained in this Policy Element 129 supplied as the Policy element type (P-type). The Internet 130 Assigned Numbers Authority (IANA) acts as a registry for 131 identity types as described in the section 10, IANA 132 Considerations. Initially, the registry contains the following 133 identity types: 135 2 AUTH_USER authentication scheme to identify users 137 3 AUTH_APP authentication scheme to identify 138 applications 140 Reserved 141 Must be set to 0. 143 Authentication Attribute List 145 Authentication attributes contain information specific to 146 authentication method and type of AUTH DATA. The policy element 147 provides the mechanism for grouping a collection of 148 authentication attributes. 150 4.3 Authentication Attributes 152 Authentication attributes must be encoded as a multiple of 4 octets, 153 attributes that are not a multiple of 4 octets long must be padded 154 to a 4-octet boundary. 156 +--------+--------+--------+--------+ 157 | Length | A-Type |SubType | 158 +--------+--------+--------+--------+ 159 | Value � 160 +--------+--------+--------+--------+ 162 Length 163 The length field is two octets and indicates the actual length 164 of the attribute (including the Length and A-Type fields) in 165 number of octets. The length does not include any bytes padding 166 the attribute to make it multiple of 4 octets long. 168 A-Type 169 Authentication attribute type (A-Type) field is one octet. IANA 170 acts as a registry for A-Types as described in the section 10, 171 IANA Considerations. Initially, the registry contains the 172 following A-Types: 174 1 POLICY_LOCATOR Unique string for locating the 175 admission policy (such as X.500 DN 176 described in [RFC 1779]). 178 2 CREDENTIAL User credential such as Kerberos 179 ticket, or digital certificate. 180 Application credential such as 181 application ID. 183 3 DIGITAL_SIGNATURE Digital signature of the 184 authentication data policy element. 186 4 POLICY_ERROR_OBJECT Detailed information on policy 187 failures. 189 SubType 190 Authentication attribute sub-type field is one octet. Value of 191 SubType depends on A-type. 193 Value: 194 The value field contains 0-65351 octets. 196 4.3.1 Policy Locator 198 POLICY_LOCATOR is used to locate the admission policy for the user 199 or application. Distinguished Name (DN) is unique for each User or 200 application hence a DN is used as policy locator. 202 +-------+-------+-------+-------+ 203 | Length |A-Type |SubType| 204 +-------+-------+-------+-------+ 205 | OctetString � 206 +-------+-------+-------+-------- 208 Length 209 > 4 211 A-Type 212 POLICY_LOCATOR 214 SubType 215 Following sub types for POLICY_LOCATOR are defined.IANA acts as 216 a registry for POLICY_LOCATOR sub types as described in the 217 section 10, IANA Considerations. Initially, the registry 218 contains the following sub types for POLICY_LOCATOR: 220 1 ASCII DN OctetString contains the X.500 DN as described 221 in the RFC 1779 as an ASCII string. 223 2 UNICODE_DN OctetString contains the X.500 DN described in 224 the RFC 1779 as an UNICODE string. 226 3 ASCII_DN_ENCRYPT OctetString contains the encrypted X.500 227 DN. The Kerberos session key or digital 228 certificate private key is used for encryption. 229 For Kerberos encryption the format is the same 230 as returned from gss_seal [RFC 1509]. 232 4 UNICODE_DN_ENCRYPT OctetString contains the encrypted 233 UNICODE X.500 DN. The Kerberos session key or 234 digital certificate private key is used for 235 encryption. For Kerberos encryption the format 236 is the same as returned from gss_seal [RFC 237 1509]. 239 OctetString 240 The OctetString field contains the DN. 242 4.3.2 Credential 244 CREDENTIAL indicates the credential of the user or application to be 245 authenticated. For Kerberos authentication method the CREDENTIAL 246 object contains the Kerberos session ticket. For public key based 247 authentication this field contains a digital certificate. 249 A summary of the CREDENTIAL attribute format is shown below. The 250 fields are transmitted from left to right. 252 +-------+-------+-------+-------+ 253 | Length |A-Type |SubType| 254 +-------+-------+-------+-------+ 255 | OctetString � 256 +-------+-------+-------+-------- 258 Length 259 > 4 261 A-Type 262 CREDENTIAL 264 SubType 265 IANA acts as a registry for CREDENTIAL sub types as described in 266 the section 10, IANA Considerations. Initially, the registry 267 contains the following sub types for CREDENTIAL: 269 1 ASCII_ID OctetString contains user or application 270 identification in plain ASCII text string. 272 2 UNICODE_ID OctetString contains user or application 273 identification in plain UNICODE text string. 275 3 KERBEROS_TKT OctetString contains Kerberos ticket. 277 4 X509_V3_CERT OctetString contains X.509 V3 digital 278 certificate [X.509]. 280 5 PGP_CERT OctetString contains PGP digital certificate. 282 OctetString 283 The OctetString contains the user or application credential. 285 4.3.3 Digital Signature 287 The DIGITAL_SIGNATURE attribute must be the last attribute in the 288 attribute list and contains the digital signature of the AUTH_DATA 289 policy element. The digital signature signs all data in the 290 AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm 291 used to compute the digital signature depends on the authentication 292 method specified by the CREDENTIAL SubType field. 294 A summary of DIGITAL_SIGNATURE attribute format is described below. 296 +-------+-------+-------+-------+ 297 | Length |A-Type |SubType| 298 +-------+-------+-------+-------+ 299 | OctetString � 300 +-------+-------+-------+-------- 302 Length 303 > 4 305 A-Type 306 DIGITAL_SIGNATURE 308 SubType 309 No sub types for DIGITAL_SIGNATURE are currently defined. This 310 field must be set to 0. 312 OctetString 313 OctetString contains the digital signature of the AUTH_DATA. 315 4.3.4 Policy Error Object 317 This attribute is used to specify any errors associated with the 318 policy element. When a RSVP policy node (local policy decision point 319 or remote PDP) encounters a request that fails policy control due to 320 its Authentication Policy Element, it may add a POLICY_ERROR_CODE 321 containing additional information about the reason the failure 322 occurred into the policy element. This will then cause an 323 appropriate PATH_ERROR or RESV_ERROR message to be generated with 324 the policy element and appropriate RSVP error code in the message, 325 which is returned to the request's source. 327 The AUTH DATA policy element in the PATH or RSVP message does not 328 contain the POLICY_ERROR_OBJECT attribute. 330 +-------+-------+-------+-------+ 331 | Length |A-Type | 0 | 332 +-------+-------+-------+-------+ 333 | 0 (Reserved) |Error value | 334 +-------+-------+-------+-------+ 335 | OctetString 336 +-------+-------+-------+-------- 338 Length 339 >= 8 341 A-Type 342 POLICY_ERROR_CODE 344 Error Value 345 A 32-bit bit code containing the reason that the policy 346 decision point failed to process the policy element. The 347 standard values are 349 ERROR_NO_MORE_INFO 1 no information is available 350 UNKNOWN_CREDENTIAL 2 the credentials are unknown 351 NO_PRIVILEGES 3 the credential has no privilege 352 EXPIRED_CREDENTIAL 4 the credential has expired 353 IDENTITY_CHANGED 5 identity has changed 355 OctetString 356 The OctetString field contains information from the policy 357 decision point that may contain additional information about 358 the failure. For example 360 "MSFT", DEF_SUBNET FLOW_RATE, CONTROLLED LOAD, 10000, 10000, 361 1000, 0, 0, 1000, 1000 363 This example contains an identification string for the policy 364 decision point, more information about why the policy decision 365 point failed. In this case, the subnet default policy on Token 366 bucket rate failed and the flow spec that caused the failure is 367 also returned. 369 5. Authentication Data Formats 371 Authentication attributes are grouped in a policy element to 372 represent the identity credentials. 374 5.1 Simple User Authentication 376 In simple user authentication method the user login ID (in plain 377 ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary 378 of the simple user AUTH_DATA policy element is shown below. 380 +--------------+--------------+--------------+--------------+ 381 | Length | P-type = AUTH_USER | 382 +--------------+--------------+--------------+--------------+ 383 | Length |POLICY_LOCATOR| SubType | 384 +--------------+--------------+--------------+--------------+ 385 | OctetString (User's Distinguished Name) � 386 +--------------+--------------+--------------+--------------+ 387 | Length |CREDENTIAL | ASCII_ID | 388 +--------------+--------------+--------------+--------------+ 389 | OctetString (User's login ID) � 390 +--------------+--------------+--------------+--------------+ 392 5.2 Kerberos User Authentication 394 Kerberos [RFC 1510] authentication uses a trusted third party (the 395 Kerberos Distribution Center � KDC) to provide for authentication of 396 the user to a network server. It is assumed that a KDC is present 397 and both host and verifier of authentication information (router or 398 PDP) implement Kerberos authentication. 400 A summary of the Kerberos AUTH_DATA policy element is shown below. 402 +--------------+--------------+--------------+--------------+ 403 | Length | P-type (AUTH_USER) | 404 +--------------+--------------+--------------+--------------+ 405 | Length |POLICY_LOCATOR| SubType | 406 +--------------+--------------+--------------+--------------+ 407 | OctetString (User's Distinguished Name) � 408 +--------------+--------------+--------------+--------------+ 409 | Length | CREDENTIAL | KERBEROS_TKT | 410 +--------------+--------------+--------------+--------------+ 411 | OctetString (Kerberos Session Ticket) � 412 +--------------+--------------+--------------+--------------+ 414 5.2.1. Operational Setting using Kerberos Identities 416 An RSVP enabled host is configured to construct and insert AUTH_DATA 417 policy element into RSVP messages that designate use of the Kerberos 418 authentication method (KERBEROS_TKT). Upon RSVP session 419 initialization, the user application contacts the KDC to obtain a 420 Kerberos ticket for the next network node or its PDP. A router when 421 generating a RSVP message contacts the KDC to obtain a Kerberos 422 ticket for the next hop network node or its PDP. The identity of the 423 PDP or next network hop can be statically configured, learned via 424 DHCP or maintained in a directory service. The Kerberos ticket is 425 sent to the next network node (which may be a router or host) in a 426 RSVP message. The KDC is used to validate the ticket and 427 authentication the user sending RSVP message. 429 5.3 Public Key based User Authentication 431 In public key based user authentication method digital certificate 432 is encoded as user credentials. The digital signature is used for 433 authenticating the user. A summary of the public key user AUTH_DATA 434 policy element is shown below. 436 +--------------+--------------+--------------+--------------+ 437 | Length | P-type (AUTH_USER) | 438 +--------------+--------------+--------------+--------------+ 439 | Length |POLICY_LOCATOR| SubType | 440 +--------------+--------------+--------------+--------------+ 441 | OctetString (User's Distinguished Name) � 442 +--------------+--------------+--------------+--------------+ 443 | Length | CREDENTIAL | SubType | 444 +--------------+--------------+--------------+--------------+ 445 | OctetString (User's Digital Certificate)� 446 +--------------+--------------+--------------+--------------+ 447 | Length |DIGITAL_SIGN. | 0 | 448 +--------------+--------------+--------------+--------------+ 449 | OctetString (Digital signature) � 450 +--------------+--------------+--------------+--------------+ 452 5.3.1. Operational Setting for public key based authentication 454 Public key based authentication assumes following: 456 - RSVP service requestors have a pair of keys (private key and 457 public key). 459 - Private key is secured with the user. 461 - Public keys are stored in digital certificates and a trusted 462 party, certificate authority (CA) issues these digital 463 certificates. 465 - The verifier (PDP or router) has the ability to verify the 466 digital certificate. 468 RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. 469 User Authenticators (router, PDP) use the user's public key (stored 470 in the digital certificate) to verify the signature and authenticate 471 the user. 473 5.4 Simple Application Authentication 475 The application authentication method encodes the application 476 identification such as an executable filename as plain ASCII or 477 UNICODE text. 479 +----------------+--------------+--------------+--------------+ 480 | Length | P-type = AUTH_APP | 481 +----------------+--------------+--------------+--------------+ 482 | Length |POLICY_LOCATOR| SubType | 483 +----------------+--------------+--------------+--------------+ 484 | OctetString (Application Distinguished Name) � 485 +----------------+--------------+--------------+--------------+ 486 | Length | CREDENTIAL | ASCII_ID | 487 +----------------+--------------+--------------+--------------+ 488 | OctetString (Application Id � ex: vic.exe) 489 +----------------+--------------+--------------+--------------+ 491 6. Operation 493 +-----+ +-----+ 494 | PDP |-------+ | PDP | 495 +-----+ | �������������.��. +-----+ 496 | : : | 497 +--------+ : Transit : +-------+ 498 +----| Router |------: Network : -------| Router|--+ 499 | +--------+ : : +-------+ | 500 | | :��������������...: | | 501 | | | | 502 Host A B C D 504 Figure 1: User and Application Authentication using AUTH_DATA PE 506 Network nodes (hosts/routers) generate AUTH_DATA policy elements, 507 contents of which are depends on the identity type used and the 508 authentication method used. But generally contains authentication 509 credentials (Kerberos ticket or digital certificate) and policy 510 locators (which can be the X.500 Distinguished Name of the user or 511 network node or application names). Network nodes generate AUTH_DATA 512 policy element containing the authentication identity when making the 513 RSVP request or forwarding an RSVP message. 515 Network nodes generate user AUTH_DATA policy element using the 516 following rules 518 1. For unicast sessions the user policy locator is the copied from 519 the previous hop. The authentication credentials are for the 520 current network node identity. 521 2. For multicast messages the user policy locator is for the current 522 network node identity. The authentication credentials are for the 523 current network node. 525 Network nodes generate application AUTH_DATA policy element using the 526 following rules: 528 1. For unicast sessions the application AUTH_DATA is the copied from 529 the previous hop. 531 2. For multicast messages the application AUTH_DATA is either the 532 first application AUTH_DATA in the message or chosen by the PDP. 534 7. Message Processing Rules 536 7.1 Message Generation (RSVP Host) 538 An RSVP message is created as specified in [RFC2205] with following 539 modifications. 541 1. RSVP message may contain multiple AUTH_DATA policy elements. 543 2. Authentication policy element (AUTH_DATA) is created and the 544 IdentityType field is set to indicate the identity type in the 545 policy element. 547 DN is inserted as POLICY_LOCATOR attribute. 549 Credentials such as Kerberos ticket or digital certificate are 550 inserted as the CREDENTIAL attribute. 552 3. POLICY_DATA object (containing the AUTH DATA policy element) is 553 inserted in the RSVP message in appropriate place. If INTEGRITY 554 object is not computed for the RSVP message then an INTEGRITY 555 object must be computed for this POLICY_DATA object, as described 556 in the [POL_EXT], and must be inserted as an Policy Data option. 558 7.2 Message Reception (Router) 560 RSVP message is processed as specified in [RFC2205] with following 561 modifications. 563 1. If router is not policy aware then it should send the RSVP 564 message to the PDP and wait for response. If the router is policy 565 unaware then it ignores the policy data objects and continues 566 processing the RSVP message. 568 2. Reject the message if the response from the PDP is negative. 570 3. Continue processing the RSVP message. 572 7.3 Authentication (Router/PDP) 574 1. Retrieve the AUTH_DATA policy element. Check the PE type field 575 and return an error if the identity type is not supported. 577 2. Verify user credential 579 - Simple authentication: e.g. Get user ID and validate it, or 580 get executable name and validate it. 582 - Kerberos: Send the Kerberos ticket to the KDC to obtain the 583 session key. Using the session key authenticate the user. 585 - Public Key: Validate the certificate that it was issued by a 586 trusted Certificate Authority (CA) and authenticate the user 587 or application by verifying the digital signature. 589 8. Error Signaling 591 If PDP fails to verify the AUTH_DATA policy element then it must 592 return Policy control failure (Error Code = 02) to PEP. The error 593 values are described in [RFC 2205] and [POL-EXT]. Also PDP must 594 supply a policy data object containing the AUTH DATA Policy Element 595 with more details on the Policy Control failures in the policy error 596 object attribute. The PEP will include this Policy Data object in 597 the outgoing RSVP Error message. 599 9. IANA Considerations 601 Following the policies outlined in [IANA-CONSIDERATIONS], 602 authentication attribute types (A-Type)in the range 0-127 are 603 allocated an IETF Consensus action, A-Type values between 128-255 604 are reserved for Private Use and are not assigned by IANA. 606 Following the policies outlined in [IANA-CONSIDERATIONS], 607 POLICY_LOCATOR SubType values in the range 0-127 are allocated an 608 IETF Consensus action, POLICY_LOCATOR SubType values between 128-255 609 are reserved for Private Use and are not assigned by IANA. 611 Following the policies outlined in [IANA-CONSIDERATIONS], 612 CREDENTIAL SubType values in the range 0-127 are allocated an IETF 613 Consensus action, CREDENTIAL SubType values between 128-255 are 614 reserved for Private Use and are not assigned by IANA. 616 10. Security Considerations 618 The purpose of this draft is to describe a mechanism to authenticate 619 RSVP requests based on user identity in a secure manner. RSVP 620 INTEGRITY object is used to protect the policy object containing 621 user identity information from security (replay) attacks. Combining 622 the AUTH_DATA policy element and the INTEGRITY object results in a 623 secure access control that enforces authentication based on both the 624 identity of the user and the identity of the originating node. 626 Simple authentication does not contain credential that can be 627 securely authenticated and is inherently less secured. 629 The Kerberos authentication mechanism is reasonably well secured. 631 User authentication using a public key certificate is known to 632 provide the strongest security. 634 11. Acknowledgments 636 We would like to thank Andrew Smith, Bob Lindell and many others for 637 their valuable comments on this draft. 639 12. References 641 [ASCII] Coded Character Set -- 7-Bit American Standard Code for 642 Information Interchange, ANSI X3.4-1986. 644 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 645 Writing an IANA Considerations Section in RFCs", BCP 26, 646 RFC 2434, October 1998. 648 [POL-EXT] Herzog, S., "RSVP Extensions for Policy Control." 649 Internet-Draft, draft-ietf-rap-policy-ext-02.txt, 650 January 1999. 652 [POL-FRAME] Yavatkar, R., et.al. "A Framework for Policy-based 653 Admission Control RSVP." Internet-Draft, draft-ietf-rap- 654 framework-01.txt, November 1998. 656 [RFC 1510] The Kerberos Network Authentication Service (V5). Kohl 657 J., Neuman, C. RFC 1510. 659 [RFC 1704] On Internet Authentication. Haller, N, Atkinson, R., 660 RFC 1704. 662 [RFC 1779] A String Representation of Distinguished Names. S. 663 Kille. RFC 1779 665 [RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol 666 (RSVP) � Version 1 Functional Specification." RFC 2205. 668 [RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol 669 (RSVP) - Version 1 Message Processing Rules." RFC 2209. 671 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 672 2.0", Addison-Wesley, Reading, MA, 1996. 674 [X.509] R. Housley, et. al., "Internet X.509 Public Key 675 Infrastructure Certificate and CRL Profile", Internet- 676 Draft, draft-ietf-pkix-ipki-part1-11.txt, September 677 1998. 679 [X.509-ITU] ITU-T (formerly CCITT) Information technology � Open 680 Systems Interconnection � The Directory: Authentication 681 Framework Recommendation X.509 ISO/IEC 9594-8 683 13. Author Information 685 Satyendra Yadav 686 Intel, JF3-206 687 2111 NE 25th Avenue 688 Hillsboro, OR 97124 690 Satyendra.Yadav@intel.com 692 Raj Yavatkar 693 Intel, JF3-206 694 2111 NE 25th Avenue 695 Hillsboro, OR 97124 697 Raj.Yavatkar@intel.com 699 Ramesh Pabbati 700 Microsoft 701 1 Microsoft Way 702 Redmond, WA 98054 704 rameshpa@microsoft.com 706 Peter Ford 707 Microsoft 708 1 Microsoft Way 709 Redmond, WA 98054 711 peterf@microsoft.com 713 Tim Moore 714 Microsoft 715 1 Microsoft Way 716 Redmond, WA 98054 718 timmoore@microsoft.com 720 Shai Herzog 721 IPHighway 722 2055 Gateway Pl., Suite 400 723 San Jose, CA 95110 725 herzog@iphighway.com 727 14. Full Copyright Statement 729 Copyright (C) The Internet Society (1999). All Rights Reserved. 731 This document and translations of it may be copied and furnished to 732 others, and derivative works that comment on or otherwise explain it 733 or assist in its implementation may be prepared, copied, published 734 and distributed, in whole or in part, without restriction of any 735 kind, provided that the above copyright notice and this paragraph 736 are included on all such copies and derivative works. However, this 737 document itself may not be modified in any way, such as by removing 738 the copyright notice or references to the Internet Society or other 739 Internet organizations, except as needed for the purpose of 740 developing Internet standards in which case the procedures for 741 copyrights defined in the Internet Standards process must be 742 followed, or as required to translate it into languages other than 743 English. 745 The limited permissions granted above are perpetual and will not be 746 revoked by the Internet Society or its successors or assigns. 748 This document and the information contained herein is provided on an 749 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 750 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 751 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 752 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 753 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 754 Yadav, et al. 3 756 Yadav, et al. 1