idnits 2.17.1 draft-ietf-rap-rsvp-authsession-03.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 expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1177 has weird spacing: '... to pertain...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7986 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 106, but not defined == Missing Reference: 'FRC-1321' is mentioned on line 640, but not defined == Missing Reference: 'RFC 1510' is mentioned on line 654, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) == Unused Reference: 'ASCII' is defined on line 1026, but no explicit reference was found in the text == Unused Reference: 'RFC-2753' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'RFC-1034' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: 'RFC-1305' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'RFC-1321' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'RFC-1510' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'RFC-2253' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC-2209' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'RFC-2327' is defined on line 1069, but no explicit reference was found in the text == Unused Reference: 'RFC-2396' is defined on line 1073, but no explicit reference was found in the text == Unused Reference: 'RFC-2474' is defined on line 1078, but no explicit reference was found in the text == Unused Reference: 'UNICODE' is defined on line 1083, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-rap-session-auth (ref. 'S-AUTH') -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Downref: Normative reference to an Informational RFC: RFC 2753 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) ** Downref: Normative reference to an Informational RFC: RFC 2209 ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'UNICODE' -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 14 errors (**), 0 flaws (~~), 18 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RAP Working Group L-N. Hamer 2 Internet Draft B. Gage 3 M. Broda 4 Document: draft-ietf-rap-rsvp-authsession-03.txt Nortel Networks 5 B. Kosinski 6 University of Alberta 7 Hugh Shieh 8 AT&T Wireless 9 June 2002 11 Session Authorization for RSVP 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet- Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 The distribution of this memo is unlimited. This memo is filed as 32 , and expires November, 33 2002. Please send comments to the authors. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 This document describes the representation of session authorization 42 information in the POLICY_DATA object (RFC 2750) for supporting 43 policy-based per-session authorization and admission control in 44 RSVP. The goal of session authorization is to allow the exchange of 45 information between network elements in order to authorize the use 46 of resources for a service and to co-ordinate actions between the 47 signaling and transport planes. This document describes how a 48 process on a system authorizes the reservation of resources by a 49 host and then provides that host with a session authorization policy 50 element which can be inserted into the RSVP PATH message to 51 facilitate proper and secure reservation of those resources within 52 the network. We describe the encoding of media authorization 53 information as RSVP policy elements and provide details relating to 54 operations, processing rules and error scenarios. 56 Contents 58 Status of this Memo................................................1 59 Copyright Notice...................................................1 60 Abstract...........................................................1 61 1. Conventions used in this document...............................3 62 2. Introduction....................................................3 63 3. Policy Element for Session Authorization Data...................4 64 3.1 Policy Data Object Format......................................4 65 3.2 Session Authorization Data Policy Element......................4 66 3.3 Session Authorization Attributes...............................4 67 3.3.1 Authorizing Entity Identifier................................6 68 3.3.2 Session Identifier...........................................7 69 3.3.3 Source Address...............................................7 70 3.3.4 Destination Address..........................................9 71 3.3.5 Start time..................................................10 72 3.3.6 End time....................................................11 73 3.3.7 Resources Authorized........................................11 74 3.3.8 Authentication data.........................................12 75 4. Integrity of the AUTH_SESSION policy element...................13 76 4.1 Shared private keys...........................................13 77 4.1.1 Operational Setting using shared private keys...............13 78 4.2 Kerberos......................................................14 79 4.2.1. Operational Setting using Kerberos.........................14 80 4.3 Public Key....................................................15 81 4.3.1. Operational Setting for public key based authentication....15 82 5. Framework......................................................16 83 5.1 The coupled model.............................................16 84 5.2 The associated model with one policy server...................16 85 5.3 The associated model with two policy servers..................17 86 5.4 The non-associated model......................................17 87 6. Message Processing Rules.......................................17 88 6.1 Message Generation (RSVP Host)................................17 89 6.2 Message Reception (Router)....................................18 90 6.3 Authorization (Router/PDP)....................................18 91 7. Error Signaling................................................18 92 8. IANA Considerations............................................19 93 9. Security Considerations........................................20 94 10. Acknowledgments...............................................21 95 11. Normative References..........................................21 96 12. Informative References........................................23 97 13. Author Information............................................23 98 14. Full Copyright Statement......................................24 99 15. Notices.......................................................24 100 16. RFC Editor Considerations.....................................25 101 1. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 105 this document are to be interpreted as described in [RFC-2119]. 107 2. Introduction 109 RSVP [RFC-2205] is a resource reservation setup protocol designed 110 for an integrated services [RFC-1633] or Integrated Services over 111 Diffserv networks [RFC-2998]. The RSVP protocol is used by a host to 112 request specific services from the network for particular 113 application data streams or flows. RSVP is also used to deliver 114 quality-of-service (QoS) requests to all routers along the path(s) 115 of the flows and to establish and maintain state to provide the 116 requested quality of service. RSVP requests will generally result 117 in resources being reserved in each router along the data path. 118 RSVP allows users to obtain preferential access to network 119 resources, under the control of an admission control mechanism. 120 Such admission control is often based on user or application 121 identity [RFC-3182], however, it is also valuable to provide the 122 ability for per-session admission control. 124 In order to allow for per-session admission control, it is necessary 125 to provide a mechanism for ensuring use of resources by a host has 126 been properly authorized before allowing the reservation of those 127 resources. In order to meet this requirement, there must be 128 information in the RSVP message which may be used to verify the 129 validity of the RSVP request. This can be done by providing the 130 host with a token upon authorization which is inserted into the RSVP 131 PATH message and verified by the network. 133 This document describes the session authorization element 134 (AUTH_SESSION) contained in the POLICY_DATA object. The user 135 process must obtain an AUTH_SESSION object from an authorizing 136 entity, which it then passes to the RSVP process (service) on the 137 originating host. The RSVP service then inserts the AUTH_SESSION 138 object into the RSVP PATH message to allow verification of the 139 network resource request. Network elements verify the request and 140 then process the RSVP message based on admission policy. 142 [S-AUTH] describes a framework in which a session authorization 143 policy element may be utilized to contain information relevant to 144 the network's decision to grant a reservation request. 146 3. Policy Element for Session Authorization Data 148 3.1 Policy Data Object Format 150 POLICY_DATA objects contain policy information and are carried by 151 RSVP messages. A detailed description of the format of POLICY_DATA 152 object can be found in "RSVP Extensions for Policy Control" [RFC- 153 2750]. 155 3.2 Session Authorization Data Policy Element 157 In this section we describe a policy element (PE) called session 158 authorization data (AUTH_SESSION). The AUTH_SESSION policy element 159 contains a list of fields which describe the session, along with 160 other attributes. 162 +-------------+-------------+-------------+-------------+ 163 | Length | P-Type = AUTH_SESSION | 164 +-------------+-------------+-------------+-------------+ 165 // Session Authorization Attribute List // 166 +-------------------------------------------------------+ 168 Length: 16 bits 169 The length of the policy element (including the Length and 170 P-Type) is in number of octets (MUST be in multiples of 4) and 171 indicates the end of the session authorization information block. 173 P-Type: 16 bits (Session Authorization Type) 174 AUTH_SESSION = TBD-by-IANA 175 The Policy element type (P-type) of this element. The 176 Internet Assigned Numbers Authority (IANA) acts as a registry 177 for policy element types for identity as described in 178 [RFC-2750]. 180 Session Authorization Attribute List: variable length 181 The session authorization attribute list is a collection of 182 objects which describes the session and provides other 183 information necessary to verify the RSVP request. An initial set 184 of valid objects is described in Section 3. 186 3.3 Session Authorization Attributes 188 A session authorization attribute may contain a variety of 189 information and has both an attribute type and subtype. The 190 attribute itself MUST be a multiple of 4 octets in length, and any 191 attributes that are not a multiple of 4 octets long MUST be padded 192 to a 4-octet boundary. All padding bytes MUST have a value of zero. 194 +--------+--------+--------+--------+ 195 | Length | S-Type |SubType | 196 +--------+--------+--------+--------+ 197 | Value ... 198 +--------+--------+--------+--------+ 200 Length: 16 bits 201 The length field is two octets and indicates the actual length 202 of the attribute (including Length, S-Type and SubType fields) 203 in number of octets. The length does NOT include any bytes 204 padding to the value field to make the attribute a multiple of 205 4 octets long. 207 S-Type: 8 bits 208 Session authorization attribute type (S-Type) field is one 209 octet. IANA acts as a registry for S-Types as described 210 in section 7, IANA Considerations. Initially, the registry 211 contains the following S-Types: 213 1 AUTH_ENT_ID The unique identifier of the entity 214 which authorized the session. 216 2 SESSION_ID Unique identifier for this session. 218 3 SOURCE_ADDR Address specification for the 219 session originator. 221 4 DEST_ADDR Address specification for the 222 session end-point. 224 5 START_TIME The starting time for the session. 226 6 END_TIME The end time for the session. 228 7 RESOURCES The resources which the user is 229 authorized to request. 231 8 AUTHENTICATION_DATA Authentication data of the session 232 authorization policy element. 234 SubType: 8 bits 235 Session authorization attribute sub-type is one octet in 236 length. The value of the SubType depends on the S-Type. 238 Value: variable length 239 The attribute specific information. 241 3.3.1 Authorizing Entity Identifier 243 AUTH_ENT_ID is used to identify the entity which authorized the 244 initial service request and generated the session authorization 245 policy element. The AUTH_ENT_ID may be represented in various 246 formats, and the SubType is used to define the format for the ID. 247 The format for AUTH_ENT_ID is as follows: 249 +-------+-------+-------+-------+ 250 | Length |S-Type |SubType| 251 +-------+-------+-------+-------+ 252 | OctetString ... 253 +-------+-------+-------+-------+ 255 Length 256 Length of the attribute, which MUST be > 4. 258 S-Type 259 AUTH_ENT_ID 261 SubType 262 The following sub-types for AUTH_ENT_ID are defined. IANA 263 acts as a registry for AUTH_ENT_ID sub-types as described 264 in section 7, IANA Considerations. Initially, the registry 265 contains the following sub-types of AUTH_ENT_ID: 267 1 IPV4_ADDRESS IPv4 address represented in 32 bits 269 2 IPV6_ADDRESS IPv6 address represented in 128 bits 271 3 FQDN Fully Qualified Domain Name as defined 272 in RFC-1034 as an ASCII string. 274 4 ASCII_DN X.500 Distinguished name as defined 275 in RFC-2253 as an ASCII string. 277 5 UNICODE_DN X.500 Distinguished name as defined 278 in RFC-2253 as a UNICODE string. 280 6 URI Universal Resource Identifier, as 281 defined in RFC-2396. 283 7 KRB_PRINCIPAL Fully Qualified Kerberos Principal name 284 represented by the ASCII string of a 285 principal followed by the @ realm name as 286 defined in RFC-1510 (e.g. 287 principalX@realmY). 289 8 X509_V3_CERT A chain of authorizing entity's X.509 V3 290 digital certificates. 292 9 PGP_CERT The PGP digital certificate of the 293 authorizing entity. 295 OctetString 296 Contains the authorizing entity identifier. 298 3.3.2 Session Identifier 300 SESSION_ID is a unique identifier used by the authorizing entity to 301 identify the request. It may be used for a number of purposes, 302 including replay detection, or to correlate this request to a policy 303 decision entry made by the authorizing entity. For example, the 304 SESSION_ID can be based on simple sequence number or on a standard 305 NTP timestamp. 307 +-------+-------+-------+-------+ 308 | Length |S-Type |SubType| 309 +-------+-------+-------+-------+ 310 | OctetString ... 311 +-------+-------+-------+-------+ 313 Length 314 Length of the attribute, which MUST be > 4. 316 S-Type 317 SESSION_ID 319 SubType 320 No subtypes for SESSION ID are currently defined; this field MUST 321 be set to zero. The authorizing entity is the only network entity 322 that needs to interpret the contents of the SESSION ID therefore the 323 contents and format are implementation dependent. 325 OctetString 326 Contains the session identifier. 328 3.3.3 Source Address 330 SOURCE_ADDR is used to identify the source address specification of 331 the authorized session. This S-Type may be useful in some scenarios 332 to make sure the resource request has been authorized for that 333 particular source address and/or port. 335 +-------+-------+-------+-------+ 336 | Length |S-Type |SubType| 337 +-------+-------+-------+-------+ 338 | OctetString ... 339 +-------+-------+-------+-------+ 340 Length 341 Length of the attribute, which MUST be > 4. 343 S-Type 344 SOURCE_ADDR 346 SubType 347 The following sub types for SOURCE_ADDR are defined. IANA 348 acts as a registry for SOURCE_ADDR sub-types as 349 described in section 7, IANA Considerations. Initially, the 350 registry contains the following sub types for SOURCE_ADDR: 352 1 IPV4_ADDRESS IPv4 address represented in 32 bits 354 2 IPV6_ADDRESS IPv6 address represented in 128 bits 356 3 FQDN Fully Qualified Domain Name as defined 357 in RFC-1034 as an ASCII string. 359 4 ASCII_DN X.500 Distinguished name as defined 360 in RFC-2253 as an ASCII string. 362 5 UNICODE_DN X.500 Distinguished name as defined 363 in RFC-2253 as a UNICODE string. 365 6 UDP_PORT LIST list of UDP port specifications, 366 represented as 16 bits per list entry. 368 7 TCP_PORT LIST list of TCP port specifications, 369 represented as 16 bits per list entry. 371 OctetString 372 The OctetString contains the source address information. 374 In scenarios where a source address is required (see Section 5), at 375 least one of the subtypes 1 through 5 (inclusive) MUST be included 376 in every Session Authorization Data Policy Element. Multiple SOURCE 377 ADDR attributes MAY be included if multiple addresses have been 378 authorized. The source address field of the RSVP datagram MUST match 379 one of the SOURCE ADDR attributes contained in this Session 380 Authorization Data Policy Element when resolved to an IP address. 382 At most, one instance of subtype 6 MAY be included in every Session 383 Authorization Data Policy Element. At most, one instance of subtype 384 7 MAY be included in every Session Authorization Data Policy 385 Element. Inclusion of a subtype 6 attribute does not prevent 386 inclusion of a subtype 7 attribute (i.e. both UDP and TCP ports may 387 be authorized). 389 If no PORT attributes are specified, then all ports are considered 390 valid; otherwise, only the specified ports are authorized for use. 392 Every source address and port list must be included in a separate 393 SOURCE_ADDR attribute. 395 3.3.4 Destination Address 397 DEST_ADDR is used to identify the destination address of the 398 authorized session. This S-Type may be useful in some scenarios to 399 make sure the resource request has been authorized for that 400 particular destination address and/or port. 402 +-------+-------+-------+-------+ 403 | Length |S-Type |SubType| 404 +-------+-------+-------+-------+ 405 | OctetString ... 406 +-------+-------+-------+-------+ 408 Length 409 Length of the attribute, which MUST be > 4. 411 S-Type 412 DEST_ADDR 414 SubType 415 The following sub types for DEST_ADDR are defined. IANA 416 acts as a registry for DEST_ADDR sub-types as described in 417 section 7, IANA Considerations. Initially, the registry 418 contains the following sub types for DEST_ADDR: 420 1 IPV4_ADDRESS IPv4 address represented in 32 bits 422 2 IPV6_ADDRESS IPv6 address represented in 128 bits 424 3 FQDN Fully Qualified Domain Name as defined 425 in RFC-1034 as an ASCII string. 427 4 ASCII_DN X.500 Distinguished name as defined 428 in RFC-2253 as an ASCII string. 430 5 UNICODE_DN X.500 Distinguished name as defined 431 in RFC-2253 as a UNICODE string. 433 6 UDP_PORT LIST list of UDP port specifications, 434 represented as 16 bits per list entry. 436 7 TCP_PORT LIST list of TCP port specifications, 437 represented as 16 bits per list entry. 439 OctetString 440 The OctetString contains the destination address specification. 442 In scenarios where a destination address is required (see Section 443 5), at least one of the subtypes 1 through 5 (inclusive) MUST be 444 included in every Session Authorization Data Policy Element. 445 Multiple DEST ADDR attributes MAY be included if multiple addresses 446 have been authorized. The destination address field of the RSVP 447 datagram MUST match one of the DEST ADDR attributes contained in 448 this Session Authorization Data Policy Element when resolved to an 449 IP address. 451 At most, one instance of subtype 6 MAY be included in every Session 452 Authorization Data Policy Element. At most, one instance of subtype 453 7 MAY be included in every Session Authorization Data Policy 454 Element. Inclusion of a subtype 6 attribute does not prevent 455 inclusion of a subtype 7 attribute (i.e. both UDP and TCP ports may 456 be authorized). 458 If no PORT attributes are specified, then all ports are considered 459 valid; otherwise, only the specified ports are authorized for use. 461 Every destination address and port list must be included in a 462 separate DEST_ADDR attribute. 464 3.3.5 Start time 466 START_TIME is used to identify the start time of the authorized 467 Session and can be used to prevent replay attacks. If the 468 AUTH_SESSION policy element is presented in a resource request, the 469 network SHOULD reject the request if it is not received within a few 470 seconds of the start time specified. 472 +-------+-------+-------+-------+ 473 | Length |S-Type |SubType| 474 +-------+-------+-------+-------+ 475 | OctetString ... 476 +-------+-------+-------+-------+ 478 Length 479 Length of the attribute, which MUST be > 4. 481 S-Type 482 START_TIME 484 SubType 485 The following sub types for START_TIME are defined. IANA 486 acts as a registry for START_TIME sub-types as described in 487 section 7, IANA Considerations. Initially, the registry 488 contains the following sub types for START_TIME: 489 1 NTP_TIMESTAMP NTP Timestamp Format as defined in 490 RFC-1305. 492 OctetString 493 The OctetString contains the start time. 495 3.3.6 End time 497 END_TIME is used to identify the end time of the authorized 498 session and can be used to limit the amount of time that resources 499 are authorized for use (e.g. in prepaid session scenarios). 501 +-------+-------+-------+-------+ 502 | Length |S-Type |SubType| 503 +-------+-------+-------+-------+ 504 | OctetString ... 505 +-------+-------+-------+-------+ 507 Length 508 Length of the attribute, which MUST be > 4. 510 S-Type 511 END_TIME 513 SubType 514 The following sub types for END_TIME are defined. IANA 515 acts as a registry for END_TIME sub-types as described in 516 section 7, IANA Considerations. Initially, the registry 517 contains the following sub types for END_TIME: 519 1 NTP_TIMESTAMP NTP Timestamp Format as defined in 520 RFC-1305. 522 OctetString 523 The OctetString contains the end time. 525 3.3.7 Resources Authorized 527 RESOURCES is used to define the characteristics of the authorized 528 session. This S-Type may be useful in some scenarios to specify the 529 specific resources authorized to ensure the request fits the 530 authorized specifications. 532 +-------+-------+-------+-------+ 533 | Length |S-Type |SubType| 534 +-------+-------+-------+-------+ 535 | OctetString ... 536 +-------+-------+-------+-------+ 538 Length 539 Length of the attribute, which MUST be > 4. 541 S-Type 542 RESOURCES 544 SubType 545 The following sub-types for RESOURCES are defined. IANA 546 acts as a registry for RESOURCES sub-types as described in 547 section 7, IANA Considerations. Initially, the registry 548 contains the following sub types for RESOURCES: 550 1 BANDWIDTH Maximum bandwidth (kbps) authorized. 552 2 FLOW_SPEC Flow spec specification as defined in 553 RFC-2205. 555 3 SDP SDP Media Descriptor as defined in 556 RFC-2327. 558 4 DSCP Differentiated services codepoint as 559 defined in RFC-2474. 561 OctetString 562 The OctetString contains the resources specification. 564 In scenarios where a resource specification is required (see Section 565 5), at least one of the subtypes 1 through 4 (inclusive) MUST be 566 included in every Session Authorization Data Policy Element. 567 Multiple RESOURCE attributes MAY be included if multiple types of 568 resources have been authorized (e.g. DSCP and BANDWIDTH). 570 3.3.8 Authentication data 572 The AUTHENTICATION_DATA attribute contains the authentication data 573 of the AUTH_SESSION policy element and signs all the data in the 574 policy element up to the AUTHENTICATION_DATA. If the 575 AUTHENTICATION_DATA attribute has been included in the AUTH_SESSION 576 policy element, it MUST be the last attribute in the list. The 577 algorithm used to compute the authentication data depends on the 578 AUTH_ENT_ID SubType field. See Section 4 entitled Integrity of the 579 AUTH_SESSION policy element. 581 A summary of AUTHENTICATION_DATA attribute format is described 582 below. 584 +-------+-------+-------+-------+ 585 | Length |S-Type |SubType| 586 +-------+-------+-------+-------+ 587 | OctetString ... 588 +-------+-------+-------+-------+ 590 Length 591 Length of the attribute, which MUST be > 4. 593 S-Type 594 AUTHENTICATION_DATA 596 SubType 597 No sub types for AUTHENTICATION_DATA are currently defined. This 598 field MUST be set to 0. 600 OctetString 601 OctetString contains the authentication data of the AUTH_SESSION. 603 4. Integrity of the AUTH_SESSION policy element 605 This section describes how to ensure the integrity of the policy 606 element is preserved. 608 4.1 Shared private keys 610 In shared private key environments, the AUTH_ENT_ID MUST be of 611 subtypes: IPV4_ADDR, IPV6_ADDR, FQDN, ASCII_DN, UNICODE_DN or URI. 612 An example AUTH_SESSION policy element is shown below. 614 +--------------+--------------+--------------+--------------+ 615 | Length | P-type = AUTH_SESSION | 616 +--------------+--------------+--------------+--------------+ 617 | Length |SESSION_ID | zero | 618 +--------------+--------------+--------------+--------------+ 619 | OctetString (The session identifier) ... 620 +--------------+--------------+--------------+--------------+ 621 | Length |AUTH DATA. | zero | 622 +--------------+--------------+--------------+--------------+ 623 | OctetString (Authentication data) ... 624 +--------------+--------------+--------------+--------------+ 626 4.1.1 Operational Setting using shared private keys 628 This assumes both the Authorizing Entity and the Network router/PDP 629 are provisioned with shared private keys and with policies detailing 630 which algorithm to be used for computing the authentication data. 632 Key maintenance is outside the scope of this document, but 633 AUTH_SESSION implementations MUST at least provide the ability to 634 manually configure keys and their parameters locally. The key used 635 to produce the authentication data is identified by the AUTH_ENT_ID 636 field. Each key must also be configured with lifetime parameters for 637 the time period within which it is valid as well as an associated 638 cryptographic algorithm parameter specifying the algorithm to be 639 used with the key. At a minimum, all AUTH_SESSION implementations 640 MUST support the HMAC-MD5-96 [RFC-2104][FRC-1321] cryptographic 641 algorithm for computing the authentication data. 643 It is good practice to regularly change keys. Keys MUST be 644 configurable such that their lifetimes overlap allowing smooth 645 transitions between keys. At the midpoint of the lifetime overlap 646 between two keys, senders should transition from using the current 647 key to the next/longer-lived key. Meanwhile, receivers simply accept 648 any identified key received within its configured lifetime and 649 reject those that are not. 651 4.2 Kerberos 653 In a Kerberos environment, the AUTH_ENT_ID MUST be of the subtype 654 KRB_PRINCIPAL. Kerberos [RFC 1510] authentication uses a trusted 655 third party (the Kerberos Distribution Center - KDC) to provide for 656 authentication of the AUTH_SESSION to a network server. It is 657 assumed that a KDC is present and both host and verifier of 658 authentication information (authorizing entity and router/PDP) 659 implement Kerberos authentication. 661 An example of the Kerberos AUTH_DATA policy element is shown below. 663 +--------------+--------------+--------------+--------------+ 664 | Length | P-type = AUTH_SESSION | 665 +--------------+--------------+--------------+--------------+ 666 | Length |SESSION_ID | zero | 667 +--------------+--------------+--------------+--------------+ 668 | OctetString (The session identifier) ... 669 +--------------+--------------+--------------+--------------+ 670 | Length | AUTH_ENT_ID | KERB_P. | 671 +--------------+--------------+--------------+--------------+ 672 | OctetString (The principal@realm name) ... 673 +--------------+--------------+--------------+--------------+ 675 4.2.1. Operational Setting using Kerberos 677 An authorizing entity is configured to construct the AUTH_SESSION 678 policy element that designates use of the Kerberos authentication 679 method (KRB_PRINCIPAL). Upon reception of the RSVP request, the 680 router/PDP contacts the local KDC to request a ticket for the 681 authorizing entity (principal@realm). The router/PDP uses the ticket 682 to access the authorizing entity and obtain authentication data for 683 the message. 685 For cases where the authorizing entity is in a different realm (i.e. 686 administrative domain, organizational boundary), the router/PDP 687 needs to fetch a cross-realm Ticket Granting Ticket (TGT) from its 688 local KDC. This TGT can be used to fetch authorizing entity tickets 689 from the KDC in the remote realm. Note that for performance 690 considerations, tickets are typically cached for extended periods. 692 4.3 Public Key 694 In a public key environment, the AUTH_ENT_ID MUST be of the 695 subtypes: X509_V3_CERT or PGP_CERT. The authentication data is used 696 for authenticating the authorizing entity. An example of the public 697 key AUTH_SESSION policy element is shown below. 699 +--------------+--------------+--------------+--------------+ 700 | Length | P-type = AUTH_SESSION | 701 +--------------+--------------+--------------+--------------+ 702 | Length |SESSION_ID | zero | 703 +--------------+--------------+--------------+--------------+ 704 | OctetString (The session identifier) ... 705 +--------------+--------------+--------------+--------------+ 706 | Length | AUTH_ENT_ID | PGP_CERT | 707 +--------------+--------------+--------------+--------------+ 708 | OctetString (Authorizing entity Digital Certificate) ... 709 +--------------+--------------+--------------+--------------+ 710 | Length |AUTH DATA. | zero | 711 +--------------+--------------+--------------+--------------+ 712 | OctetString (Authentication data) ... 713 +--------------+--------------+--------------+--------------+ 715 4.3.1. Operational Setting for public key based authentication 717 Public key based authentication assumes following: 719 - Authorizing entities have a pair of keys (private key and 720 public key). 722 - Private key is secured with the authorizing entity. 724 - Public keys are stored in digital certificates and a 725 trusted party, certificate authority (CA) issues these 726 digital certificates. 728 - The verifier (PDP or router) has the ability to verify the 729 digital certificate. 731 Authorizing entity uses its private key to generate 732 AUTHENTICATION_DATA. Authenticators (router, PDP) use the 733 authorizing entity's public key (stored in the digital certificate) 734 to verify and authenticate the policy element. 736 5. Framework 738 [S-AUTH] describes a framework in which the AUTH_SESSION 739 policy element may be utilized to transport information required for 740 authorizing resource reservation for media flows. [S-AUTH] 741 introduces 4 different models: 742 1- the coupled model 743 2- the associated model with one policy server 744 3- the associated model with two policy servers 745 4- the non-associated model. 747 The fields that are required in an AUTH SESSION policy element is 748 dependent on which of the models is used. 750 5.1 The coupled model 752 In the Coupled Model, the only information that MUST be included in 753 the policy element is the SESSION ID; it is used by the Authorizing 754 Entity to correlate the resource reservation request with the media 755 authorized during session set up. Since the End Host is assumed to 756 be untrusted, the Policy Server SHOULD take measures to ensure that 757 the integrity of the SESSION ID is preserved in transit; the exact 758 mechanisms to be used and the format of the SESSION ID are 759 implementation dependent. 761 5.2 The associated model with one policy server 763 In this model, the contents of the AUTH_SESSION policy element MUST 764 include: 766 - A session identifier - SESSION_ID. This is information that the 767 authorizing entity can use to correlate the resource reservation 768 request with the media authorized during session set up. 770 - The identity of the authorizing entity _ AUTH_ENT_ID. This 771 information is used by the Edge Router to determine which 772 authorizing entity (Policy Server) should be used to solicit 773 resource policy decisions. 775 In some environments, an Edge Router may have no means for 776 determining if the identity refers to a legitimate Policy Server 777 within its domain. In order to protect against redirection of 778 authorization requests to a bogus authorizing entity, the 779 AUTH_SESSION MUST also include: 781 - AUTHENTICATION_DATA. This authentication data is calculated over 782 all other fields of the AUTH_SESSION policy element. 784 5.3 The associated model with two policy servers 786 The content of the AUTH_SESSION Policy Element is identical to the 787 associated model with one policy server. 789 5.4 The non-associated model 791 In this model, the AUTH_SESSION MUST contain sufficient information 792 to allow the Policy Server to make resource policy decisions 793 autonomously from the authorizing entity. The policy element is 794 created using information about the session by the authorizing 795 entity. The information in the AUTH_SESSION policy element MUST 796 include: 798 - Calling party IP address or Identity (e.g. FQDN) - SOURCE_ADDR S- 799 TYPE 800 - Called party IP address or Identity (e.g. FQDN) - DEST_ADDR S- 801 TYPE 802 - The characteristics of (each of) the media stream(s) authorized 803 for this session - RESOURCES S-TYPE 804 - The authorization lifetime - START_TIME S-TYPE 805 - The identity of the authorizing entity to allow for validation of 806 the token in shared private key and Kerberos schemes - 807 AUTH_ENT_ID S-TYPE 808 - The credentials of the authorizing entity in a public-key scheme 809 - AUTH_ENT_ID S-TYPE 810 - Authentication data used to prevent tampering with the 811 AUTH_SESSION policy element - AUTHENTICATION_DATA 813 Furthermore, the AUTH_SESSION policy element MAY contain: 815 - The lifetime of (each of) the media stream(s) - END_TIME S-TYPE 816 - Calling party port number - SOURCE_ADDR S-TYPE 817 - Called party port number - DEST_ADDR S-TYPE 819 All AUTH_SESSION fields MUST match with the resource request. If a 820 field does not match, the request SHOULD be denied. 822 6. Message Processing Rules 824 6.1 Message Generation (RSVP Host) 826 An RSVP message is created as specified in [RFC-2205] with following 827 modifications. 829 1. RSVP message MUST contain at most one AUTH_SESSION policy 830 element. 832 2. A Session Authorization policy element (AUTH_SESSION) is created 833 and the IdentityType field is set to indicate the identity type 834 in the policy element. Only the required Session Authorization 835 attributes are added. 837 3. POLICY_DATA object (containing the AUTH_SESSION policy element) 838 is inserted in the RSVP message in the appropriate place. 840 6.2 Message Reception (Router) 842 RSVP message is processed as specified in [RFC-2205] with following 843 modifications. 845 1. If router is policy aware then it SHOULD send the RSVP 846 message to the PDP and wait for response. If the router is 847 policy unaware then it ignores the policy data objects and 848 continues processing the RSVP message. 850 2. Reject the message if the response from the PDP is negative. 852 3. Continue processing the RSVP message. 854 6.3 Authorization (Router/PDP) 856 1. Retrieve the AUTH_SESSION policy element. Check the PE type 857 field and return an error if the identity type is not supported. 859 2. Verify the message integrity. 861 - Shared private key authentication: Get authorizing entity ID, 862 identify appropriate algorithm and shared private key for the 863 authorizing entity, and validate signature. 865 - Public Key: Validate the certificate chain against 866 trusted Certificate Authority (CA) and validate the 867 message signature using the public key. 869 - Kerberos Ticket: If the AUTH_ENT_ID is of subtype KRB_PRINCIPAL, 870 Request a ticket for the authorizing entity (principal@realm) 871 from the local KDC. Use the ticket to access the authorizing 872 entity and obtain authentication data for the message. 874 3. Verify the requested resources do not exceed the authorized QoS. 876 7. Error Signaling 878 If a PDP fails to verify the AUTH_SESSION policy element then it 879 MUST return a policy control failure (Error Code = 02) to the PEP. 880 The error values are described in [RFC-2205] and [RFC-2750]. Also 881 the PDP SHOULD supply a policy data object containing an AUTH_DATA 882 Policy Element with A-Type=POLICY_ERROR_CODE containing more 883 details on the Policy Control failure [RFC-3182]. The PEP 884 MUST include this Policy Data object in the outgoing RSVP Error 885 message. 887 8. IANA Considerations 889 Following the policies outlined in [IANA-CONSIDERATIONS], Standard 890 RSVP Policy Elements (P-type values) are assigned by IETF Consensus 891 action as described in [RFC-2750]. 893 P-Type AUTH_SESSION is assigned the value TBD-by-IANA. 895 Following the policies outlined in [IANA-CONSIDERATIONS], session 896 authorization attribute types (S-Type)in the range 0-127 are 897 allocated through an IETF Consensus action; S-Type values between 898 128-255 are reserved for Private Use and are not assigned by IANA. 900 S-Type AUTH_ENT_ID is assigned the value 1. 901 S-Type SESSION_ID is assigned the value 2. 902 S-Type SOURCE_ADDR is assigned the value 3. 903 S-Type DEST_ADDR is assigned the value 4. 904 S-Type START_TIME is assigned the value 5. 905 S-Type END_TIME is assigned the value 6. 906 S-Type RESOURCES is assigned the value 7. 907 S-Type AUTHENTICATION_DATA is assigned the value 8. 909 Following the policies outlined in [IANA-CONSIDERATIONS], 910 AUTH_ENT_ID SubType values in the range 0-127 are allocated through 911 an IETF Consensus action, SubType values between 128-255 are 912 reserved for Private Use and are not assigned by IANA. 914 AUTH_ENT_ID SubType IPV4_ADDRESS is assigned the value 1. 915 SubType IPV6_ADDRESS is assigned the value 2. 916 SubType FQDN is assigned the value 3. 917 SubType ASCII_DN is assigned the value 4. 918 SubType UNICODE_DN is assigned the value 5. 919 SubType URI is assigned the value 6. 920 SubType KRB_PRINCIPAL is assigned the value 7. 921 SubType X509_V3_CERT is assigned the value 8. 922 SubType PGP_CERT is assigned the value 9. 924 Following the policies outlined in [IANA-CONSIDERATIONS], 925 SOURCE_ADDR SubType values in the range 0-127 are allocated through 926 an IETF Consensus action, SubType values between 128-255 are 927 reserved for Private Use and are not assigned by IANA. 929 SOURCE_ADDR SubType IPV4_ADDRESS is assigned the value 1. 930 SubType IPV6_ADDRESS is assigned the value 2. 931 SubType FQDN is assigned the value 3. 932 SubType ASCII_DN is assigned the value 4. 933 SubType UNICODE_DN is assigned the value 5. 934 SubType UDP_PORT_LIST is assigned the value 6. 936 SubType TCP_PORT_LIST is assigned the value 7. 938 Following the policies outlined in [IANA-CONSIDERATIONS], 939 DEST_ADDR SubType values in the range 0-127 are allocated through an 940 IETF Consensus action, SubType values between 128-255 are reserved 941 for Private Use and are not assigned by IANA. 943 DEST_ADDR SubType IPV4_ADDRESS is assigned the value 1. 944 SubType IPV6_ADDRESS is assigned the value 2. 945 SubType FQDN is assigned the value 3. 946 SubType ASCII_DN is assigned the value 4. 947 SubType UNICODE_DN is assigned the value 5. 948 SubType UDP_PORT_LIST is assigned the value 6. 949 SubType TCP_PORT_LIST is assigned the value 7. 951 Following the policies outlined in [IANA-CONSIDERATIONS], 952 START_TIME SubType values in the range 0-127 are allocated through 953 an IETF Consensus action, SubType values between 128-255 are 954 reserved for Private Use and are not assigned by IANA. 956 START_TIME SubType NTP_TIMESTAMP is assigned the value 1. 958 Following the policies outlined in [IANA-CONSIDERATIONS], 959 END TIME SubType values in the range 0-127 are allocated through an 960 IETF Consensus action, SubType values between 128-255 are reserved 961 for Private Use and are not assigned by IANA. 963 END TIME SubType NTP_TIMESTAMP is assigned the value 1. 965 Following the policies outlined in [IANA-CONSIDERATIONS], 966 RESOURCES SubType values in the range 0-127 are allocated through an 967 IETF Consensus action, SubType values between 128-255 are reserved 968 for Private Use and are not assigned by IANA. 970 RESOURCES SubType BANDWIDTH is assigned the value 1. 971 SubType FLOW_SPEC is assigned the value 2. 972 SubType SDP is assigned the value 3. 973 SubType DSCP is assigned the value 4. 975 9. Security Considerations 977 The purpose of this draft is to describe a mechanism for session 978 authorization to prevent theft of service. 980 Replay attacks MUST be prevented. In the non-associated model, the 981 AUTH_SESSION policy element MUST include a START_TIME field. The 982 start time is used to verify that the request is not being replayed 983 at a later time. In all other models, the SESSION_ID is used by the 984 Policy Server to ensure that the resource request successfully 985 correlates with records of an authorized session. If a AUTH_SESSION 986 is replayed, it MUST be detected by the policy server (using 987 internal algorithms) and the request MUST be rejected. 989 To ensure that the integrity of the policy element is preserved in 990 untrusted environments, the AUTHENTICATION_DATA attribute MUST be 991 included. 993 In order to keep the AUTH_SESSION policy element size to a strict 994 minimum, in environments where shared private keys are possible, 995 they should be used. This is especially true in wireless 996 environments where the AUTH_SESSION policy element is sent over-the- 997 air. The shared private keys authentication option MUST be supported 998 by all AUTH_SESSION implementations. 1000 If shared private keys are not a valid option, the Kerberos 1001 authentication mechanism is reasonably well secured and efficient in 1002 terms of AUTH_SESSION size. The AUTH_SESSION only needs to contain 1003 the principal@realm name of the authorizing entity. This is much 1004 more efficient than the PKI authentication option. 1006 PKI authentication option provides a high level of security and good 1007 scalability, however it requires the presence of credentials in the 1008 AUTH_SESSION policy element which impacts its size. 1010 10. Acknowledgments 1012 We would like to thank Louis LeVay, Francois Audet, Don Wade, Hamid 1013 Syed, Kwok Ho Chan and many others for their valuable comments. 1015 In addition, we would like to thank S. Yadav, et al, for their 1016 efforts on RFC 3182, as this document borrows from their work. 1018 11. Normative References 1020 [S-AUTH] Hamer, L.-N., Gage, B., Shieh, H., "Framework 1021 for session setup with media authorization", 1022 Internet-Draft, 1023 draft-ietf-rap-session-auth-04.txt, 1024 June 2002. 1026 [ASCII] Coded Character Set -- 7-Bit American 1027 Standard Code for Information Interchange, 1028 ANSI X3.4-1986. 1030 [RFC-2750] Herzog, S., "RSVP Extensions for Policy 1031 Control", RFC 2750, January 2000. 1033 [RFC-2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A 1034 Framework for Policy-based Admission Control 1035 RSVP", RFC 2753, January 2000. 1037 [RFC-1034] Mockapetris, P.V., "Domain names - concepts 1038 and facilities", RFC 1034, November 1987. 1040 [RFC-1305] Mills, David L., "Network Time Protocol 1041 (Version 3) Specification, Implementation, and 1042 Analysis", RFC 1305, March 1992. 1044 [RFC-1321] Rivest, R., "The MD5 Message-Digest 1045 Algorithm",RFC 1321, April 1992. 1047 [RFC-1510] Kohl, J. and C. Neuman, "The Kerberos Network 1048 Authentication Service (V5)", RFC 1510, 1049 September 1993. 1051 [RFC-2104] Krawczyk, H., Bellare, M. and R. Canetti, 1052 "HMAC: Keyed-Hashing for Message 1053 Authentication", RFC 2104, February 1997. 1055 [RFC-2253] Wahl, M. et al., "UTF-8 String 1056 Representation of Distinguished Names", 1057 RFC 2253, December 1997. 1059 [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. 1060 and S. Jamin, "Resource ReSerVation Protocol 1061 (RSVP) - Version 1 Functional Specification", 1062 RFC 2205, September 1997. 1064 [RFC-2209] Braden, R. and L. Zhang, "Resource 1065 ReSerVation Protocol (RSVP) - Version 1 1066 Message Processing Rules", RFC 2209, 1067 September 1997. 1069 [RFC-2327] Handley, M., Jacobson, V., "SDP: Session 1070 Description Protocol", RFC 2327, October 1071 1998. 1073 [RFC-2396] Berners-Lee, T., Fielding, R., Irvine, U.C., 1074 Masinter, L., "Uniform Resource Identifiers 1075 (URI): Generic Syntax", RFC 2396, August 1076 1998. 1078 [RFC-2474] Nichols, K., Blake, S., Baker, F., Black, D., 1079 "Definition of the Differentiated Services 1080 Field (DS Field) in the IPv4 and IPv6 1081 Headers", RFC 2474, December 1998. 1083 [UNICODE] The Unicode Consortium, "The Unicode 1084 Standard,Version 2.0", Addison-Wesley, 1085 Reading, MA, 1996. 1087 [X.509] Housley, R., Ford, W., Polk, W. and D. Solo, 1088 "Internet X.509 Public Key Infrastructure 1089 Certificate and CRL Profile", RFC 2459, 1090 January 1999. 1092 [X.509-ITU] ITU-T (formerly CCITT) Information technology 1093 Open Systems Interconnection - The Directory: 1094 Authentication Framework Recommendation X.509 1095 ISO/IEC 9594-8 1097 12. Informative References 1099 [RFC-3182] S. Yadav et al, "Identity Representation for 1100 RSVP", RFC 3182, October 2001 1102 [RFC-2998] Bernet, Y., Ford, P., Yavatkar, R., 1103 Baker, F.,Zhang, L., Speer, M., Braden, R., 1104 Davie, B., Wroclawski, J., Felstaine, E., "A 1105 Framework for Integrated Services Operation 1106 over Diffserv Networks", RFC 2998, November 1107 2000. 1109 [RFC-1633] Braden, R., Clark, D., Shenker, S., 1110 "Integrated Services in the Internet 1111 Architecture: An Overview", RFC 1633, 1112 June 1994. 1114 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 1115 Writing an IANA Considerations Section in 1116 RFCs", BCP 26, RFC 2434, October 1998. 1118 13. Author Information 1120 Louis-Nicolas Hamer 1121 Nortel Networks 1122 PO Box 3511 Station C 1123 Ottawa, Ontario 1124 Canada K1Y 4H7 1125 Phone: +1 613.768.3409 1126 EMail: nhamer@nortelnetworks.com 1128 Brett Kosinski 1129 University of Alberta 1130 Edmonton, Alberta 1131 Canada T6G 2M7 1132 EMail: kosinski@cs.ualberta.ca 1133 Bill Gage 1134 Nortel Networks 1135 PO Box 3511 Station C 1136 Ottawa, Ontario 1137 Canada K1Y 4H7 1138 Phone: +1 613.763.4400 1139 EMail: gageb@nortelnetworks.com 1141 Matt Broda 1142 Nortel Networks 1143 PO Box 3511 Station C 1144 Ottawa, Ontario 1145 Canada K1Y 4H7 1146 Phone: +1 613.763.7399 1147 EMail: mbroda@nortelnetworks.com 1149 Hugh Shieh 1150 AT&T Wireless 1151 7277 164th Avenue NE 1152 Redmond, WA 1153 USA 98073-9761 1154 Phone: +1 425.580.6898 1155 Email: hugh.shieh@attws.com 1157 14. Full Copyright Statement 1159 Copyright (C) The Internet Society (2002). All Rights Reserved. This 1160 document and translations of it may be copied and furnished to 1161 others, and derivative works that comment on or otherwise explain it 1162 or assist in its implementation may be prepared, copied, published 1163 and distributed, in whole or in part, without restriction of any 1164 kind, provided that the above copyright notice and this paragraph 1165 are included on all such copies and derivative works. However, this 1166 document itself may not be modified in any way, such as by removing 1167 the copyright notice or references to the Internet Society or other 1168 Internet organisations, except as needed for the purpose of 1169 developing Internet standards in which case the procedures for 1170 copyrights defined in the Internet Standards process must be 1171 followed, or as required to translate it into. 1173 15. Notices 1175 "The IETF takes no position regarding the validity or scope of 1176 any intellectual property or other rights that might be claimed 1177 to pertain to the implementation or use of the technology 1178 described in this document or the extent to which any license 1179 under such rights might or might not be available; neither does 1180 it represent that it has made any effort to identify any such 1181 rights. Information on the IETF's procedures with respect to 1182 rights in standards-track and standards-related documentation 1183 can be found in BCP-11. Copies of claims of rights made 1184 available for publication and any assurances of licenses to 1185 be made available, or the result of an attempt made 1186 to obtain a general license or permission for the use of such 1187 proprietary rights by implementors or users of this 1188 specification can be obtained from the IETF Secretariat." 1190 "The IETF invites any interested party to bring to its 1191 attention any copyrights, patents or patent applications, or 1192 other proprietary rights which may cover technology that may be 1193 required to practice this standard. Please address the 1194 information to the IETF Executive Director." 1196 16. RFC Editor Considerations 1198 This document references an IETF Internet-Draft that is in the IESG 1199 last call stage. Please use the corresponding RFC number prior to 1200 publishing of this document as a RFC. The referenced IETF I-D is 1201 [S-AUTH].