open issue:draft-sterman, use of Access-Challenge
"Beck01, Wolfgang" <BeckW@t-systems.com> Wed, 25 August 2004 16:09 UTC
Envelope-to: radiusext-data@psg.com
Delivery-date: Wed, 25 Aug 2004 16:11:25 +0000
Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FD78@E9JDF.mgb01.telekom.de>
From: "Beck01, Wolfgang" <BeckW@t-systems.com>
To: radiusext@ops.ietf.org
Subject: open issue:draft-sterman, use of Access-Challenge
Date: Wed, 25 Aug 2004 18:09:57 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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/>
- open issue:draft-sterman, use of Access-Challenge Beck01, Wolfgang