open issue:draft-sterman, use of Access-Challenge

["Beck01, Wolfgang" <BeckW@t-systems.com>]

Use of Access-Challenge
Submitter name: Wolfgang Beck
Submitter email address: beckw@t-systems.com
Date first submitted: 25.8.2004
Reference: 
Document: RADIUS Extension for Digest Authentication
Comment type: T
Priority: 2
Section: 1.4, 3.1, 3.2
Rationale/Explanation of issue:
draft-sterman-aaa-sip-03 uses Access-Accept messages with a Digest-Nonce,
but without a Digest-Response parameter. This is a in fact a challenge
message and should use RADIUS Access-Challenge.

Requested change:
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.

                     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-Challenge (step 3).  This Access-Challenge
   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

3.1  RADIUS Client Behaviour

   [..]
   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-Challenge 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-Challenge message to the RADIUS
   client.  The RADIUS server MUST add Digest-Algorithm, Digest-Realm,
   SHOULD add 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.
    [..]


--
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/>