digest-auth negotiation issue

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

Following the contributions of Alexey Melnikov and Hendrik Nordstrom,
I think we have also a negotiation problem.

In scenario 1 -- RADIUS client chooses nonces -- the RADIUS client has to know
what RfC2617 features the responsible RADIUS server supports. 

The trouble is, that an HTTP Digest server not only sends the nonce but also the supported
protocol features in its initial response. The RADIUS client can invent a nonce but does
not necessarily know the features of the RADIUS servers.

The draft mentions only the AKA case and requests manual configuration. MD5, MD5-sess, auth,
auth-int are not covered.

Proposal 1:
clarify by adding a new section:

	RADIUS client configuration
	
	A RADIUS client choosing nonces has to maintain some configuration data for each
	RADIUS server it may send requests to:
	- the algorithms (MD5, MD5-sess, etc) supported by the RADIUS server
	- the quality of protection (qop) levels supported by the RADIUS server
	This configuration may be done manually or by protocols not covered in this document.

can we add this without starting a new round of Last Calls?

Proposal 2:

remove scenario 1 from the draft, go back to WGLC


Wolfgang
--
T-Systems International GmbH
Technologiezentrum
Next Generation IP Services and Systems
+49 6151 9372863
Am Kavalleriesand 3
64295 Darmstadt



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