Network Working Group B. Sterman Internet-Draft Kayote Networks Expires: November 30, 2004 D. Sadolevsky SecureOL, Inc. D. Schwartz Kayote Networks D. Williams Cisco Systems W. Beck Deutsche Telekom AG June 2004 RADIUS Extension for Digest Authentication draft-sterman-aaa-sip-03.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Basic and Digest authentication schemes are widely used in protocols such as SIP and HTTP . RADIUS is a protocol for back end Sterman, et al. Expires November 30, 2004 [Page 1] Internet-Draft RADIUS Extension for Digest Authentication June 2004 authentication. RADIUS supports Basic authentication natively, as well as several other authentication schemes, such as CHAP, but does not support Digest authentication scheme. This document describes an extension to RADIUS for Digest authentication and provides a scenario of Digest user authentication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Scenario 1, RADIUS client chooses nonces . . . . . . . . . 4 1.4 Scenario 2, RADIUS server chooses nonces . . . . . . . . . 5 1.5 Approach . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. New RADIUS attributes . . . . . . . . . . . . . . . . . . . 8 2.1 Digest-Response attribute . . . . . . . . . . . . . . . . 8 2.2 Digest-Realm attribute . . . . . . . . . . . . . . . . . . 9 2.3 Digest-Nonce attribute . . . . . . . . . . . . . . . . . . 9 2.4 Digest-Method attribute . . . . . . . . . . . . . . . . . 10 2.5 Digest-URI attribute . . . . . . . . . . . . . . . . . . . 10 2.6 Digest-QoP attribute . . . . . . . . . . . . . . . . . . . 11 2.7 Digest-Algorithm attribute . . . . . . . . . . . . . . . . 11 2.8 Digest-Body attribute . . . . . . . . . . . . . . . . . . 12 2.9 Digest-CNonce attribute . . . . . . . . . . . . . . . . . 13 2.10 Digest-Nonce-Count attribute . . . . . . . . . . . . . . 13 2.11 Digest-Username attribute . . . . . . . . . . . . . . . 14 2.12 Digest-Opaque attribute . . . . . . . . . . . . . . . . 14 2.13 Digest-Auth-Param attribute . . . . . . . . . . . . . . 15 2.14 Digest-AKA-Auts attribute . . . . . . . . . . . . . . . 16 2.15 Digest-Domain attribute . . . . . . . . . . . . . . . . 16 2.16 Digest-Stale attribute . . . . . . . . . . . . . . . . . 17 3. Detailed Description . . . . . . . . . . . . . . . . . . . . 18 3.1 RADIUS Client Behaviour . . . . . . . . . . . . . . . . . 18 3.2 RADIUS Server Behaviour . . . . . . . . . . . . . . . . . 19 4. Migration Path to DIAMETER . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . 24 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. Changes from -02 . . . . . . . . . . . . . . . . . . . . . . 29 9. Changes from -01 . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1 Normative References . . . . . . . . . . . . . . . . . . . 31 10.2 Informative References . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . 35 Sterman, et al. Expires November 30, 2004 [Page 2] Internet-Draft RADIUS Extension for Digest Authentication June 2004 1. Introduction 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Motivation Digest authentication is a simple authentication mechanism for HTTP and SIP. While it was not too successful in HTTP environments, it is the only SIP authentication mechanism that has been widely adopted. Due to the weaknesses of Digest authentication (see Section 6), PKI-based authentication and encryption mechanisms have been introduced into SIP: TLS [RFC2246] and S/MIME [RFC2633]. However, most SIP user agents that support TLS don't send client certificates. SIP with S/MIME is lacking support, too: even two years after the inclusion of S/MIME into SIP, almost no implementations exist. SIP service providers whishing to authenticate their clients have the following options: they can o build a PKI and wait for interopable S/MIME capable SIP implementations, o build a PKI and wait for SIP implementations supporting TLS with client-side certificates, o replace their existing RADIUS infrastructure with DIAMETER [RFC3588], when DIAMETER supports HTTP Digest authentication, o use TLS for server authentication and plaintext passwords (Basic) for client authentication, which can be done with standard RADIUS, o upgrade their existing RADIUS servers with the functionality described in this document PKI solutions only cover authentication, not authorization (EAP could change this, but its use with SIP is not standardized). TLS / Basic authentication works only with the limited number of SIP devices that implement TLS. Basic authentication has been deprecated for SIP in [RFC3261]. Current RADIUS-based AAA infrastructures have been built and debugged over years. Deficiencies of RADIUS have been mitigated with proprietary (ie costly) extensions. Operators are therefore reluctant to replace their RADIUS infrastructure in order to enable a single new authentication mechanism. Given the complexity of S/MIME, simple clients will continue to support HTTP digest authentication only. Its interopability with a back-end authentication protocol such as RADIUS is needed. Sterman, et al. Expires November 30, 2004 [Page 3] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Operators that are about to replace their RADIUS-based AAA infrastructure are strongly recommended to use DIAMETER. 1.3 Scenario 1, RADIUS client chooses nonces Figure 1 depicts the basic scenario that is relevant for this document. It shows a generic case where entities A and B communicate in the front-end using protocols such as HTTP/SIP, while entities B and C communicate in the back-end using RADIUS. HTTP/SIP RADIUS +-----+ (1) +-----+ +-----+ | |==========>| | | | | | (2) | | | | | |<==========| | | | | | (3) | | | | | |==========>| | | | | A | | B | (4) | C | | | | |---------->| | | | | | (5) | | | | | |<----------| | | | (6) | | | | | |<==========| | | | +-----+ +-----+ +-----+ ====> HTTP/SIP ----> RADIUS Figure 1: Overview of basic operation The roles played by the entities in this scenario are as follows: A: HTTP client / SIP UA B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} acting also as a RADIUS NAS C: RADIUS server The relevant order of messages sent in this scenario is as follows: Sterman, et al. Expires November 30, 2004 [Page 4] Internet-Draft RADIUS Extension for Digest Authentication June 2004 A sends B an HTTP/SIP request without authorization header (step 1). B challenges A sending an HTTP/SIP "(Proxy) Authorization required" response containing a locally generated nonce (step 2). A sends B an HTTP/SIP request with authorization header (step 3). B sends C a RADIUS Access-Request with attributes described in this document (step 4). C responds to B with a RADIUS Access-Accept/Access-Reject response (step 5). If credentials were accepted B receives an Access-Accept response and the message sent from A is considered authentic. If B receives an Access-Reject response, however, B then responds to A with a "(Proxy) Authorization required" response (step 6). 1.4 Scenario 2, RADIUS server chooses nonces Figure 2 depicts an alternative scenario, where the RADIUS server generates nonces. It shows a generic case where entities A and B communicate in the front-end using protocols such as HTTP/SIP, while entities B and C communicate in the back-end using RADIUS. Sterman, et al. Expires November 30, 2004 [Page 5] Internet-Draft RADIUS Extension for Digest Authentication June 2004 HTTP/SIP RADIUS +-----+ (1) +-----+ +-----+ | |==========>| | (2) | | | | | |---------->| | | | | | (3) | | | | (4) | |<----------| | | |<==========| | | | | | (5) | | | | | |==========>| | | | | A | | B | (6) | C | | | | |---------->| | | | | | (7) | | | | | |<----------| | | | (8) | | | | | |<==========| | | | +-----+ +-----+ +-----+ ====> HTTP/SIP ----> RADIUS Figure 2: RADIUS server chooses nonces The roles played by the entities in this scenario are as follows: A: HTTP client / SIP UA B: {HTTP server / HTTP proxy server / SIP proxy server / SIP UAS} acting also as a RADIUS NAS C: RADIUS server The relevant order of messages sent in this scenario is as follows: A sends B an HTTP/SIP request without authorization header (step 1). B sends an Access-Request message with the newly defined Digest-Method and Digest-URI attributes but without a Digest-Nonce attribute to the RADIUS server, C (step 2). C chooses a nonce and responds with an Access-Accept (step 3). This Access-Accept contains Digest attributes, from which B takes values to construct a HTTP/SIP "(Proxy) Authorization required" response. The remaining steps are identical with scenario 1 (Section 1.3): B sends this response to A (step 4). A resends its request with its credentials (step 5). B sends an Access-Request to C (step 6). C checks the credentials and replies with Access-Accept or Access-Reject (step 7). Dependent on the C's result, B processes A's request or rejects it with a "(Proxy) Sterman, et al. Expires November 30, 2004 [Page 6] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Authorization required" response (step 8). 1.5 Approach The approach taken here is to extend RADIUS to support Digest authentication by mimicking its native support for CHAP authentication. According to [RFC2865], the RADIUS server distinguishes between different authentication schemes by looking at the presence of an attribute specific for that scheme. For the three natively supported authentication schemes, these attributes are: User-Password for PAP (or any other clear-text password scheme), CHAP-Password for CHAP, and State + User- Password for challenge-response scheme. This document adds another attribute to be used in this role: Digest-Response. Also according to [RFC2865], "An Access-Request packet MUST contain either a User-Password or a CHAP-Password or a State. It MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used instead of User-Password or CHAP-Password." The Digest-Response introduced here therefore can be used instead of User-Password or CHAP-Password. The HTTP Authentication parameters found in the Proxy-Authorization or Authorization request header are mapped into newly defined RADIUS attributes. These new RADIUS attributes are defined in the document together with some other information required for calculating the correct digest response on the RADIUS server with exception of the password, which the RADIUS server is assumed to be able to retrieve from a data store given the username. In most cases, the operation outlined in Section 1.3 is sufficient. It reduces the load on the RADIUS server to a minimum. However, in some cases the RADIUS server is better off with pre-computed hashes. Section 1.4 describes an mechanism that enables this style of authentication. Sterman, et al. Expires November 30, 2004 [Page 7] Internet-Draft RADIUS Extension for Digest Authentication June 2004 2. New RADIUS attributes DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG, DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP, DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that will be assigned by IANA, if this specification becomes a working group or IESG document. The term 'HTTP-style' denotes any protocol that uses HTTP-like headers and uses HTTP digest authentication as described in [RFC2617]. Examples are HTTP and SIP. 2.1 Digest-Response attribute If this attribute is present, the RADIUS server SHOULD view the Access-Request as a Digest one. When a RADIUS client receives a (Proxy-)Authorization header, it puts the request-digest value into a Digest-Response attribute. Access-Accept packets MUST contain a Digest-Response attribute. In Access-Accept packets, this attribute contains a digest that can be used for generating Authentication-Info headers. The calculation of this digest is described in [RFC2617], section 3.2.3. A summary of the Digest-Response attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-RES for Digest-Response. Early implementations have used the experimental type 206. Length 34 String In Access-Requests, this string proves the user knows a password. The String field is 32 octets long and contains hexadecimal representation of 16 octet digest value as it was calculated by the authenticated client. The String field SHOULD be copied from request-digest of digest-response Sterman, et al. Expires November 30, 2004 [Page 8] Internet-Draft RADIUS Extension for Digest Authentication June 2004 ([RFC2617]). In Access-Accepts, this string proves the RADIUS server knows the password. The RADIUS server calculates a digest according to section 3.2.3 of [RFC2617] and copies the result into this string. 2.2 Digest-Realm attribute This string attribute describes a protection space of the RADIUS server. See [RFC2617] 1.2 for details. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-REALM Length >=3 String In Access-Requests, the RADIUS client takes the value of the realm directive (realm-value) from the HTTP-style request it wants to authenticate. In Access-Accept messages carrying a Digest-Nonce attribute, the RADIUS server puts the expected realm value into this attribute. 2.3 Digest-Nonce attribute This attribute holds a random nonce to be used in the HTTP Digest calculation. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sterman, et al. Expires November 30, 2004 [Page 9] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Type DIG-NONCE Length >=3 String In Access-Requests, the RADIUS client takes the value of the nonce directive (nonce-value) from the HTTP-style request it wants to authenticate. If the Access-Request had a Digest-Nonce attribute, the RADIUS server MAY put the nonce to be used in a future request into this attribute in the Access-Accept message. If the Access-Request had a Digest-Method and a Digest-URI but no Digest-Nonce attribute and the RADIUS server is configured to choose nonces, it MUST put a Digest-Nonce attribute into its Access-Accept message. 2.4 Digest-Method attribute This attribute holds the method string to be used in the HTTP Digest calculation. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-METHOD Length >=3 String In Access-Requests, the RADIUS client takes the value of the request method from the HTTP-style request it wants to authenticate. This attribute MUST only be used in Access-Request messages. 2.5 Digest-URI attribute This attribute holds the URI string to be used in the HTTP Digest calculation. Sterman, et al. Expires November 30, 2004 [Page 10] Internet-Draft RADIUS Extension for Digest Authentication June 2004 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-URI Length >=3 String In Access-Requests, the RADIUS client takes the value of the request URI (digest-uri-value) from the HTTP-style request it wants to authenticate. The attribute MUST only be used in Access-Request messages. 2.6 Digest-QoP attribute This attribute holds the Quality of Protection parameter that influences the HTTP Digest calculation. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-QOP Length >=3 String In Access-Requests, the RADIUS client takes the value of the qop directive (qop-value) from the HTTP-style request it wants to authenticate. In Access-Accept messages carrying a Digest-Nonce attribute, the RADIUS server MAY put the desired qop-value into this attribute. 2.7 Digest-Algorithm attribute This attribute holds the algorithm parameter that influences the HTTP Sterman, et al. Expires November 30, 2004 [Page 11] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Digest calculation. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-ALG Length >=3 String In Access-Requests, the RADIUS client takes the value of the algorithm directive from the HTTP-style request it wants to authenticate. In Access-Accept messages, the RADIUS server MAY put the desired algorithm into this attribute. 2.8 Digest-Body attribute When using the qop level 'auth-int', the contents of the message body are required for digest calculation. Instead of sending the complete body of the message, only its hash value is sent. This hash value can be used directly in the digest calculation. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-BODY Length 34 Sterman, et al. Expires November 30, 2004 [Page 12] Internet-Draft RADIUS Extension for Digest Authentication June 2004 String String, hexadecimal representation of a digest calculated over entity-body of HTTP/SIP request ([RFC2616], [RFC3261]). Computed by entity B in figure Figure 1. This attribute is not part of the HTTP Digest response. See [RFC2617] section 3.2.2.3. This attribute MUST only be sent in Access-Request packets. 2.9 Digest-CNonce attribute This attribute holds the client nonce parameter that is used in the HTTP Digest calculation. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-CNONCE Length >=3 String In Access-Requests, the RADIUS client takes the value of the cnonce directive (cnonce-value) from the HTTP-style request it wants to authenticate. The attribute is never used in Access-Response messages. 2.10 Digest-Nonce-Count attribute This attribute holds the nonce count parameter that is used to detect replay attacks. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sterman, et al. Expires November 30, 2004 [Page 13] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Type DIG-NC Length 9 String In Access-Requests, the RADIUS client takes the value of the nc directive (nc-value) from the HTTP-style request it wants to authenticate. The attribute MUST only be used in Access-Request messages. 2.11 Digest-Username attribute This attribute holds the user name parameter that is used in the HTTP digest calculation. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-USER Length >= 3 String In Access-Requests, the RADIUS client takes the value of the username directive (username-value) from the HTTP-style request it wants to authenticate. The RADIUS server SHOULD NOT use this value for password finding, but only for digest calculation purpose. In order to find the user record containing the password, the RADIUS server SHOULD use the value of the ([RFC2865] -)User-Name attribute. This attribute MUST only be sent in Access-Request packets. 2.12 Digest-Opaque attribute This attribute holds the opaque parameter that is passed to the HTTP-style client. Th HTTP-style client passes this value back to the server (ie the RADIUS client) without modification. Sterman, et al. Expires November 30, 2004 [Page 14] Internet-Draft RADIUS Extension for Digest Authentication June 2004 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-OPAQUE Length >=3 String This attribute is only used when the RADIUS server chooses nonces. In Access-Requests, the RADIUS client takes the value of the opaque directive from the HTTP-style request it wants to authenticate and puts it into this attribute. In Access-Accept messages carrying a Digest-Nonce attribute, the RADIUS server MAY include this attribute. 2.13 Digest-Auth-Param attribute This attribute is a placeholder for future extensions. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-AUTHP Length >=3 String This attribute is for future extensions. Any extension parameter in the digest-response can be put into a Digest-Auth-Param attribute. The string consists of the whole parameter, including its name and the equal ('=') sign. RADIUS servers that do not implement a parameter contained in an Digest-Auth-Param attribute MUST respond with an Access-Reject message. RADIUS clients that do not implement a parameter contained in an Digest-Auth-Param attribute MUST reject the Sterman, et al. Expires November 30, 2004 [Page 15] Internet-Draft RADIUS Extension for Digest Authentication June 2004 original HTTP-style request. This attribute MAY be used in Access-Request and Access-Accept messages. 2.14 Digest-AKA-Auts attribute This attribute holds the auts parameter that is used in the AKA Digest ([RFC3310]) calculation. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-AUTS Length >=3 String In Access-Requests, the RADIUS client takes the value of the auts directive from the HTTP-style request it wants to authenticate. It is only used if the algorithm of the digest-response denotes a version of AKA digest [RFC3310]. RADIUS servers that do not implement AKA digest MUST respond with an Access-Reject message. 2.15 Digest-Domain attribute When a RADIUS client has asked for a nonce, the RADIUS server MAY add one or more Digest-Domain attributes to its Access-Accept message. The RADIUS client puts them into the quoted, space-separated list of URIs of the 'domain' directive of a WWW-Authenticate header. The URIs in the list define the protection space (see [RFC2617], section 3.2.1). 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sterman, et al. Expires November 30, 2004 [Page 16] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Type DIG-DOMAIN Length 3 String The string consists of a single URI, that defines a protection space. RADIUS servers MAY send attributes of this type in Access-Accept messages that contain a Digest-Nonce attribute. RADIUS clients MUST NOT put attributes of this type in Access-Request messages. 2.16 Digest-Stale attribute If this attribute is present, the RADIUS server did not accept the nonce value. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type DIG-STALE Length 3 String The string consists of a single character '1'. The contents of this string MAY be ignored by an implementation. The presence of the attribute itself tells the RADIUS client that the nonce was considered stale. The attribute MUST only be used in Access-Accept messages. Sterman, et al. Expires November 30, 2004 [Page 17] Internet-Draft RADIUS Extension for Digest Authentication June 2004 3. Detailed Description 3.1 RADIUS Client Behaviour A RADIUS client without an encrypted or otherwise secured connection to its RADIUS server only accepts unsecured connections from its HTTP-style clients (or else the clients would have a false sense of security). The RADIUS client examines the (Proxy-)Authorization header of an incoming HTTP-style request message. If this header is present and contains HTTP digest information, the RADIUS client checks the 'nonce' parameter. If the 'nonce' value has not been sent by the RADIUS client, it responds with a 401 (Unauthorized) or 407 (Proxy Authentication Required) to the HTTP-style client. In this error response, the RADIUS client sends a new nonce. If the RADIUS client recognizes the nonce, it takes the header parameters and puts them into a RADIUS Access-Request message. It puts the 'response' parameter into a Digest-Response attribute and the realm / nonce / qop / algorithm / cnonce / nc / username into the respective Digest-Realm / Digest-Nonce / Digest-QoP / Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest-Username attributes. The request URI and the request method are put into the Digest-URI and Digest-Method attributes. Now, the RADIUS client sends the Access-Request message to the RADIUS server. The RADIUS server processes the message and responds with an Access-Accept or an Access-Reject. If the RADIUS client receives an Access-Accept, it examines the Digest attributes contained in the message. If the Digest-Stale attribute is present, the RADIUS client sends an error (401 or 407) response containing WWW-/Proxy-Authenticate header with a stale directive. If the Digest-Stale attribute is not present, the RADIUS client constructs an Authentication-Info header and puts the contents of Digest-Response into the 'rspauth' directive. The RADIUS server MAY have added a Digest-Nonce attribute. If the RADIUS client discovers this, it puts the contents of this attribute into a 'nextnonce' directive. Now it can send a HTTP-style response. If the RADIUS client did not receive a (Proxy-)Authorization header from its HTTP-style client, it obtains a new nonce and sends an error response (401 or 407) containing a (Proxy-)Authenticate header. If the RADIUS client receives an Access-Reject or no response from Sterman, et al. Expires November 30, 2004 [Page 18] Internet-Draft RADIUS Extension for Digest Authentication June 2004 the RADIUS server, it sends an error response to the HTTP-style request it has received. The RADIUS client has three ways to obtain nonces: it generates them locally, it has received one in a Digest-Nonce attribute of a previously received Access-Accept message, or it asks the RADIUS server for one. To do the latter, it sends an Access-Request containing a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute. The RADIUS server chooses a nonce and responds with an Access-Accept containing a Digest-Nonce attribute. If the RADIUS server responds with an Access-Reject, the RADIUS client MAY generate a nonce locally. If the RADIUS client does not generate nonces locally, the authentication has failed. The RADIUS server can send Digest-QoP, Digest-Algorithm, Digest-Realm, Digest-Domain and Digest-Opaque attributes in the Access-Accept carrying the nonce. If these attributes are present, the client MUST use them. 3.2 RADIUS Server Behaviour If the RADIUS server receives an Access-Request message with a Digest-Method and a Digest-URI attribute but without a Digest-Nonce attribute, it chooses a nonce. It puts the nonce into a Digest-Nonce attribute and sends it in an Access-Accept message to the RADIUS client. The RADIUS server MAY add Digest-QoP, Digest-Algorithm, Digest-Realm, Digest-Domain and Digest-Opaque attributes to the Access-Accept message. If the server cannot choose a nonce, it replies with an Access-Reject message. If the RADIUS server receives an Access-Request message containing a Digest-Response attribute, it looks for the following attributes: Digest-Realm, Digest-Nonce, Digest-Method, Digest-URI, Digest-QoP, Digest-Algorithm, Digest-Username. Depending on the content of Digest-Algorithm and Digest-QoP, it looks for Digest-Body, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and [RFC3310] for details. If it has issued a Digest-Opaque attribute along with the present nonce, the Access-Request MUST have a matching Digest-Opaque attribute. If it does not find these attributes, it responds with an Access-Reject message. If the attributes are present, the RADIUS server calculates the digest response as described in [RFC2617]. To look up the password, the RADIUS server uses the RADIUS User-Name attribute. All other values are taken from the Digest attributes described in this document. If the calculated digest response equals the string received in the Digest-Response attribute, the authentication was successful. If not, the RADIUS server responds with an Access-Reject. Sterman, et al. Expires November 30, 2004 [Page 19] Internet-Draft RADIUS Extension for Digest Authentication June 2004 If the authentication was successful, the RADIUS server calculates a Digest-Response attribute that can be used by the RADIUS client to construct an Authentication-Info header. The calculation of this response is described in [RFC2617], section 3.2.3. RADIUS servers issuing nonces MAY construct a Digest-Nonce attribute. This is useful to limit the lifetime of a nonce and to save a round-trip in future requests (see nextnonce discussion in [RFC2617], section 3.2.3). The Digest-Response attribute and the optional Digest-Nonce attribute are send to the RADIUS client in an Access-Accept message. Sterman, et al. Expires November 30, 2004 [Page 20] Internet-Draft RADIUS Extension for Digest Authentication June 2004 4. Migration Path to DIAMETER The following table gives an overview of the mapping between RADIUS attributes defined here and the corresponding DIAMETER AVPs described in [I-D.ietf-aaa-diameter-sip-app]: +---------------------------------+---------------------------------+ | RADIUS | DIAMETER | +---------------------------------+---------------------------------+ | Digest-Realm | Digest-Realm | | | | | Digest-Nonce | Digest-Nonce | | | | | Digest-URI | Digest-URI | | | | | Digest-Domain | Digest-Domain | | | | | Digest-QoP | Digest-Qop | | | | | Digest-Algorithm | Digest-Algorithm | | | | | Digest-CNonce | Digest-Cnonce | | | | | Digest-Nonce-Count | Digest-Nonce-Count | | | | | Digest-Method | SIP-Method AVP | | | | | Digest-Username | Digest-Username AVP | | | | | Digest-Body | SIP-Entity-Body-Hash AVP | | | | | Access-Request Digest-Response | SIP-Authorization | | | Digest-Response | | | | | Access-Accept Digest-Response | SIP-Authentication-Info | | | Digest-Response | | | | | Digest-Opaque | Digest-Opaque AVP | | | | | Digest-Auth-Param | Digest-Auth-Param | | | | | Digest-AKA-Auts | Digest-AKA-Auts | | | | | Digest-Response | Digest-Response AVP | | | | | Digest-Stale | Digest-Stale AVP | +---------------------------------+---------------------------------+ Sterman, et al. Expires November 30, 2004 [Page 21] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Table 1 Access-Requests containing a Digest-Response attribute and other Digest attributes are mapped to a DIAMETER SIP-Authorization AVP. The RADIUS/DIAMETER gateway constructs a MAR and sends it to the DIAMETER server. If the authentication was successful, the DIAMETER server replies with a MAA containing a SIP-Authentication-Info and a Digest-Response AVP. The gateway converts these to the corresponding RADIUS attributes and constructs a RADIUS message. If the Result-Code AVP is DIAMETER_SUCCESS or a Digest-Stale AVP is present, an Access-Accept is sent. In all other cases, an Access-Reject is sent. +---------------+------------+ | RADIUS | DIAMETER | +---------------+------------+ | Digest-URI | SIP-AOR | | | | | Digest-Method | SIP-Method | +---------------+------------+ Table 2 If an Access-Request contains a Digest-Method and a Digest-URI attribute but no Digest-Nonce attribute, the gateway maps the RADIUS attributes to DIAMETER according to Table 2. The gateway construct a MAR message and sends it to the DIAMETER server. If the MAA contains a SIP-Authenticate-AVP, the gateway maps the contained values to RADIUS attributes, according to Table 1. If the Result-Code AVP is DIAMETER_MULTI_ROUND_AUTH, the gateway constructs an Access-Accept and sends it. Sterman, et al. Expires November 30, 2004 [Page 22] Internet-Draft RADIUS Extension for Digest Authentication June 2004 5. IANA Considerations DIG-RES, DIG-REALM, DIG-NONCE, DIG-METHOD, DIG-URI, DIG-QOP, DIG-ALG, DIG-BODY, DIG-CNONCE, DIG-NC, DIG-USER, DIG-OPAQUE, DIG-AUTHP, DIG-AUTS, DIG-DOMAIN and DIG-STALE are placeholders for values that require IANA registration. They must be assigned from the RADIUS attribute type number space, if this specification becomes a working group or IESG document. Sterman, et al. Expires November 30, 2004 [Page 23] Internet-Draft RADIUS Extension for Digest Authentication June 2004 6. Security Considerations The RADIUS extensions described in this document make RADIUS a transport protocol for the data that is required to perform a digest calculation. It adds the vulnerabilities of HTTP Digest (see [RFC2617], section 4) to those of RADIUS (see [RFC2865], section 8 or )). If an attacker gets access to a RADIUS client or RADIUS proxy, it can perform man-in-the-middle attacks even if the connections between A, B and B, C (Figure 1) have been secured with TLS or IPSec. SIP or HTTP requests occur much more frequently than dial-in requests. RADIUS servers implementing this specification must meet that additional performance requirements. An attacker could try to overload the RADIUS infrastructure by excessively sending SIP or HTTP requests. This kind of attack was more difficult when RADIUS was just used for dial-in authentication: the attacker could be identified by the DSL / Cable interface or with some help of the PSTN provider. To make simple denial of service attacks more difficult, RADIUS clients MUST check if nonces received from a client have been issued by them. This SHOULD be done statelessly. For example, a nonce could consist of a cryptographically random part and some kind of signature of the RADIUS client, as described in [RFC2617], section 3.2.1. RADIUS servers MAY include Digest-QoP and Digest-Algorithm attributes in Access-Accept messages. A man in the middle can modify or remove those attributes in a bidding down attack. In this case, the RADIUS client would use a weaker authentication scheme than intended. Informational RfC 3579 [RFC3579], section 3.2 describes a Message-Authenticator attribute which MAY be used to protect the integrity of RADIUS messages. HTTP-style clients can use TLS with server side certificates together with HTTP-Digest authentication. IPSec can be used in a similar way. TLS or IPSec secure the connection while Digest Authentication authenticates the user. If a RADIUS client accepts such connections, it MUST have a secure connection to the RADIUS server. Sterman, et al. Expires November 30, 2004 [Page 24] Internet-Draft RADIUS Extension for Digest Authentication June 2004 7. Example This is an example sniffed from the traffic between HearMe softphone (A), Cisco Systems Proxy Server (B) and deltathree RADIUS server (C) (The communication between Cisco Systems Proxy Server and a SIP PSTN gateway is omitted for brevity): A->B INVITE sip:97226491335@213.137.69.38 SIP/2.0 Via: SIP/2.0/UDP 213.137.67.67:5061 From: ;tag=216ae97f To: sip:97226491335@213.137.69.38 Contact: sip:12345678@213.137.67.67:5061 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 CSeq: 2544265 INVITE Content-Length: 150 Content-Type: application/sdp User-Agent: HearMe SoftPHONE v=0 o=HearMe 2544265 2544265 IN IP4 213.137.67.67 s=HearMe c=IN IP4 213.137.67.67 t=0 0 m=audio 8000 RTP/AVP 0 4 a=ptime:20 a=x-ssrc:009aa330 B->A SIP/2.0 100 Trying Via: SIP/2.0/UDP 213.137.67.67:5061 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 From: ;tag=216ae97f To: sip:97226491335@213.137.69.38 CSeq: 2544265 INVITE Content-Length: 0 B->A SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 213.137.67.67:5061 Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 Sterman, et al. Expires November 30, 2004 [Page 25] Internet-Draft RADIUS Extension for Digest Authentication June 2004 From: ;tag=216ae97f To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc CSeq: 2544265 INVITE Proxy-Authenticate: DIGEST realm="deltathree" ,nonce="3bada1a0", algorithm="md5" Content-Length: 0 A->B ACK sip:97226491335@213.137.69.38 SIP/2.0 Via: SIP/2.0/UDP 213.137.67.67:5061 From: ;tag=216ae97f To: sip:97226491335@213.137.69.38;tag=3f5611de-22a007dc Call-ID: da591c98-f056-4803-a751-0bd296170875@213.137.67.67 CSeq: 2544265 ACK Content-Length: 0 A->B INVITE sip:97226491335@213.137.69.38 SIP/2.0 Via: SIP/2.0/UDP 213.137.67.67:5061 From: ;tag=29e97f To: sip:97226491335@213.137.69.38 Contact: sip:12345678@213.137.67.67:5061 Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 CSeq: 2544266 INVITE Content-Length: 150 Content-Type: application/sdp User-Agent: HearMe SoftPHONE Proxy-Authorization: DIGEST algorithm="md5",nonce="3bada1a0" ,opaque="",realm="deltathree" ,response="2ae133421cda65d67dc50d13ba0eb9bc" ,uri="sip:97226491335@213.137.69.38",username="12345678" v=0 o=HearMe 2544265 2544265 IN IP4 213.137.67.67 s=HearMe c=IN IP4 213.137.67.67 t=0 0 m=audio 8000 RTP/AVP 0 4 a=ptime:20 a=x-ssrc:009aa330 B->C Sterman, et al. Expires November 30, 2004 [Page 26] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Code = 1 (Access-Request) Identifier = 1 Length = 162 Authenticator = 56 7b e6 9a 8e 43 cf b6 fb a6 c0 f0 9a 92 6f 0e Attributes: NAS-IP-Address = d5 89 45 26 (213.137.69.38) NAS-Port-Type = 5 (Virtual) User-Name = "12345678" Digest-Response (DIG-RES) = "2ae133421cda65d67dc50d13ba0eb9bc" Digest-Realm (DIG-REALM) = "deltathree" Digest-Nonce (DIG-NONCE) = "3bada1a0" Digest-Method (DIG-METHOD) = "INVITE" Digest-URI (DIG-URI) = "sip:97226491335@213.137.69.38" Digest-Algorithm (DIG-ALG) = "md5" Digest-Username (DIG-USER) = "12345678" C->B Code = 2 (Access-Accept) Identifier = 1 Length = 20 Authenticator = 6d 76 53 ce aa 07 9a f7 ac b4 b0 e2 96 2f c4 0d Attributes: Digest-Response (206) = "6303c41b0e2c3e524e413cafe8cce954" B->A SIP/2.0 180 Ringing Via: SIP/2.0/UDP 213.137.67.67:5061 From: ;tag=29e97f To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E Date: Tue, 25 Jan 2000 03:41:00 gmt Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 Server: Cisco-SIPGateway/IOS-12.x Record-Route: CSeq: 2544266 INVITE Content-Length: 0 B->A SIP/2.0 200 OK Via: SIP/2.0/UDP 213.137.67.67:5061 From: ;tag=29e97f To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E Sterman, et al. Expires November 30, 2004 [Page 27] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Date: Tue, 25 Jan 2000 03:41:00 gmt Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 Authentication-Info: nextnonce="ef0189c5", rspauth="6303c41b0e2c3e524e413cafe8cce954" Server: Cisco-SIPGateway/IOS-12.x Record-Route: CSeq: 2544266 INVITE Contact: Content-Type: application/sdp Content-Length: 158 v=0 o=CiscoSystemsSIP-GW-UserAgent 1901 5895 IN IP4 213.137.69.36 s=SIP Call c=IN IP4 213.137.69.36 t=0 0 m=audio 17724 RTP/AVP 0 a=rtpmap:0 PCMU/8000 A->B ACK sip:97226491335@213.137.69.38:5060 SIP/2.0 Via: SIP/2.0/UDP 213.137.67.67:5061 From: ;tag=29e97f To: sip:97226491335@213.137.69.38;tag=7BF5248C-177E Call-ID: b0f487c9-04a0-4108-a5a3-580ecbaf0e24@213.137.67.67 CSeq: 2544266 ACK Content-Length: 0 Route: Sterman, et al. Expires November 30, 2004 [Page 28] Internet-Draft RADIUS Extension for Digest Authentication June 2004 8. Changes from -02 o Relaxed restrictions for DIG-DOMAIN, DIG-REALM, DIG-OPAQUE, DIG-QOP and DIG-ALG o Additional security considerations for DIG-DOMAIN, DIG-QOP and DIG-ALG usage in Access-Accept messages Sterman, et al. Expires November 30, 2004 [Page 29] Internet-Draft RADIUS Extension for Digest Authentication June 2004 9. Changes from -01 o Replaced Sub-attributes with flat attributes o aligned naming with [I-D.ietf-aaa-diameter-sip-app] o Added how a server must treat unknown attributes. o Added a section 'Migration path to DIAMETER' o Added an optional attribute for support of the digest scheme described in informational [RFC3310]. o Added a mode of operation where the RADIUS server chooses the nonce. This was required for AKA [RFC3310], but can be useful for ordinary Digest authentication when the qop directive is not used. This required the addition of several attributes. Sterman, et al. Expires November 30, 2004 [Page 30] Internet-Draft RADIUS Extension for Digest Authentication June 2004 10. References 10.1 Normative References [I-D.ietf-aaa-diameter-sip-app] Garcia-Martin, M., "Diameter Session Initiation Protocol (SIP) Application", draft-ietf-aaa-diameter-sip-app-02 (work in progress), April 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 10.2 Informative References [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [RFC3310] Niemi, A., Arkko, J. and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. Sterman, et al. Expires November 30, 2004 [Page 31] Internet-Draft RADIUS Extension for Digest Authentication June 2004 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Authors' Addresses Baruch Sterman Kayote Networks P.O. Box 1373 Efrat 90435 Israel EMail: baruch@kayote.com Daniel Sadolevsky SecureOL, Inc. Jerusalem Technology Park P.O. Box 16120 Jerusalem 91160 Israel EMail: dscreat@dscreat.com David Schwartz Kayote Networks P.O. Box 1373 Efrat 90435 Israel EMail: david@kayote.com David Williams Cisco Systems 7025 Kit Creek Road P.O. Box 14987 Research Triangle Park NC 27709 USA EMail: dwilli@cisco.com Sterman, et al. Expires November 30, 2004 [Page 32] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Wolfgang Beck Deutsche Telekom AG Am Kavalleriesand 3 Darmstadt 64295 Germany EMail: beckw@t-systems.com Sterman, et al. Expires November 30, 2004 [Page 33] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Appendix A. Acknowledgements We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or providing comments and experimental implementation. Sterman, et al. Expires November 30, 2004 [Page 34] Internet-Draft RADIUS Extension for Digest Authentication June 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sterman, et al. Expires November 30, 2004 [Page 35]