[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions about RfC3310 and RADIUS HTTP-Digest
Beck01, Wolfgang wrote:
Jari,
while preparing the -02 version of the sterman draft, I discovered that
it would take an additional message exchange to handle AKA. In the
previous versions of the draft, nonces where only generated by the RADIUS
client. Assuming that authentication vectors are user-specific, this would
not work with AKA. So I included an optional message exchange. However,
after re-reading my changes, the word "optional" turned up quite frequently.
A bad thing in a standard.
- Do we need RADIUS server generated nonces in other scenarios than AKA?
Right now, the only algorithms defined and in use
with Digest are MD5 and AKA. Its kind of hard
to say what other things will come in the future.
It seems that there's another general situation,
however, that may require the same roundtrip:
parameters. RFC 2617 defines the parameters (nonce
is one but there can be others), and those can
appear already in the challenge. Perhaps some
future algorithm or Digest extension would utilize
the parameters in a user-specific way, which would
lead to the same additional roundtrip.
- Would it be better to put RADIUS AKA Digest into a separate
(informational) document?
I'd really like to see the RADIUS Digest work be
able to handle all existing Digest algorithms,
and full RFC 2617 syntax. I'm sorry that Digest
AKA gives you additional things to worry about.
If you don't see other way than an optional
additional roundtrip, then we probably need it.
--Jari
--
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/>