Re: AW: : digest issue 11 closure (fwd)

Right, this is the "rule" that allows the SIP server to do a translation 
and determine when to create an Authentication-Info header. This is the 
type of rules that Jari was trying to avoid, and I have been saying that 
is not possible in RADIUS. And this is the type of rule I am trying to 
avoid in Diameter.

/Miguel

Beck01, Wolfgang wrote:

> Miguel wrote:
> 
>>Hmmmm... I see the point. But I still believe a translation rule is 
>>needed, but not in the gateway, but in the RADIUS client (so 
>>this makes 
>>also the rule needed in the gateway).
>>
>>Imagine: how is the SIP-server/RADIUS-client going to 
>>determine that it 
>>has to generate an Authentication-Info header when the RADIUS server 
>>returns a next nonce? I guess there is a rule that says "if 
>>Digest-Nextnonce attribute present, then generate Authentication-Info 
>>header in SIP". So this is the rule between RADIUS and SIP.
>>
> 
> The draft is quite explicit when to generate Authentication-Info:
> 
>    The RADIUS client constructs an Authentication-Info header:
>    o  If the Access-Accept message contains a Digest-Response-Auth
>       attribute, the RADIUS client checks the Digest-Qop attribute:
>       *  If the Digest-Qop attribute's value is 'auth' or not specified,
>          the RADIUS client puts the Digest-Response-Auth attribute's
>          content into the Authentication-Info header's 'rspauth'
>          directive of the HTTP-style response.
>       *  If the Digest-Qop attribute's value is 'auth-int', the RADIUS
>          client ignores the Access-Accept message and behaves like it
>          had received an Access-Reject message (Digest-Response-Auth
>          can't be correct as the RADIUS server does not know the
>          contents of the HTTP-style response's body).
>    o  If the Access-Accept message contains a Digest-HA1 attribute, the
>       RADIUS client checks the 'qop' and 'algorithm' directives in the
>       Authorization header of the HTTP-style request it wants to
>       authorize:
>       *  If the 'qop' directive is missing or its value is 'auth', the
>          RADIUS client ignores the Digest-HA1 attribute.  It does not
>          include an Authentication-Info header into its HTTP-style
>          response.
>       *  If the 'qop' directive's value is 'auth-int' and at least one
>          of the following conditions is true, the RADIUS client
>          calculates the contents of the HTTP-style response's 'rspauth'
>          directive:
>          +  The algorithm directive's value is 'MD5-sess' or
>             'AKAv1-MD5-sess'.
>          +  The messages between RADIUS client and RADIUS server are
>             protected with IPsec (see Section 8).
>          It creates the HTTP-style response message and calculates the
>          hash of this message's body.  It uses the result and the
>          Digest-URI attribute's value of the corresponding
>          Access-Request message to perform the H(A2) calculation.  It
>          takes the Digest-Nonce, Digest-Nonce-Count, Digest-CNonce and
>          Digest-Qop values of the corresponding Access-Request and the
>          Digest-HA1 attribute's value to finish the computation of the
>          'rspauth' value.
>    o  If the Access-Accept message contains neither a
>       Digest-Response-Auth nor a Digest-HA1 attribute, the RADIUS client
>       will not create an Authentication-Info header for its HTTP-style
>       response.
> 
> 
> 
> Wolfgang
> 
> --
> T-Systems
> Next Generation IP Services and Systems
> +49 6151 937 2863
> Am Kavalleriesand 3
> 64295 Darmstadt
> Germany 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland