[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: AW: HTTP digest and RADIUS; new version of the Sterman draft
Beck01, Wolfgang wrote:
-----Ursprungliche Nachricht-----
Von: Jari Arkko [mailto:jari.arkko@piuha.net]
Gesendet: Donnerstag, 12. Februar 2004 09:29
An: Beck, Wolfgang
Cc: john.loughney@nokia.com; radiusext@ops.ietf.org
Betreff: Re: AW: HTTP digest and RADIUS; new version of the Sterman
draft
Jari Arkko wrote:
Beck01, Wolfgang wrote:
Open issues: I hope that I have addressed all the issues that were
raised in Minneapolis.
What about support for other algorithms than MD5? This was one
of my comments in Minneapolis. I took a new look at the draft.
It does not say anything about this, but on the other hand my
quick look did not reveal anything which would prevent them from
being supported. Can you say if you support them or not? Say, RFC
3310 support is included?
Other algorithms are supported as long as they don't define additional
parameters. RfC 3310 defines a new 'auths' parameter, which would
require an additional RADIUS (sub-)attribute. I am not sure if a
general procedure can be valid for all possible algorithms.
Ah, I see. But I would think that any additional parameter could
be transported easily, as long as it fits the RFC 2617 section 2.1
syntax for "auth-param". Of course, this requires that the parameters
are indeed part of the HTTP authentication header, but this appears
to be the case in variations that I know of. Could you accommodate this
is in a general way? If not, perhaps you could add support for "auts"
from RFC 3310 specifically. But that does not appear to be necessary.
My second significant comment at some point was the interoperation
with Diameter-based SIP AAA. I think this is a requirement. Can
you provide a section that explains how and under what limitations
this and draft-ietf-aaa-diameter-sip-app can work together?
Sure. For example, draft-ietf-aaa-diameter-sip-app defines a
SIP-Authentication-Context AVP which holds the SIP message body
for qop=auth-int. draft-sterman-aaa-sip-01 saves space by calculating
the body digest in the RADIUS client. As the maximum length of RADIUS
messages is limited to 4096, I see no way around some kind of compression.
DIAMETER allows much larger messages, but pre-computation of the body
digest might be a good idea for this protocol, too.
Ok. I'd prefer to see those considerations written down
somewhere. I believe that Miguel Garcia, who is working on
the Diameter SIp application, would be willing to listen
for feedback, if it turns out that interoperation is hard
for some specific reason.
--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/>