[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue 117: Transport Behavior

To: radiusext@ops.ietf.org
Subject: Issue 117: Transport Behavior
From: Bernard Aboba <aboba@internaut.com>
Date: Thu, 11 Aug 2005 12:02:04 -0700 (PDT)
Issue 117: Transport Behavior
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: August 11, 2005
Reference:
Document: DIGEST-03
Comment type: T
Priority: S
Section: 2.1, 2.2
Rationale/Explanation of issue:

In at least two places, this document changes the basic transport behavior
of RADIUS. If a RADIUS client does not receive a response from a RADIUS
server, it retransmits the Request or fails over to another RADIUS server.
A RADIUS client that automatically rejects user access without
retransmission or failover is badly behaved.


In general, a RADIUS server only silently discards a packet if
it is invalid, such as a packet containing a Request Authenticator
(Accounting) or Message-Authenticator attribute that does not verify.
Unless there is a loading problem, silently discarding packets is a bad
idea since the client will just retransmit or failover to another RADIUS
server. If the Access-Request is valid but is requesting an unauthorized
service, the correct response is an Access-Reject, not silent discard.

In Section 2.1,

Change:

" The RADIUS server MAY have added a Digest-Nextnonce attribute into an
Access-Accept message. 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.

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 or no response from
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-Nextnonce 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. It adds a Message-Authenticator (see
[RFC3579]) attribute to the Access-Request message. 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 message 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."

To:


" The RADIUS server MAY include a Digest-Nextnonce attribute within an
Access-Accept message. A RADIUS client receiving a Digest-Nextnonce
attribute places the contents of this attribute into a 'nextnonce'
directive within a response sent to the HTTP-style client.

If the RADIUS client receives 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 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 can generate
them locally, it may receive a Digest-Nextnonce attribute within an
Access-Accept message, or it may ask the RADIUS server to generate one.
To do the latter, it sends an Access-Request containing Digest-Method
and Digest-URI attributes, but without a Digest-Nonce attribute. The
RADIUS client then adds a Message-Authenticator attribute to the
Access-Request message. 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
RADIUS client MUST use them.

If the RADIUS client sends an Access-Request containing a Digest-Nonce
attribute and receives an Access-Challenge message in response,
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."

In Section 2.2,

Change:

" 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-Challenge message 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 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-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 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.
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 silently
discards the Access-Request message. Other actions taken by the
RADIUS server are out of scope of this document. However, the RADIUS
server should notify the operator and may take additional action such
as discarding all future requests from this client, until some
management action tells it to do so again.

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."

to:

" If the RADIUS server receives an Access-Request message with
Digest-Method and Digest-URI attributes, but without a Digest-Nonce
attribute, sends an Access-Challenge message to the RADIUS client
containing a nonce within a Digest-Nonce atribute.
The RADIUS server MUST include Digest-Realm and Message-Authenticator
attributes within the Access-Challenge and SHOULD include Digest-Algorithm
and one or more Digest-Qop attributes. The RADIUS server MAY include
Digest-Domain and Digest-Opaque attributes in the Access-Challenge
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-Entity-Body-
Hash, Digest-CNonce and Digest-AKA-Auts attributes; 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, the RADIUS server MUST respond
with an Access-Reject. If the required attributes are present, the
RADIUS server calculates the digest response as described in [RFC2617].
The RADIUS server determines the required credentials based on the
contents of the User-Name attribute sent in the Access-Request.
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 these checks fail, the RADIUS server MUST send an Access-Reject.

Correlation between User-Name and SIP-AOR AVP values is required to
prevent a user from registering or misusing a SIP-AOR allocated to
another user.

A RADIUS server MUST check if the RADIUS client is authorized to
serve users of the realm provided 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."

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>
Prev by Date: AW: Do we have consensus on the Digest Auth draft issues?
Next by Date: Issue 118: Editorial NITs
Previous by thread: AW: Do we have consensus on the Digest Auth draft issues?
Next by thread: Issue 118: Editorial NITs
Index(es):
- Date
- Thread