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
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.
Hi:
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
/Miguel
-- 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/>