[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HTTP digest and RADIUS; new version of the Sterman draft
I understand that there are different possible scenarios. But as you
can imagine (no matter what the minor protocol encoding differences
are) its hard to interoperate if the models underlying the
protocols are different. As I would not like to see market
fragmentation, is there something that you Wolfgang and Miguel
could do to move towards a similar model, or at least provide
an ability to support one common model?
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
the body digest in the RADIUS client. As the maximum length
messages is limited to 4096, I see no way around some kind
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.
Wolfgang is correct in the sense that the Diameter SIP Application provides a SIP-Authentication-Context AVP which is intended to carry the whole entity-body in the case of SIP.
I must warn you that the Diameter SIP application supports two authentication scenarios, one where the Diameter server is authenticating the user, in which case the SIP-Authentication-Contxt AVP may have significance. The other scenario we support takes place when the Diameter server delegates authentication to the SIP server (the Diameter client). In this case there is no need to transfer the entity-body accross the network. This is the solution that we offer in the Diameter SIP application.
Wolfgang is proposing a third solution, let's call it "the hybrid solution". I said it is hybrid because the SIP server calculates the MD5 of the entity-body, but the Diameter (or Radius in your case) server authenticates the user. I wonder if the delegation of authentication to the SIP server would not solve your problem.
I believe this hybrid solution would work also in the Diameter SIP application, we simply didn't have a requirement to implement it, so we didn't.
My 0,02 EUR
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.