[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Another review of draft-ietf-radext-digest-auth06.txt (fwd)
---------- Forwarded message ----------
Date: Wed, 14 Dec 2005 14:04:20 -0800
From: Kurt D. Zeilenga <Kurt@openldap.org>
To: Sam Hartman <hartmans-ietf@mit.edu>
Cc: david@kayote.com, david.kessens@nokia.com, beckw@t-systems.com,
dscreat@dscreat.com, secdir@mit.edu, baruch@kayote.com, dwilli@cisco.com
Subject: Re: [secdir]Re: Review request:
draft-ietf-radext-digest-auth06.txt
Sam, the following is my SecDir review of this draft. -- Kurt
Overall, I believe the document with some changes is generally
suitable for publication on the Standards Track. I believe
some changes are necessary to clarify handling of digest-uri
and fixing the first example in section 7. In this example,
the "Proxy Server" modifies the URI. This would cause a different
and incorrect A2 to be produced by the RADIUS server, and hence
cause the authentication to fail. I suspect a typo in the example.
I do note that RFC 2617 does allow proxies to provide a different
URI than the HTTP client's request URI, but the assumption here
is that its modifying the HTTP request URI and not the value of
the digest-uri parameter. Aside from fixing the example, I
suggest the document be more clear as to which Digest values,
including but not limited to digest-uri, can be modified by
the proxy and which must be preserved as presented by the
client/server.
Aside from this, I found a number of editorial and other relatively
minor issues, such as inconsistent use of the term "protection
space", which should be address prior to the document's
progression. Attached are my raw review notes.
There is no digest-uri discussion. RFC 2617 allows proxies
to modify the digest-uri. Is the RADIUS client allowed
to modify the digest-uri? I would assume not as the
digest-uri is used in computing A2. However, in the
first example, the RADIUS client changes the URI.
>Network Working Group B. Sterman
>Internet-Draft Kayote Networks
>Expires: April 17, 2006 D. Sadolevsky
> SecureOL, Inc.
> D. Schwartz
> Kayote Networks
> D. Williams
> Cisco Systems
> W. Beck
> Deutsche Telekom AG
> October 14, 2005
>
>
> RADIUS Extension for Digest Authentication
> draft-ietf-radext-digest-auth-06.txt
>
>
>Abstract
>
> This document defines an extension to the RADIUS protocol to enable
> support of Digest Authentication, for use with HTTP-style protocols
> like SIP and HTTP.
Acronyms, especially RADIUS and SIP, should be spelled out on
first use in the abstract.
>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].
>
> The use of normative requirement key words in this document shall
> apply only to RADIUS Client and RADIUS Server implementations that
> include the features described in this document. This document
> creates no normative requirements for existing implementations.
>
> HTTP-style protocol
> 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.
> NAS
> Network Access Server, the RADIUS client.
> nonce
> An unpredictable value used to prevent replay attacks. The
> nonce generator may use cryptographic mechanisms to produce
> nonces it can recognize without maintaining state.
> protection space
> The combination of realm and digest URI, the use of which is
> authorized by the RADIUS server.
This definition seems only consistent with RFC2617 if the digest
URI holds a canonical root URL. See Section 1.1 of RFC 2617.
> SIP UA
> SIP User Agent, an Internet endpoint that uses the Session
> Initiation Protocol.
> SIP UAS
> SIP User Agent Server, a logical entity that generates a
> response to a SIP (Session Initiation Protocol) request.
Note that while SIP is spelled out in the last use above, this
is not the first use in the body. Other acyronyms should also be
spelled out on first use in body.
>1.2. Motivation
>
> The HTTP Digest Authentication mechanism, defined in [RFC2617], was
> subsequently adapted to use with SIP in [RFC2543] (obsoleted by
> [RFC3261]). Due to the limitations and weaknesses of Digest
> Authentication (see [RFC2617], section 4), additional authentication
> and encryption mechanisms are defined in SIP [RFC3261], including TLS
> [RFC2246] and S/MIME [RFC2633]. However, Digest Authentication has
> been widely implemented within SIP clients and to support those
> clients there is a need for support of Digest Authentication within
> AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588].
>
> This document defines an extension to the RADIUS protocol to enable
> support of Digest Authentication, for use with SIP, HTTP, and other
> HTTP-style protocols using this authentication method. Support for
> Digest mechanisms such as AKA [RFC3310] is also supported. A
> companion document [I-D.ietf-aaa-diameter-sip-app] defines support
> for Digest Authentication within Diameter.
>
>1.3. Overview
>
> HTTP digest is a challenge-response protocol used to authenticate a
> client's request to access some resource on a server. Figure 1 shows
> a single HTTP digest transaction.
>
>
>
> HTTP/SIP..
> +------------+ (1) +------------+
> | |--------->| |
> | HTTP-style | (2) | HTTP-style |
> | Client |<---------| server |
> | | (3) | |
> | |--------->| |
> | | (4) | |
> | |<---------| |
> +------------+ +------------+
>
>
>
>
> Figure 1: digest operation without RADIUS
>
> If the client sends a request without any credentials (1), the server
> will reply with an error response (2) containing a nonce. The client
> creates a cryptographic digest from parts of the request, from the
> nonce it received from the server, and a shared secret. The client
> re-transmits the request (3) to the server, but now includes the
> digest within the packet. The server does the same digest
> calculation as the client and compares the result with the digest it
> received in (3). If the digest values are identical, the server
> grants access to the resource and sends a positive response to the
> client (4). If the digest values differ, the server sends a negative
> response to the client (4).
>
> Instead of maintaining a local user database, the server could use
> RADIUS to access a centralized user database. However, RADIUS
> [RFC2865] does not include support for HTTP digest authentication.
> The RADIUS client can not use the User-Password attribute, since it
> does not receive a password from the HTTP-style client. The CHAP-
> Challenge and CHAP-Password attributes are also not suitable since
> the CHAP algorithm is not compatible with HTTP digest.
Informative reference for CHAP?
> This document defines new attributes that enable the RADIUS server to
> perform the digest calculation defined in [RFC2617], providing
> support for Digest Authentication as a native authentication
> mechanism within RADIUS.
>
> This document defines new attributes that enable the RADIUS server to
> perform the digest calculation defined in [RFC2617].
>
> The nonces required by the digest algorithm are either generated by
> the RADIUS client or by the RADIUS server. A mix of nonce generation
> modes is not supported. This specification assumes that both the
> RADIUS client and server are appropriately configured to generate the
> nonces in either the RADIUS client or the RADIUS server, but not in
> both at the same time. Implementations, though, do not have the
> means to verify this behavior.
>
>1.3.1. Scenario 1, RADIUS client chooses nonces
>
>
> HTTP/SIP RADIUS
>
> +-----+ (1) +-----+ +-----+
> | |==========>| | | |
> | | (2) | | | |
> | |<==========| | | |
> | | (3) | | | |
> | |==========>| | | |
> | A | | B | (4) | C |
> | | | |---------->| |
> | | | | (5) | |
> | | | |<----------| |
> | | (6) | | | |
> | |<==========| | | |
> +-----+ +-----+ +-----+
>
> ====> HTTP/SIP
> ----> RADIUS
>
>
>
> Figure 2: RADIUS client 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 (RADIUS client)
>
> 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 challenges A sending an HTTP/SIP "407 / 401 (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 "407 / 401 (Proxy) Authorization
> required" response (step 6).
>
>1.3.2. Scenario 2, RADIUS server chooses nonces
>
> While the usage scenario described in Section 1.3.1 minimizes the
> load on the RADIUS server, alternatives are required in some
> situations. When using AKA [RFC3310] the nonce is partially derived
> from a precomputed authentication vector, which is often stored
> centrally.
>
> Figure 3 depicts a scenario in which the RADIUS server chooses
> nonces. In this case entities A and B communicate using HTTP or SIP,
> while entities B and C communicate using RADIUS."
Extraneous " ?
>
>
> HTTP/SIP RADIUS
>
> +-----+ (1) +-----+ +-----+
> | |==========>| | (2) | |
> | | | |---------->| |
> | | | | (3) | |
> | | (4) | |<----------| |
> | |<==========| | | |
> | | (5) | | | |
> | |==========>| | | |
> | A | | B | (6) | C |
> | | | |---------->| |
> | | | | (7) | |
> | | | |<----------| |
> | | (8) | | | |
> | |<==========| | | |
> +-----+ +-----+ +-----+
>
> ====> HTTP/SIP
> ----> RADIUS
>
>
>
> Figure 3: 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 following messages are sent in this scenario:
>
> A sends B an HTTP/SIP request without an authorization header (step
> 1). B sends an Access-Request packet 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-Challenge (step 3). This Access-Challenge contains
> Digest attributes, from which B takes values to construct an HTTP/SIP
> "(Proxy) Authorization required" response. The remaining steps are
> identical with scenario 1 (Section 1.3.1): 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)
> Authorization required" response (step 8).
>
>
>2. Interoperability
>
> An implementation supporting this extension MUST include a Digest-
> Response attribute within an Access-Request packet where Digest
> Authentication is desired. An Access-Request MUST NOT contain both a
> Digest-Response attribute and another authentication attribute, such
> as User-Password, CHAP-Password, or EAP-Message.
>
> RADIUS clients and servers MUST support both nonce generation modes.
> As there is no automatic capability exchange, the operator MUST make
> sure that the RADIUS client software uses the correct nonce
> generation mode when accessing a specific RADIUS server:
The above MUST does not apply to an implementation, but to a user,
which seems counter to proper RFC 2119 usage.
> o If the RADIUS server generates nonces, its RADIUS clients MUST NOT
> try to generate nonces.
> o If the RADIUS server does not generate nonces, its RADIUS clients
> MUST generate nonces locally.
> o If at least one HTTP-style client requires AKA authentication
> [RFC3310], the RADIUS server MUST generate nonces and its RADIUS
> clients MUST NOT generate nonces locally.
> RADIUS implementations MUST offer respective configuration options.
>
>
>3. Detailed Description
>
>3.1. RADIUS Client Behavior
>
> The attributes described in this document are sent in cleartext.
> Therefore were a RADIUS client to accept secured connections (https
> or sips) from HTTP-style clients, this could result in information
> intentionally protected by HTTP-style clients being sent in the clear
> during the RADIUS exchange.
>
> On reception of an HTTP-style request message, the RADIUS client
> checks whether it is authorized to authenticate the request. Where
> an HTTP-style request traverses several proxies and each of the
> proxies requests to authenticate the HTTP-style client, the request
> at the HTTP-style server may contain multiple credential sets.
>
> The RADIUS client can use the 'realm' directive in HTTP to determine
> which credentials are applicable. Where none of the realms are of
> interest, the RADIUS client MUST behave as though no relevant
> credentials were sent. In all situations the RADIUS client MUST send
> zero or exactly one credential to the RADIUS server. The RADIUS
> client MUST choose the credential of the (Proxy-)Authorization header
> if the realm directive matches its locally configured realm.
>
> If such a (Proxy-)Authorization header is present and contains HTTP
> digest information, the RADIUS client checks the 'nonce' parameter.
> If the RADIUS client generates nonces but did not issue the received
> nonce, 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 or does not generate
> nonces, it takes the header directives and puts them into a RADIUS
> Access-Request packet. It puts the 'response' directive into a
> Digest-Response attribute and the realm / nonce / digest-uri / qop /
> algorithm / cnonce / nc / username / opaque directives into the
What is '/' above used to signify? In ABNF, / character separates choices.
I assume each of these directives are actually required, seems using
a comma as a separator would be more appropriate for this prose.
Likewise below.
> respective Digest-Realm / Digest-Nonce / Digest-URI / Digest-Qop /
> Digest-Algorithm / Digest-CNonce / Digest-Nonce-Count / Digest-
> Username / Digest-Opaque attributes. The request method is put into
> the Digest-Method attribute. The RADIUS client adds a Message-
> Authenticator attribute, defined in [RFC3579] and sends the Access-
> Request packet to the RADIUS server.
>
> The RADIUS server processes the packet and responds with an Access-
> Accept or an Access-Reject.
>
> The RADIUS client constructs an Authentication-Info header:
> o If the Access-Accept packet contains a Digest-Response-Auth
> attribute, the RADIUS client checks the Digest-Qop attribute:
> * If the Digest-Qop attribute's value is 'auth' or not specified,
> the RADIUS client puts the Digest-Response-Auth attribute's
> content into the Authentication-Info header's 'rspauth'
> directive of the HTTP-style response.
> * If the Digest-Qop attribute's value is 'auth-int', the RADIUS
> client ignores the Access-Accept packet and behaves like it had
> received an Access-Reject packet (Digest-Response-Auth can't be
> correct as the RADIUS server does not know the contents of the
> HTTP-style response's body).
> o If the Access-Accept packet contains a Digest-HA1 attribute, the
> RADIUS client checks the 'qop' and 'algorithm' directives in the
> Authorization header of the HTTP-style request it wants to
> authorize:
> * If the 'qop' directive is missing or its value is 'auth', the
> RADIUS client ignores the Digest-HA1 attribute. It does not
> include an Authentication-Info header into its HTTP-style
> response.
> * If the 'qop' directive's value is 'auth-int' and at least one
> of the following conditions is true, the RADIUS client
> calculates the contents of the HTTP-style response's 'rspauth'
> directive:
> + The algorithm directive's value is 'MD5-sess' or 'AKAv1-MD5-
> sess'.
> + The packets between RADIUS client and RADIUS server are
> protected with IPsec (see Section 9).
> It creates the HTTP-style response message and calculates the
> hash of this message's body. It uses the result and the
> Digest-URI attribute's value of the corresponding Access-
> Request packet to perform the H(A2) calculation. It takes the
> Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and Digest-Qop
> values of the corresponding Access-Request and the Digest-HA1
> attribute's value to finish the computation of the 'rspauth'
> value.
> o If the Access-Accept packet contains neither a Digest-Response-
> Auth nor a Digest-HA1 attribute, the RADIUS client will not create
> an Authentication-Info header for its HTTP-style response.
>
> The RADIUS server MAY have added a Digest-Nextnonce attribute into an
> Access-Accept packet. If the RADIUS client discovers this, it puts
> the contents of this attribute into a 'nextnonce' directive. Now it
> can send an HTTP-style response.
The use of MAY here seems odd. The actual OPTIONAL behavior of
the RADIUS server is discussed elsewhere. This could more simply be
worded:
When the RADIUS server provides a Digest-Nextnonce attribute
in the Access-Accept packet, the RADIUS client puts the
contexts of this attributes into a 'nextnonce' directive.
Now it can send an HTTP-style response.
> If the RADIUS client did receive an HTTP-style request without a
> (Proxy-)Authorization header matching its locally configured realm
> value, 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 from the RADIUS
> server, it sends an error response to the HTTP-style request it has
> received. If the RADIUS client does not receive a response, it
> retransmits or fails over to another RADIUS server as described in
> [RFC2865].
>
> The RADIUS client has three ways to obtain nonces: it generates them
> locally, it has received one in a Digest-Nextnonce attribute of a
> previously received Access-Accept packet, 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. It adds a Message-Authenticator (see
> [RFC3579]) attribute to the Access-Request packet. The RADIUS server
> chooses a nonce and responds with an Access-Challenge containing a
> Digest-Nonce attribute.
>
> The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest-
> Realm, Digest-Domain and Digest-Opaque attributes in the Access-
> Challenge carrying the nonce. If these attributes are present, the
> client MUST use them.
>
> If the RADIUS client receives an Access-Challenge packet in response
> to an Access-Request containing a Digest-Nonce attribute, the RADIUS
> server did not accept the nonce. If a Digest-Stale attribute is
> present in the Access-Challenge and has a value of 'true' (without
> quotes), the RADIUS client sends an error (401 or 407) response
> containing WWW-/Proxy-Authenticate header with the directive 'stale'
> and the digest directives derived from the Digest-* attributes.
>
>3.2. RADIUS Server Behavior
>
> If the RADIUS server receives an Access-Request packet 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-Challenge packet to the RADIUS
> client. The RADIUS server MUST add Digest-Realm, Message-
> Authenticator (see [RFC3579]), SHOULD add Digest-Algorithm, one or
> more Digest-Qop and MAY add Digest-Domain, Digest-Opaque attributes
> to the Access-Challenge packet. If the server cannot choose a nonce,
> it replies with an Access-Reject packet.
>
> If the RADIUS server receives an Access-Request packet 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-Entity-Body-
> Hash, Digest-CNonce and Digest-AKA-Auts, too. See [RFC2617] and
> [RFC3310] for details. If the Digest-Algorithm attribute is missing,
> 'MD5' is assumed. If the RADIUS server has issued a Digest-Opaque
> attribute along with the nonce, the Access-Request MUST have a
> matching Digest-Opaque attribute.
>
> If mandatory attributes are missing, it MUST respond with an Access-
> Reject packet. 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.
> The RADIUS server MUST check if the user identified by the User-Name
> attribute
> o is authorized to access the protection space defined by the
> Digest-URI and Digest-Realm attributes,
> o is authorized to use the URI included in the SIP-AOR attribute, if
> this attribute is present.
> If any of those checks fails, the RADIUS server MUST send an Access-
> Reject.
>
> Correlation between User-Name and SIP-AOR AVP values is required just
> to avoid that any user can register or misuse a SIP-AOR allocated to
> another user.
>
> A RADIUS server MUST check if the RADIUS client is authorized to
> serve users of the realm mentioned in the Digest-Realm attribute. If
> the RADIUS client is not authorized, the RADIUS server MUST send an
> Access-Reject. The RADIUS server SHOULD log the event so as to
> notify the operator, and MAY take additional action such as sending
> an Access-Reject in response to all future requests from this client,
> until this behavior is reset by management action.
>
> All values required for the digest calculation are taken from the
> Digest attributes described in this document. If the calculated
> digest response equals the value received in the Digest-Response
> attribute, the authentication was successful. If not, the RADIUS
> server responds with an Access-Reject.
>
> If the authentication was successful, the RADIUS server adds an
> attribute to the Access-Accept packet which can be used by the RADIUS
> client to construct an Authentication-Info header:
> o If the Digest-Qop attribute's value is 'auth' or unspecified, the
> RADIUS server SHOULD put a Digest-Response-Auth attribute into the
> Access-Accept packet
> o If the Digest-Qop attribute's value is 'auth-int' and at least one
> of the following conditions is true, the RADIUS server SHOULD put
> a Digest-HA1 attribute into the Access-Accept packet:
> * The Digest-Algorithm attribute's value is 'MD5-sess' or 'AKAv1-
> MD5-sess'.
> * The packets between RADIUS client and RADIUS server are
> protected with IPsec (see Section 9).
> In all other cases, Digest-Response-Auth or Digest-HA1 MUST NOT be
> sent.
>
> RADIUS servers issuing nonces MAY construct a Digest-Nextnonce
> attribute and add it to the Access-Accept packet. 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
> RADIUS server adds a Message-Authenticator attribute (see [RFC3579])
> and sends the Access-Accept packet to the RADIUS client.
>
> If the RADIUS server does not accept the nonce received in an Access-
> Request packet but authentication was successful, the RADIUS server
> MUST send an Access-Challenge packet containing a Digest-Stale
> attribute set to 'true' (without quotes). The RADIUS server MUST add
> Message-Authenticator (see [RFC3579]), Digest-Nonce, Digest-Realm,
> SHOULD add Digest-Algorithm, one or more Digest-Qop and MAY add
> Digest-Domain, Digest-Opaque attributes to the Access-Challenge
> packet.
>
>
>4. New RADIUS attributes
>
> If not stated otherwise, the attributes have the following format:
>
>
> 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 | Text ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>4.1. Digest-Response attribute
>
> Description
> If this attribute is present in an Access-Request message, a
> RADIUS server implementing this specification MUST treat the
> Access-Request as a request for Digest Authentication. When a
> RADIUS client receives a (Proxy-)Authorization header, it puts
> the request-digest value into a Digest-Response attribute.
> This attribute (which enables the user to prove possession of
> the password) MUST only be used in Access-Requests.
> Type
> [IANA: use 102 if possible] for Digest-Response.
> Length
> >= 3
> Text
> When using HTTP digest, the text field is 32 octets long and
> contains a hexadecimal representation of 16 octet digest value
> as it was calculated by the authenticated client. Other digest
> algorithms MAY define different digest lengths. The text field
> MUST be copied from request-digest of digest-response
> ([RFC2617]) without quotes.
>
>4.2. Digest-Realm attribute
>
> Description
> This attribute describes a protection space of the RADIUS
> server. See [RFC2617] 1.2 for details. It MUST only be used
> in Access-Request and Access-Challenge packets.
Per the definion in section 1,
The combination of realm and digest URI, the use of which is
authorized by the RADIUS server.
But this says this attribute, just a Realm, describes a protection
space.
> Type
> [IANA: use 103 if possible] for Digest-Realm
> Length
> >=3
> Text
> In Access-Requests, the RADIUS client takes the value of the
> realm directive (realm-value according to [RFC2617]) without
> quotes from the HTTP-style request it wants to authenticate.
> In Access-Challenge packets, the RADIUS server puts the
> expected realm value into this attribute.
>
>4.3. Digest-Nonce attribute
>
> Description
> This attribute holds a nonce to be used in the HTTP Digest
> calculation. 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-Challenge packet. This attribute
> MUST only be used in Access-Request and Access-Challenge
> packets.
> Type
> [IANA: use 104 if possible] for Digest-Nonce
> Length
> >=3
> Text
> In Access-Requests, the RADIUS client takes the value of the
> nonce directive (nonce-value in [RFC2617]) without quotes from
> the HTTP-style request it wants to authenticate. In Access-
> Challenge packets, the attribute contains the nonce selected by
> the RADIUS server.
>
>4.4. Digest-Response-Auth attribute
>
> Description
> This attribute enables the RADIUS server to prove possession of
> the password. If the previously received Digest-Qop attribute
> was 'auth-int' (without quotes), the RADIUS server MUST send a
> Digest-HA1 attribute instead of a Digest-Response-Auth
> attribute. The Digest-Response-Auth attribute MUST only be
> used in Access-Accept packets. The RADIUS client puts the
> attribute value without quotes into the rspauth directive of
> the Authentication-Info header.
> Type
> [IANA: use 105 if possible] for Digest-Response-Auth.
> Length
> >= 3
> Text
> The RADIUS server calculates a digest according to section
> 3.2.3 of [RFC2617] and copies the result into this attribute.
> Other digest algorithms than the one defined in [RFC2617] MAY
> define digest lengths other than 32.
>
>4.5. Digest-Nextnonce attribute
>
> This attribute holds a nonce to be used in the HTTP Digest
> calculation.
>
> Description
> If the RADIUS server is configured to choose nonces it MAY put
> a Digest-Nextnonce attribute into an Access-Accept packet. If
> this attribute is present, the RADIUS client MUST put the
> contents of this attribute into the nextnonce directive of an
> Authentication-Info header in its HTTP-style response. This
> attribute MUST only be used in Access-Accept packets.
> Type
> [IANA: use 106 if possible] for Digest-Nextnonce
> Length
> >=3
> Text
> It is recommended that this text be base64 or hexadecimal data.
>
>4.6. Digest-Method attribute
>
> Description
> This attribute holds the method value to be used in the HTTP
> Digest calculation. This attribute MUST only be used in
> Access-Request packets.
> Type
> [IANA: use 107 if possible] for Digest-Method
> Length
> >=3
> Text
> In Access-Requests, the RADIUS client takes the value of the
> request method from the HTTP-style request it wants to
> authenticate.
>
>4.7. Digest-URI attribute
>
> Description
> This attribute is used to transport the contents of the digest-
> uri directive or the URI of the HTTP-style request. It MUST
> only be used in Access-Request packets.
> Type
> [IANA: use 108 if possible] for Digest-URI
> Length
> >=3
> Text
> If the HTTP-style request has an Authorization header, the
> RADIUS client puts the value of the "uri" directive in the
> (known as "digest-uri-value" in section 3.2.2 of [RFC2617])
> without quotes into this attribute.
This text implies the client is to remove any quote characters
appearing in the URI. Suggest:
s/without quotes/without quoting/
> If there is no
> Authorization header, the RADIUS client takes the value of the
> request URI from the HTTP-style request it wants to
> authenticate.
>
>4.8. Digest-Qop attribute
>
> Description
> This attribute holds the Quality of Protection parameter that
> influences the HTTP Digest calculation. This attribute MUST
> only be used in Access-Request and Access-Challenge packets. A
> RADIUS client SHOULD insert one of the Digest-Qop attributes it
> has received in a previous Access-Challenge packet. RADIUS
> servers SHOULD insert at least one Digest-Qop attribute in an
> Access-Challenge packet. Digest-Qop is optional in order to
> preserve backward compatibility with a minimal implementation
> of [RFC2069].
> Type
> [IANA: use 109 if possible] for Digest-Qop
> Length
> >=3
> Text
> In Access-Requests, the RADIUS client takes the value of the
> qop directive (qop-value as described in [RFC2617]) without the
> quotes from the HTTP-style request it wants to authenticate.
> In Access-Challenge packets, the RADIUS server puts a desired
> qop-value into this attribute. If the RADIUS server supports
> more than one "quality of protection" value, it puts each qop-
> value into a separate Digest-Qop attribute.
>
>4.9. Digest-Algorithm attribute
>
> Type
s/Type/Description/
> This attribute holds the algorithm parameter that influences
> the HTTP Digest calculation. It MUST only be used in Access-
> Request and Access-Challenge packets. If this attribute is
> missing, "MD5" is assumed.
>
> Type
> [IANA: use 110 if possible] for Digest-Algorithm
> Length
> >=3
> Text
> In Access-Requests, the RADIUS client takes the value of the
> algorithm directive (as described in [RFC2617], section 3.2.1)
> without the quotes from the HTTP-style request it wants to
> authenticate. In Access-Challenge packets, the RADIUS server
> SHOULD put the desired algorithm into this attribute.
>
>4.10. Digest-Entity-Body-Hash attribute
>
> Description
> When using the qop level 'auth-int', a hash of the HTTP-style
> message body's contents is 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.
> The clarifications described in section 22.4 of [RFC2617] about
> the hash of empty entity bodies apply to the Digest-Entity-
> Body-Hash attribute. This attribute MUST only be sent in
> Access-Request packets.
> Type
> [IANA: use 111 if possible] for Digest-Entity-Body-Hash
> Length
> >=3
> Text
> The attribute holds the hexadecimal representation of H(entity-
> body). This hash is required by certain authentication
> mechanisms, such as HTTP Digest with quality of protection set
> to "auth-int". RADIUS clients MUST use this attribute to
> transport the hash of the entity body when HTTP Digest is the
> authentication mechanism and the RADIUS server requires to
> verify the integrity of the entity body (e.g., qop parameter
> set to "auth-int"). Extensions to this document may define
> support for authentication mechanisms other than HTTP Digest.
>
>4.11. Digest-CNonce attribute
>
> Description
> This attribute holds the client nonce parameter that is used in
> the HTTP Digest calculation. It MUST only be used in Access-
> Request packets.
> Type
> [IANA: use 112 if possible] for Digest-CNonce
> Length
> >=3
> Text
> This attribute includes the value of the cnonce-value [RFC2617]
> without quotes, taken from the HTTP-style request.
>
>4.12. Digest-Nonce-Count attribute
>
> Description
> This attribute includes the nonce count parameter that is used
> to detect replay attacks. The attribute MUST only be used in
> Access-Request packets.
> Type
> [IANA: use 113 if possible] for Digest-Nonce-Count
> Length
> 10
> Text
> In Access-Requests, the RADIUS client takes the value of the nc
> directive (nc-value according to [RFC2617]) without quotes from
> the HTTP-style request it wants to authenticate.
>
>4.13. Digest-Username attribute
>
> Description
> This attribute holds the user name used in the HTTP digest
> calculation. The RADIUS server MUST use this attribute only
> for the purposes of calculating the digest. In order to
> determine the appropriate user credentials, the RADIUS server
> MUST use the User-Name (1) attribute, and MUST NOT use the
> Digest-Username attribute. This attribute MUST only be used in
> Access-Request packets.
> Type
> [IANA: use 114 if possible] for Digest-Username
> Length
> >= 3
> Text
> In Access-Requests, the RADIUS client takes the value of the
> username directive (username-value according to [RFC2617])
> without quotes from the HTTP-style request it wants to
> authenticate.
>
>4.14. Digest-Opaque attribute
>
> Description
> This attribute holds the opaque parameter that is passed to the
> HTTP-style client. The HTTP-style client will pass this value
> back to the server (i.e. the RADIUS client) without
> modification. This attribute is only used when the RADIUS
> server chooses nonces and MUST only be used in Access-Request
> and Access-Challenge packets.
> Type
> [IANA: use 115 if possible] for Digest-Opaque
> Length
> >=3
> Text
> In Access-Requests, the RADIUS client takes the value of the
> opaque directive (opaque-value according to [RFC2617]) without
> quotes from the HTTP-style request it wants to authenticate and
> puts it into this attribute. In Access-Challenge packets, the
> RADIUS server MAY include this attribute.
>
>4.15. Digest-Auth-Param attribute
>
> Description
> This attribute is a placeholder for future extensions and
> corresponds to the "auth-param" parameter defined in section
> 3.2.1 of [RFC2617]. The Digest-Auth-Param is the mechanism
> whereby the RADIUS client and RADIUS server can exchange auth-
> param extension parameters contained within Digest headers that
> are not understood by the RADIUS client and for which there are
> no corresponding stand-alone attributes.
> Unlike the previously listed Digest-* attributes, the Digest-
> Auth-Param contains not only the value, but also the parameter
> name, since the parameter name is unknown to the RADIUS client.
> If the Digest header contains several unknown parameters, then
> the RADIUS implementation MUST repeat this attribute and each
> instance MUST contain one different unknown Digest parameter/
> value combination. This attribute MUST ONLY be used in Access-
> Request, Access-Challenge, or Access-Accept packets.
> Type
> [IANA: use 116 if possible] for Digest-Auth-Param
> Length
> >=3
> Text
> The text consists of the whole parameter, including its name
> and the equal ('=') sign and quotes.
>
>4.16. Digest-AKA-Auts attribute
>
> Description
> This attribute holds the auts parameter that is used in the
> Digest AKA ([RFC3310]) calculation. It is only used if the
> algorithm of the digest-response denotes a version of AKA
> digest [RFC3310]. This attribute MUST only be used in Access-
> Request packets.
> Type
> [IANA: use 117 if possible] for Digest-AKA-Auts
> Length
> >=3
> Text
> In Access-Requests, the RADIUS client takes the value of the
> auts directive (auts-param according to section 3.4 of
> [RFC3310]) without quotes from the HTTP-style request it wants
> to authenticate.
>
>4.17. Digest-Domain attribute
>
> Description
> When a RADIUS client has asked for a nonce, the RADIUS server
> MAY send one or more Digest-Domain attributes in its Access-
> Challenge packet. 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). RADIUS
> servers MAY send one or more attributes of this type in Access-
> Challenge packets. This attribute MUST only be used in Access-
> Challenge packets.
> Type
> [IANA: use 118 if possible] for Digest-Domain
> Length
> 3
> Text
> This attribute consists of a single URI, that defines a
> protection space.
>
>4.18. Digest-Stale attribute
>
> Description
> This attribute is sent by a RADIUS server in order to notify
> the RADIUS client whether it has accepted a nonce. If the
> nonce presented by the RADIUS client was stale, the value is
> 'true' and is 'false' otherwise. The RADIUS client puts the
> content of this attribute into a 'stale' directive of the WWW-
> Authenticate header in the HTTP-style response to the request
> it wants to authenticate. The attribute MUST only be used in
> Access-Challenge packets and only if the RADIUS server chooses
> nonces.
> Type
> [IANA: use 119 if possible] for Digest-Stale
> Length
> 3
> Text
> The attribute has either the value 'true' or 'false' (both
> values without quotes).
>
>4.19. Digest-HA1 attribute
>
> Description
> This attribute is used to allow the generation of an
> Authentication-Info header, even if the HTTP-style response's
> body is required for the calculation of the rspauth value. It
> SHOULD be used in Access-Accept packets if the required quality
> of protection ('qop') is 'auth-int'.
> This attribute MUST NOT be sent if the qop parameter was not
> specified or has a value of 'auth' (in this case, use Digest-
> Response-Auth instead).
> The Digest-HA1 attribute MUST only be sent by the RADIUS server
> or processed by the RADIUS client if at least one of the
> following conditions is true:
> + The Digest-Algorithm attribute's value is 'MD5-sess' or
> 'AKAv1-MD5-sess'.
> + The packets between RADIUS client and RADIUS server are
> protected with IPsec (see Section 9).
> This attribute MUST only be used in Access-Accept packets.
> Type
> [IANA: use 120 if possible] for Digest-HA1
> Length
> >= 3
> Text
> This attribute contains the hexadecimal representation of H(A1)
> as described in [RFC2617], section 3.1.3, 3.2.1 and 3.2.2.2.
>
>4.20. SIP-AOR
>
> Type
s/Type/Description/
> This attribute is used for the authorization of SIP messages.
> The SIP-AOR attribute identifies the URI the use of which must
> be authenticated and authorized. The RADIUS server uses this
> attribute to authorize the processing of the SIP request. The
> SIP-AOR can be derived from, e.g., the To header field in a SIP
> REGISTER request (user under registration), or the From header
> field in other SIP requests. However, the exact mapping of
> this attribute to SIP can change due to new developments in the
> protocol. This attribute MUST only be used when the RADIUS
> client wants to authorize SIP users and MUST only be used in
> Access-Request packets.
> Type
> [IANA:use 121 if possible] for SIP-AOR
> Length
> >=3
> Text
> The syntax of this attribute corresponds either to a SIP URI
> (with the format defined in [RFC3261] or a TEL URI (with the
> format defined in [RFC3966]).
> The SIP-AOR attribute holds the complete URI, including
> parameters and other parts. It is up to the RADIUS server what
> components of the URI are regarded in the authorization
> decision.
>
>
>5. Diameter Compatibility
>
> This document defines support for Digest Authentication in RADIUS. A
> companion document "Diameter Session Initiation Protocol (SIP)
> Application" [I-D.ietf-aaa-diameter-sip-app] defines support for
> Digest Authentication in Diameter, and addresses compatibility issues
> between RADIUS and Diameter.
>
>
>6. Table of Attributes
>
> The following table provides a guide to which attributes may be found
> in which kinds of packets, and in what quantity.
>
> Req Accept Reject Challenge # Attribute
> 1 0 0 0 1 User-Name
> 1 1 1 1 80 Message-Authenticator
> 0-1 0 0 0 TBD Digest-Response
> 0-1 0 0 1 TBD Digest-Realm
> 0-1 0 0 1 TBD Digest-Nonce
> 0 0-1 0 0 TBD Digest-Response-Auth
> (see Note 1, 2)
> 0 0-1 0 0 TBD Digest-Nextnonce
> 0-1 0 0 0 TBD Digest-Method
> 0-1 0 0 0 TBD Digest-URI
> 0-1 0 0 1+ TBD Digest-Qop
> 0-1 0 0 0-1 TBD Digest-Algorithm (see
> Note 3)
> 0-1 0 0 0 TBD Digest-Entity-Body-Hash
> 0-1 0 0 0 TBD Digest-CNonce
> 0-1 0 0 0 TBD Digest-Nonce-Count
> 0-1 0 0 0 TBD Digest-Username
> 0-1 0 0 0-1 TBD Digest-Opaque
> 0+ 0+ 0 0+ TBD Digest-Auth-Param
> 0-1 0 0 0 TBD Digest-AKA-Auts
> 0 0 0 0+ TBD Digest-Domain
> 0 0 0 0-1 TBD Digest-Stale
> 0 0-1 0 0 TBD Digest-HA1 (see Note 1,
> 2)
> 0-1 0 0 0 TBD SIP-AOR
>
> Table 1
>
> [Note 1] Digest-HA1 MUST be used instead of Digest-Response-Auth if
> Digest-Qop is 'auth-int'.
> [Note 2] Digest-Response-Auth MUST be used instead of Digest-HA1 if
> Digest-Qop is 'auth'.
> [Note 3] If Digest-Algorithm is missing, 'MD5' is assumed
>
>
>7. Example
s/Example/Examples/
> This is an example sniffed from the traffic between a softphone (A),
> a Proxy Server (B) and example.com RADIUS server (C). The
> communication between the Proxy Server and a SIP PSTN gateway is
> omitted for brevity. The SIP messages are not shown completely.
>
>
> A->B
>
> INVITE sip:97226491335@example.com SIP/2.0
> From: <sip:12345678@example.com>
> To: <sip:97226491335@example.com>
>
>
> B->A
>
> SIP/2.0 100 Trying
>
>
> B->A
>
> SIP/2.0 407 Proxy Authentication Required
> Proxy-Authenticate: Digest realm="example.com"
> ,nonce="3bada1a0", algorithm="md5"
> Content-Length: 0
>
>
> A->B
>
> ACK sip:97226491335@example.com SIP/2.0
>
>
> A->B
>
> INVITE sip:97226491335@example.com SIP/2.0
> Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
> ,opaque="",realm="example.com"
> ,response="f3ce87e6984557cd0fecc26f3c5e97a4"
> ,uri="sip:97226491335@10.0.69.38",username="12345678"
> From: <sip:12345678@example.com>
> To: <sip:97226491335@example.com>
>
>
> B->C
>
> Code = 1 (Access-Request)
> Attributes:
> NAS-IP-Address = a 0 45 26 (10.0.69.38)
> NAS-Port-Type = 5 (Virtual)
> User-Name = "12345678"
> Digest-Response = "f3ce87e6984557cd0fecc26f3c5e97a4"
> Digest-Realm = "example.com"
> Digest-Nonce = "3bada1a0"
> Digest-Method = "INVITE"
> Digest-URI = "sip:97226491335@example.com"
Why is the value of Digest-URI not the same URI provided by A?
> Digest-Algorithm = "md5"
> Digest-Username = "12345678"
> SIP-AOR = "sip:12345678@example.com"
>
>
> C->B
>
> Code = 2 (Access-Accept)
> Attributes:
> Digest-Response-Auth =
> "6303c41b0e2c3e524e413cafe8cce954"
>
>
> B->A
>
> SIP/2.0 180 Ringing
>
>
> B->A
>
> SIP/2.0 200 OK
>
>
> A->B
>
> ACK sip:97226491335@example.com SIP/2.0
>
>
>
> A second example shows the traffic between a web browser (A), web
> server (B) and a RADIUS server (C).
>
>
>
> A->B
>
> GET /index.html HTTP/1.1
>
>
> B->A
>
> HTTP/1.1 407 Authentication Required
> WWW-Authenticate: Digest realm="example.com",
> domain="/index.html",
> nonce="a3086ac8", algorithm="md5"
> Content-Length: 0
>
>
> A->B
>
> GET /index.html HTTP/1.1
> Authorization: Digest algorithm="md5",nonce="a3086ac8"
> ,opaque="",realm="example.com"
> ,response="f052b68058b2987aba493857ae1ab002"
> ,uri="/index.html",username="12345678"
>
>
> B->C
>
> Code = 1 (Access-Request)
> Attributes:
> NAS-IP-Address = a 0 45 26 (10.0.69.38)
> NAS-Port-Type = 5 (Virtual)
> User-Name = "12345678"
> Digest-Response = "f052b68058b2987aba493857ae1ab002"
> Digest-Realm = "example.com"
> Digest-Nonce = "a3086ac8"
> Digest-Method = "GET"
> Digest-URI = "/index.html""
> Digest-Algorithm = "md5"
> Digest-Username = "12345678"
>
>
> C->B
>
> Code = 2 (Access-Accept)
> Attributes:
> Digest-Response-Auth =
> "e644aa513effbfe1caff67103ff6433c"
>
>
> B->A
>
> HTTP/1.1 200 OK
> ...
>
> <html>
> ...
>
>
>
>
>8. IANA Considerations
>
> This document serves as IANA registration request for a number of
> values from the RADIUS attribute type number space:
>
> +-------------------------+------------------------+
> | placeholder | value assigned by IANA |
> +-------------------------+------------------------+
> | Digest-Response | TBD |
> | Digest-Realm | TBD |
> | Digest-Nonce | TBD |
> | Digest-Nextnonce | TBD |
> | Digest-Response-Auth | TBD |
> | Digest-Method | TBD |
> | Digest-URI | TBD |
> | Digest-Qop | TBD |
> | Digest-Algorithm | TBD |
> | Digest-Entity-Body-Hash | TBD |
> | Digest-CNonce | TBD |
> | Digest-Nonce-Count | TBD |
> | Digest-Username | TBD |
> | Digest-Opaque | TBD |
> | Digest-Auth-Param | TBD |
> | Digest-AKA-Auts | TBD |
> | Digest-Domain | TBD |
> | Digest-Stale | TBD |
> | Digest-HA1 | TBD |
> | SIP-AOR | TBD |
> +-------------------------+------------------------+
>
> Table 2
>
>
>9. Security Considerations
>
> The RADIUS extensions described in this document enable RADIUS to
> transport the data that required to perform a digest calculation. As
> a result, RADIUS inherits the vulnerabilities of HTTP Digest (see
> [RFC2617], section 4) in addition to RADIUS security vulnerabilities
> described in [RFC2865] Section 8 and [RFC3579] Section 4.
>
> An attacker compromising a RADIUS client or proxy can carry out man-
> in-the-middle attacks even if the paths between A, B and B, C
> (Figure 2) have been secured with TLS or IPsec.
>
> The RADIUS server MUST check the Digest-Realm attribute it has
> received from a client. If the RADIUS client is not authorized to
> serve HTTP-style clients of that realm, it might be compromised.
>
> RADIUS clients implementing the extension described in this document
> may authenticate HTTP-style requests received over the Internet. As
> compared with use of RADIUS to authenticate link layer network
> access, an attacker may find it easier to cover their tracks in such
> a scenario.
>
> An attacker can attempt a denial of service attack on one or more
> RADIUS servers by sending a large number of HTTP-style requests. To
> make simple denial of service attacks more difficult, the nonce
> issuer (RADIUS client or server) MUST check if it has generated the
> nonce received from an HTTP-style client. This SHOULD be done
> statelessly. For example, a nonce could consist of a
> cryptographically random part and some kind of signature provided by
> the RADIUS client, as described in [RFC2617], section 3.2.1.
>
> RADIUS servers SHOULD include Digest-Qop and Digest-Algorithm
> attributes in Access-Challenge messages. A man in the middle can
> modify or remove those attributes in a bidding down attack, causing
> the RADIUS client to use a weaker authentication scheme than
> intended.
>
> The Message-Authenticator attribute, described in [RFC3579] section
> 3.2 MUST be included in Access-Request, Access-Challenge, Access-
> Reject and Access-Accept messages that contain attributes described
> in this specification.
>
> The Digest-HA1 attribute contains no random components if the
> algorithm is 'MD5' or 'AKAv1-MD5'. This makes offline dictionary
> attacks easier and enables replay attacks.
>
> HTTP-style clients can use TLS with server side certificates together
> with HTTP-Digest Authentication. Instead of TLS, IPsec can be used,
> too. TLS or IPsec secure the connection while Digest Authentication
> authenticates the user. The RADIUS transaction can be regarded as
> one leg on the path between the HTTP-style client and the HTTP-style
> server. To prevent RADIUS from representing the weak link, a RADIUS
> client receiving an HTTP-style request via TLS or IPsec could use an
> equally secure connection to the RADIUS server. There are several
> ways to achieve this, for example:
> o the RADIUS client may reject HTTP-style requests received over TLS
> or IPsec
> o the RADIUS client require that traffic be sent and received over
> IPsec.
> RADIUS over IPsec, if used, MUST conform to the requirements
> described in [RFC3579] section 4.2.
>
>
>10. Acknowledgments
>
> We would like to acknowledge Kevin Mcdermott (Cisco Systems) /or
> providing comments and experimental implementation.
>
> Many thanks to all reviewers, especially to Miguel Garcia, Jari
> Arkko, Avi Lior and Jun Wang.
>
>
>11. References
>
>11.1. Normative References
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119, March 1997.
>
> [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.
>
> [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.
>
> [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
> RFC 3966, December 2004.
>
>11.2. Informative References
>
> [I-D.ietf-aaa-diameter-sip-app]
> Garcia-Martin, M., "Diameter Session Initiation Protocol
> (SIP) Application", draft-ietf-aaa-diameter-sip-app-09
> (work in progress), September 2005.
>
> [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
> Luotonen, A., Sink, E., and L. Stewart, "An Extension to
> HTTP : Digest Access Authentication", RFC 2069,
> January 1997.
>
> [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
> RFC 2246, January 1999.
>
> [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
> Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
> March 1999.
>
> [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification",
> RFC 2633, June 1999.
>
> [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
> Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
>