[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: digest-auth negotiation issue
On Mon, 9 Jan 2006, Beck01, Wolfgang wrote:
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
Indeed. It isn't too unlikely there will be radius servers only supporting
MD5-sess, and additionally only in scenario 2 mode of operations. This
would be due to second level user directory integration requirements where
the radius server itself can not get raw access to the MD5 H(A1) as it is
rather security sensitive piece of information, only session hashes
coupled with a unique sesson nonce generated by the user directory
service.
- 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.
auth vs auth-int is mainly a property of the RADIUS client, not the RADIUS
server. Having this decided by the RADIUS server in either mode would be a
bit odd. But indeed possible in scenario 2 mode operations.
What is missing here is to clarify that in both cases the client should
include a Digest-Qop attribute in the first message (or to be precise all
messages) indicating which of auth or auth-int is desired. If not
specified auth is assumed. The radius server MAY override the client
wishes, but it can not be expected that all clients supports auth-int.
can we add this without starting a new round of Last Calls?
Hope so.
Proposal 2:
remove scenario 1 from the draft, go back to WGLC
Hmm.. can't really make up my mind on this one. It is a quite useful
optimization of the protocol, in lack of useable MD5-sess session
support..
But at the same time it's a quite dangerous mode of operation if adding
MD5-sess session support as it could allow theft of the session hash via
another authorized RADIUS client.
Additionally scenario 1 mode of operations have a minor security issue in
that it allows for probing to verify if the password is still the same by
simply replaying the exact same digest message, provided one has gained
authorization to talk to the RADIUS server directly.
Additionally the strength of the Digest hashing as such is also partly a
property of the how well the RADIUS client chooses it's nonces in this
mode of operation.. If the client is really poorly implemented and only
selects between a small set of nonces it could make Digest open to replay
attacks, no matter how good the RADIUS server implementation is. But the
opposite is also true in that in scenario 2 the client can not choose
stronger nonces if it is found the RADIUS server is poorly implemented...
Regards
Henrik
--
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/>