idnits 2.17.1 draft-ietf-rap-rsvp-identity-00.txt: ** The Abstract section seems to be numbered -(337): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(448): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(455): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(589): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(664): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(673): 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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 21 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 14 longer pages, the longest (page 11) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([POL-EXT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 46 has weird spacing: '...ding of ident...' -- 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 (November 1998) is 9293 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 59, but not defined == Missing Reference: 'RFC 1633' is mentioned on line 63, but not defined == Missing Reference: 'RFC 1509' is mentioned on line 224, but not defined ** Obsolete undefined reference: RFC 1509 (Obsoleted by RFC 2744) == Missing Reference: 'RFC2205' is mentioned on line 518, but not defined == Missing Reference: 'COPS-RSVP' is mentioned on line 634, but not defined == Unused Reference: 'ASCII' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'RFC 1704' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC 2209' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 669, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' == Outdated reference: A later version (-08) exists of draft-ietf-rsvp-md5-07 -- No information found for draft-ietf-rap-policy-ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'POL-EXT' ** 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: 15 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: Intel 3 Ramesh Pabbati 4 Microsoft 5 Tim Moore 6 Microsoft 7 Shai Herzog 8 IPHighway 10 Identity Representation for RSVP 11 November 1998 13 Status of this Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a 24 "working draft" or "work in progress". 26 To view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 A Revised Version of this draft document will be submitted to the 33 RFC editor as a Proposed Standard for the Internet Community. 34 Discussion and suggestions for improvement are requested. This 35 document will expire in May 1999. Distribution of this draft is 36 unlimited. 38 1. Abstract 40 This document describes the representation of identity information 41 in POLICY_DATA object [POL-EXT] for supporting policy based 42 admission control in RSVP. The goal of identity representation is to 43 allow a process on a system to securely identify the owner of the 44 communicating process (e.g. user id) and convey this information in 45 RSVP messages (PATH or RESV) in a secure manner. We describe the 46 encoding of identities as RSVP policy element. We describe the 47 processing rules to generate identity policy elements for multicast 48 merged flows. Subsequently, we describe representations of user 49 identities for Kerberos and Public Key based user authentication 50 mechanisms. In summary we describe the use of this identity 51 information in an operational setting. 53 Yadav, et al. 1 54 2. Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 58 this document are to be interpreted as described in [RFC-2119]. 60 3. Introduction 62 RSVP [RFC 2205] is a resource reservation setup protocol designed 63 for an integrated services Internet [RFC 1633]. RSVP is used by a 64 host to request specific quality of service (QoS) from the network 65 for particular application data streams or flows. RSVP is also used 66 by routers to deliver QoS requests to all nodes along the path(s) of 67 the flows and to establish and maintain state to provide the 68 requested service. RSVP requests will generally result in resources 69 being reserved in each node along the data path. RSVP allows 70 particular users to obtain preferential access to network resources, 71 under the control of an admission control mechanism. Permission to 72 make a reservation is based both upon the availability of the 73 requested resources along the path of the data and upon satisfaction 74 of policy rules. Providing policy based admission control mechanism 75 based on user identity is one of the prime requirements. 77 In order to solve these problems and implement user based policy 78 control it is required to identify the user making an RSVP request. 79 This document proposes a mechanism for sending identification 80 information in the RSVP requests and enables authorization decisions 81 based on policy and identity of the user requesting resources from 82 the network. 84 We describe the authentication policy element (AUTH_DATA) contained 85 in the POLICY_DATA object. User process generates an AUTH_DATA 86 policy element and gives it to RSVP process (service) on the 87 originating host. RSVP process inserts AUTH_DATA into the RSVP 88 message to identify the owner (user) making the request for network 89 resources. Network elements, such as routers, authenticate user 90 using the credentials presented in the AUTH_DATA and admit the RSVP 91 message based on admission policy. After a request has been 92 authenticated, first hop router installs the RSVP state and forwards 93 the new policy element returned by the policy server. 95 Yadav, et al. 2 96 4. Policy Element for Authentication Data 98 4.1 Policy Data Object Format 100 POLICY_DATA objects contain policy information and are carried by 101 RSVP messages. A detail description of the format of POLICY_DATA 102 object can be found in �RSVP Extensions for Policy Control� [POL- 103 EXT]. 105 4.2 Authentication Data Policy Element 107 In this section, we describe a policy element (PE) called 108 authentication data (AUTH_DATA). AUTH_DATA policy element contains a 109 list of authentication attributes. Policy object containing 110 AUTH_DATA MUST be protected against replay attacks using INTEGRITY 111 object option as described in the [POL-EXT]. 113 +-------------+-------------+-------------+-------------+ 114 | Length | P-Type = AUTH_DATA | 115 +-------------+-------------+-------------+-------------+ 116 | IdentityType | 0 (Reserved) | 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 and indicates the end of the 125 authentication attribute list. 127 AUTH_DATA 128 Policy element type (P-type) for the authentication data as 129 registered with Internet Assigned Numbers Authority (IANA). 131 IdentityType 132 This field describes the authentication method being used. 133 Following types are currently defined. 135 1 AUTH_USER authentication scheme to identify users 137 2 AUTH_APP authentication scheme to identify 138 applications 140 Reserved 141 Must be set to 0. 143 Yadav, et al. 3 144 Authentication Attribute List 146 Authentication attributes contain information specific to 147 authentication methods. The policy element provides the 148 mechanism for grouping a collection of authentication 149 attributes. 151 4.3 Authentication Attributes 153 Authentication attributes must be encoded as a multiple of 4 octets, 154 attributes that are not a multiple of 4 octets long must be padded 155 to a 4-octet boundary. 157 +--------+--------+--------+--------+ 158 | Length | A-Type |SubType | 159 +--------+--------+--------+--------+ 160 | Value � 161 +--------+--------+--------+--------+ 163 Length 164 The length field is two octets and indicates the actual length 165 of the attribute (including the Length and A-Type fields) in 166 number of octets. The length does not include any bytes padding 167 the attribute to make it multiple of 4 octets long. 169 A-Type 170 Authentication attribute type (A-Type) field is one octet. The 171 following values are defined: 173 1 POLICY_LOCATOR Unique string for locating the 174 admission policy (such as X.500 DN 175 described in [RFC 1779]). 177 2 CREDENTIAL_ User credential such as Kerberos 178 ticket, or digital certificate. 179 Application credential such as 180 application ID. 182 3 DIGITAL_SIGNATURE Digital signature of the 183 authentication data policy element. 185 SubType 186 Authentication attribute sub-type field is one octet. Value of 187 SubType depends on A-type. 189 Value: 190 The value field contains 0-65351 octets. 192 Yadav, et al. 4 193 4.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 policy 197 hence a DN is used as policy locator. 199 +-------+-------+-------+-------+ 200 | Length |A-Type |SubType| 201 +-------+-------+-------+-------+ 202 | OctetString � 203 +-------+-------+-------+-------- 205 Length 206 > 4 208 A-Type 209 POLICY_LOCATOR 211 SubType 212 Following sub types for POLICY_LOCATOR are defined. 214 1 X500_DN OctetString contains the X.500 DN as described 215 in the RFC 1779 as an ASCII string. 217 2 UNICODE DN OctetString contains the X.500 DN described in 218 the RFC 1779 as an UNICODE string. 220 3 X500_DN ENCRYPT OctetString contains the encrypted X.500 DN. 221 The Kerberos session key or digital certificate 222 private key is used for encryption. For 223 Kerberos encryption the format is the same as 224 returned from gss_seal [RFC 1509]. 226 4 X500_UNICODE_DN ENCRYPT OctetString contains the encrypted 227 UNICODE X.500 DN. The Kerberos session key or 228 digital certificate private key is used for 229 encryption. For Kerberos encryption the format 230 is the same as returned from gss_seal [RFC 231 1509]. 233 OctetString 234 The OctetString field contains the DN. 236 4.3.2 Credential 238 CREDENTIAL indicates the credential of the user or application to be 239 authenticated. For Kerberos authentication method the CREDENTIAL 240 object contains the Kerberos session ticket. For public key based 241 authentication this field contains a digital certificate. 243 Yadav, et al. 5 244 A summary of the CREDENTIAL attribute format is shown below. The 245 fields are transmitted from left to right. 247 +-------+-------+-------+-------+ 248 | Length |A-Type |SubType| 249 +-------+-------+-------+-------+ 250 | OctetString � 251 +-------+-------+-------+-------- 253 Length 254 > 4 256 A-Type 257 _CREDENTIAL 259 SubType 260 Following sub types for CREDENTIAL are defined. 262 1 ASCII_ID OctetString contains user or application 263 identification in plain ASCII text. 265 2 UNICODE_ID OctetString contains user or application 266 identification in plain UNICODE text. 268 3 KERBEROS_TKT OctetString contains Kerberos ticket. 270 4 X509_V3_CERT OctetString contains X.509v3 digital 271 certificate [X.509]. 273 5 PGP_CERT OctetString contains PGP digital certificate. 275 OctetString 276 The OctetString contains the user or application credential. 278 4.3.3 Digital Signature 280 The DIGITAL_SIGNATURE attribute must be the last attribute in the 281 attribute list and contains the digital signature of the AUTH_DATA 282 policy element. The digital signature signs all data in the 283 AUTH_DATA policy element up to the DIGITAL_SIGNATURE. The algorithm 284 used to compute the digital signature depends on the authentication 285 method specified by the CREDENTIAL SubType field. 287 A summary of DIGITAL_SIGNATURE attribute format is described below. 289 +-------+-------+-------+-------+ 290 | Length |A-Type |SubType| 291 +-------+-------+-------+-------+ 292 | OctetString � 293 +-------+-------+-------+-------- 295 Yadav, et al. 6 296 Length 297 > 4 299 A-Type 300 DIGITAL_SIGNATURE 302 SubType 303 No sub types for DIGITAL_SIGNATURE are currently defined. This 304 field must be set to 0. 306 OctetString 307 OctetString contains the digital signature of the AUTH_DATA. 309 5. Authentication Data Formats 311 Authentication attributes are grouped in a policy element to 312 represent the identity credentials. 314 5.1 Simple User Authentication 316 In simple user authentication method the user login ID (in plain 317 ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary 318 of the simple user AUTH_DATA policy element is shown below. 320 +--------------+--------------+--------------+--------------+ 321 | Length | P-type = AUTH_DATA | 322 +--------------+--------------+--------------+--------------+ 323 | IdentityType = AUTH_USER | 0 | 324 +--------------+--------------+--------------+--------------+ 325 | Length |POLICY_LOCATOR| SubType | 326 +--------------+--------------+--------------+--------------+ 327 | OctetString (User�s Distinguished Name) � 328 +--------------+--------------+--------------+--------------+ 329 | Length |CREDENTIAL | SubType | 330 +--------------+--------------+--------------+--------------+ 331 | OctetString (User�s login ID) � 332 +--------------+--------------+--------------+--------------+ 334 5.2 Kerberos User Authentication 336 Kerberos [RFC 1510] authentication uses a trusted third party (the 337 Kerberos Distribution Center � KDC) to provide for authentication of 338 the user to a network server. It is assumed that a KDC is present 339 and both host and verifier of authentication information (router or 340 policy server) implement Kerberos authentication. 342 Yadav, et al. 7 343 A summary of the Kerberos AUTH_DATA policy element is shown below. 345 +--------------+--------------+--------------+--------------+ 346 | Length | P-type (AUTH_DATA) | 347 +--------------+--------------+--------------+--------------+ 348 | IdentityType = AUTH_USER | 349 +--------------+--------------+--------------+--------------+ 350 | Length |POLICY_LOCATOR| SubType | 351 +--------------+--------------+--------------+--------------+ 352 | OctetString (User�s Distinguished Name) � 353 +--------------+--------------+--------------+--------------+ 354 | Length | CREDENTIAL | KERBEROS_TKT | 355 +--------------+--------------+--------------+--------------+ 356 | OctetString (Kerberos Session Ticket) � 357 +--------------+--------------+--------------+--------------+ 359 5.2.1. Operational Setting using Kerberos Identities 361 An RSVP enabled host is configured to construct and insert AUTH_DATA 362 policy element into RSVP messages that designate use of the Kerberos 363 authentication method (KERBEROS_TKT). Upon RSVP session 364 initialization, the user application contacts the KDC to obtain a 365 Kerberos ticket for the next network node or its policy server. A 366 router when generating a RSVP message contacts the KDC to obtain a 367 Kerberos ticket for the next hop network node or its policy server. 368 The identity of the policy server or next network hop can be 369 statically configured, learned via DHCP or maintained in a directory 370 service. The Kerberos ticket is sent to the next network node (which 371 may be a router or host) in a RSVP message. The router may be a 372 policy node or may use a policy server. The KDC is used to validate 373 the ticket and authentication the user sending RSVP message. 375 Yadav, et al. 8 376 5.3 Public Key based User Authentication 378 In public key based user authentication method digital certificate 379 is encoded as user credentials. The digital signature is used for 380 authenticating the user. A summary of the public key user AUTH_DATA 381 policy element is shown below. 383 +--------------+--------------+--------------+--------------+ 384 | Length | P-type (AUTH_DATA) | 385 +--------------+--------------+--------------+--------------+ 386 | IdentityType = AUTH_USER | 0 | 387 +--------------+--------------+--------------+--------------+ 388 | Length |POLICY_LOCATOR| SubType | 389 +--------------+--------------+--------------+--------------+ 390 | OctetString (User�s Distinguished Name) � 391 +--------------+--------------+--------------+--------------+ 392 | Length | _CREDENTIAL | SubType | 393 +--------------+--------------+--------------+--------------+ 394 | OctetString (User�s Digital Certificate)� 395 +--------------+--------------+--------------+--------------+ 396 | Length |DIGITAL_SIGN. | 0 | 397 +--------------+--------------+--------------+--------------+ 398 | OctetString (Digital signature) � 399 +--------------+--------------+--------------+--------------+ 401 5.3.1. Operational Setting for public key based authentication 403 Public key based authentication assumes following: 405 - RSVP service requestors have a pair of keys (private key and 406 public key). 408 - Private key is secured with the user. 410 - Public keys are stored in digital certificates and a trusted 411 party, certificate authority (CA) issues these digital 412 certificates. 414 - The verifier (policy server or router) has the ability to 415 verify the digital certificate. 417 RSVP requestor uses its private key to generate DIGITAL_SIGNATURE. 418 User Authenticators (router, policy server) use the user�s public 419 key (stored in the digital certificate) to verify the signature and 420 authenticate the user. 422 Yadav, et al. 9 423 5.4 Simple Application Authentication 425 The application authentication method encodes the application 426 identification such as an executable filename as plain ASCII or 427 UNICODE text. 429 +--------------+--------------+--------------+------------------+ 430 | Length | P-type = AUTH_DATA | 431 +--------------+--------------+--------------+------------------+ 432 | IdentityType = AUTH_APP | 0 | 433 +--------------+--------------+--------------+------------------+ 434 | Length |POLICY_LOCATOR| SubType | 435 +--------------+--------------+--------------+------------------+ 436 | OctetString (Application Distinguished Name) � 437 +--------------+--------------+--------------+------------------+ 438 | Length | CREDENTIAL | SubType 439 +--------------+--------------+--------------+------------------+ 440 | OctetString (Application Identification) 441 +--------------+--------------+--------------+------------------+ 443 6. Operation 445 +------+ +------+ 446 |Policy|------+ |Policy| 447 |Server| | |Server| 448 +------+ | �������������.��. +------+ 449 | : : | 450 | : : | 451 +---------+ : : +-------+ 452 +----|First hop| Transit Transit -----|Transit| 453 | | Router |----Router Router | Router|--+ 454 | +---------+ : : +-------+ | 455 | | :��������������...: | | 456 | | | | 457 Host A B C D 459 Figure 1: User and Application Authentication using AUTH_DATA object 461 Hosts and network nodes generate AUTH DATA policy elements, contents 462 of which are depends on the identity type used and the 463 authentication method used. But generally contains authentication 464 credentials (Kerberos ticket or digital certificate) and policy 465 locators (which can be the X.500 Distinguished Name of the user or 466 network node or application names). Host systems generate AUTH_DATA 467 policy element containing the authentication identity when making 468 the RSVP request. 470 Network nodes generate user AUTH_DATA policy element using the 471 following rules 473 Yadav, et al. 10 474 1. For unicast sessions the user policy locator is the copied from 475 the previous hop. The authentication credentials are for the 476 current network node identity. 478 2. For multicast messages the user policy locator is for the current 479 network node identity. The authentication credentials are for the 480 current network node. 482 Network nodes generate application AUTH_DATA policy element using 483 the following rules: 485 1. 486 For unicast sessions the application AUTH_DATA is the copied from 487 the previous hop. 489 2. 490 For multicast messages the application AUTH_DATA is either the 491 first application AUTH_DATA in the message or chosen by the policy 492 server. 494 7. Message Processing Rules 496 7.1 Message Generation (RSVP Host) 498 An RSVP message is created as specified in [RFC2205] with following 499 modifications. 501 1. An authentication policy element, AUTH_DATA, is created and the 502 IdentityType field is modified to indicate the authentication 503 identity type being used. 505 - A DN is inserted as POLICY_LOCATOR attribute. 507 - Credentials such as Kerberos ticket or digital certificate 508 are inserted as the CREDENTIAL attribute. 510 2. A POLICY_DATA object is inserted in the RSVP message in 511 appropriate place with AUTH_DATA as one of the policy elements. 512 If INTEGRITY object is not computed for the RSVP message then an 513 INTEGRITY object MUST be computed for this POLICY_DATA object, as 514 described in the [POL_EXT], and MUST be inserted as an option. 516 7.2 Message Reception (Router/Subnet Bandwidth Manager (SBM)) 518 RSVP message is processed as specified in [RFC2205] with following 519 modifications. 521 1. If router/SBM is not policy aware then it SHOULD send the RSVP 522 message to the policy server and wait for response. 524 2. Reject the message if the response from the policy server is 525 negative. 527 Yadav, et al. 11 528 3. Continue processing the RSVP message. 530 7.3 Authentication (Router/SBM/Policy server) 532 1. Retrieve the AUTH_DATA policy element. 534 2. Check the IdentityType field and return an error if the identity 535 type is not supported. 537 3. Verify credential 539 - Simple authentication: e.g. Get user ID and validate it, or 540 get executable name and validate it. 542 - Kerberos: Send the Kerberos ticket to the KDC to obtain the 543 session key. Using the session key authenticate the user. 545 - Public Key: Validate the certificate that it was issued by a 546 trusted Certificate Authority (CA) and authenticate the user 547 or application by verifying the digital signature. 549 8. Security Considerations 551 The purpose of this draft is to describe a mechanism to authenticate 552 RSVP requests based on user identity in a secure manner. RSVP 553 INTEGRITY object [MD5] is used to protect the policy object 554 containing user identity information from security (replay) attacks. 555 Combining the AUTH_DATA policy element and the INTEGRITY object 556 results in a secure access control that enforces authentication 557 based on both the identity of the user and the identity of the 558 originating node. 560 Simple authentication does not contain credential that can be 561 securely authenticated and is inherently less secured. 563 The Kerberos authentication mechanism is reasonably well secured. 565 User authentication using a public key certificate is known to 566 provide the strongest security. 568 9. Error Signaling 570 If Policy server fails to verify the AUTH_DATA policy element then 571 it must indicate to the first hop router the Error Code = 02 (Policy 572 control failure). The policy server may specify error value field. 573 These typically include: 575 - Authentication method not supported 577 Yadav, et al. 12 578 - Authentication failure 580 - Required attribute (specify) missing. For example CREDENTIAL 581 attribute missing. 583 - Unknown attribute (specify) type. 585 - Unknown attribute (specify) sub type. 587 10. Appendix A 589 Internet-Draft �RSVP Cryptography Authentication� [MD5] describes a 590 mechanism to authenticate RSVP messages based on the interface of a 591 node on which the RSVP messages are sent. A single key is used to 592 authenticate RSVP requests made by all users for an interface of the 593 node. The security of such a setup has following limitations: 595 - Authentication and RSVP admission control on the basis of 596 node credentials alone is less secure as a node can 597 impersonate all of its users even when they are not logged 598 in. 600 - It is not possible to identify the user making the RSVP 601 request. 603 Mechanism described in this draft can be used to solve the key 604 distribution problem between hosts and routers for implementing 605 [MD5]. We call this key the integrity key and if a network node is 606 using authentication information, it may obtain this integrity key 607 from a key distribution center by using the authentication 608 information. A network node can verify the Integrity object of the 609 RSVP message by using the authentication credentials to obtain the 610 key from a key distribution center. The integrity key is used to 611 compute the messages digest in the INTEGRITY object. The next hop 612 router may either be a policy node; a policy server client or it may 613 obtain the integrity key from a key distribution center using the 614 authentication credentials from the first AUTH_DATA policy element. 615 The key management APIs described in [MD5] needs to use the whole 616 message to obtain the necessary information to obtain the key for 617 integrity verification from a key distribution center. 618 The key to generate integrity object for PATH and RESV tear should 619 use the same key that was used to generate integrity objects for the 620 PATH or RESV message. 622 Using the identity policy elements to find the integrity key does 623 not work for the last hop for multicast RSVP. This requires 624 authenticated multicast joins to allow the control of who can send 625 RSVP messages for a multicast group. The certificate authority can 626 issue secret keys for use between the requestor and the verifier. 627 This secret key is used for the integrity key. 629 Yadav, et al. 13 630 If the policy server or another key server supplies an integrity key 631 then check the integrity object. The router or host for later use 632 (e.g., on refreshes) may cache this key. If a policy server obtains 633 the integrity key on behalf of the router it can send the key using 634 cops [COPS-RSVP]. 636 11. Acknowledgments 638 We would like to thank Raj Yavatkar, Bob Linden and many others for 639 their valuable comments on this draft. 641 12. References 643 [ASCII] Coded Character Set -- 7-Bit American Standard Code for 644 Information Interchange, ANSI X3.4-1986. 646 [MD5] Baker, F., et.al. "RSVP Cryptographic Authentication." 647 Internet-Draft, draft-ietf-rsvp-md5-07.txt, November 648 1998. 650 [POL-EXT] Herzog, S., "RSVP Extensions for Policy Control." 651 Internet-Draft, draft-ietf-rap-policy-ext-00.txt, April 652 1998 654 [RFC 1510] The Kerberos Network Authentication Service (V5). Kohl 655 J., Neuman, C. RFC 1510. 657 [RFC 1704] On Internet Authentication. Haller, N, Atkinson, R., 658 RFC 1704. 660 [RFC 1779] A String Representation of Distinguished Names. S. 661 Kille. RFC 1779 663 [RFC 2205] Braden, R., et. al., "Resource ReSerVation Protocol 664 (RSVP) � Version 1 Functional Specification." RFC 2205. 666 [RFC 2209] Braden, R., Zhang, L., "Resource ReSerVation Protocol 667 (RSVP) - Version 1 Message Processing Rules." RFC 2209. 669 [UNICODE] The Unicode Consortium, "The Unicode Standard, Version 670 2.0", Addison-Wesley, Reading, MA, 1996. 672 [X.509] ITU-T (formerly CCITT) Information technology � Open 673 Systems Interconnection � The Directory: Authentication 674 Framework Recommendation X.509 ISO/IEC 9594-8 676 Yadav, et al. 14 677 13. Author Information 679 Satyendra Yadav 680 Intel, JF3-206 681 2111 NE 25th Avenue 682 Hillsboro, OR 97124 683 Satyendra.Yadav@intel.com 685 Ramesh Pabbati 686 Microsoft 687 1 Microsoft Way 688 Redmond, WA 98054 689 rameshpa@microsoft.com 691 Tim Moore 692 Microsoft 693 1 Microsoft Way 694 Redmond, WA 98054 695 timmoore@microsoft.com 697 Shai Herzog 698 IPHighway 699 2055 Gateway Pl., Suite 400 700 San Jose, CA 95110 701 herzog@iphighway.com 703 Yadav, et al. 15