AW: : digest issue 11 closure (fwd)

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