AW: HTTP digest and RADIUS; new version of the Sterman draft

["Beck01, Wolfgang" <BeckW@t-systems.com>]

Miguel,

you wrote:

> 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.
Correct me if have misunderstood your DIAMETER draft: authentication delegation
means, that the DIAMETER server knows a SIP server that knows how to
authenticate a user. This is sort of a routing function, that could be done
by a redirecting SIP proxy without using AAA protocol at all.

> 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. 
As you are already supporting both scenarios, I see two solutions.

1. You define the SIP-Authentication-Context content as body-digest
instead of the whole SIP message body when using HTTP Digest and
qop=auth-int
2. You define an additional AVP eg. SIP-Authentication-Digest that
can be used for transportation of digest values. It contains the
body-digest and is only used in environments using RADIUS translators.

I'd prefer option 1, because it would make DIAMETER messages shorter
and would not introduce separate RADIUS-related variations for a single
function.


Wolfgang Beck


--
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/>