Subject: [AAA-WG]: draft-diameter-sip-app; Authentication-Info and qop=auth-int

From: "Beck01, Wolfgang" <[email-masked]>
Date: Fri, 16 Jul 2004 10:55:41 +0200

Hello Miguel,

Rahul Joshi made an observation concerning Authentication-Info and qop=auth-int.
To calculate Authentication-Info with qop=auth-int, the AAA server must
know the bodies of both, the positive AND the negative SIP/HTTP response. 

This problem occurs with draft-sterman-aaa-sip. Has diameter-sip-app the same
problem? I see the following solutions:
1) drop support for Authentication-Info alltogether
2) drop support for Authentication-Info and qop=auth-int
3) let the RADIUS/DIAMETER client insert Body-Digests/Digest-Entity-Body-Hash
of the request and all response variants that might be sent after receiving an
answer of the server.

I am in favour of 2) as 3) means a lot of overhead in the clients.

Wolfgang

-----Ursprüngliche Nachricht-----
Von: Rahul Joshi [mailto:rahul_joshi a e t persistent.co.in]
Gesendet: Montag, 12. Juli 2004 14:43
An: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Beck,
Wolfgang; Rahul Joshi
Betreff: Calculating rspauth when qop=auth-int as per
draft-sterman-aaa-sip-02.txt

After going through the  draft-sterman-aaa-sip-02.txt and RFC 2617 (HTTP 
Authentication)
I have  a question regarding calculating rspauth attribute in 
Authentication-Info header when qop=auth-int.

Should the H(Entity-body)  used in the calculation of rspauth be of the 
"request"  message body that was received
or the 200 OK SIP response  that is being send back to the client ?

As per RFC 2617, pg 16, "qop=auth-int also provides
limited integrity protection of the response". Because of this I think 
that we should use the
H(Entity-Body)  of the 200 OK response in the calculation.  So how would 
the information of
the response message body  be communicated to the AAA server in the 
current framework
of draft-sterman-aaa-sip-02.txt?

Currently we  only send the hash of  "request message body" as  DIG-BODY 
attribute .
No hash of the response message body is communicated.

Is there any specific reason for devation from RFC 2617 by always
using the request message body hash , OR  there has been some 
misinterpretation on my part?

Regards.
-Rahul

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 27 Jul 2004 14:00:05 +0300

Hi Wolfgang:

My apologies for the delay in answering, caused by some vacation.

As for your question regarding the Authentication-Info header... This 
header is used only by SIP User Agents, i.e., it is not used by SIP 
proxies. So, if a SIP proxy receives a 200 OK response for an INVITE 
request from the called party, the SIP proxy will not append an 
Authentication-Info header to the response, and then then forwards it to 
the calling party. Instead, the Authentication-Info header is used only 
when the proxy is acting as a SIP User Agent (then is not a SIP proxy 
anymore, we should call it "the SIP box" instead).

We have several examples when the SIP box is acting as a SIP User Agent, 
for instance, when the SIP box is the recepient of REGISTER or SUBSCRIBE 
requests. When the SIP box generates a response to those requests, the 
SIP box could potentially include an entity-body in the response. This 
is not the normal case, since at the moment there are no semantics 
associated with responses to REGISTER or SUBSCRIBE methods in SIP.

Still it might be possible that "the SIP box" is acting as a SIP User 
Agent (e.g., a voice mail server) and generates a 200 OK that contains 
an SDP answer. In this case, it can generate an Authentication-Info 
header. Obviously, when the Diameter server generates the parameters 
that will populate the Authentication-Info header (in the MAA command), 
the SIP box has not created the SDP yet. The call flow (partial) will be 
as follows:

        SIP UA          SIP box      Diam. Srv.
          |                |              |
          |  INVITE (SDP)  |              |
          | -------------> |              |
          |                |    MAR       |
          |                | -----------> |
          |                |              |
          |                |    MAA       |
          |  200 OK (SDP)  | <----------- |
          | <------------- |              |
          |                |              |

My proposed solution is that the SIP box is in charge of creating the 
entity-body hash, since it is also responsible for creating the 
entity-body.

So according to the above figure, the Diameter server will include a 
SIP-Authentication-Info AVP in the MAA command. The 
SIP-Authentication-Info AVP contains a Digest-Qop AVP set to "auth-int", 
but does not contain a SIP-Authentication-Context AVP. The SIP box will 
create a SIP Authentication-Info header based on the 
SIP-Authentication-Info AVP. Since the Digest-Qop AVP is set to 
"auth-int", the SIP box will create the entity-body hash (e.g., SDP) and 
add it to the rspauth parameter of the Authentication-Info header.

If this is acceptable, I will add a discussion about this issue. I can 
add procedures to the Diameter client to generate the rspauth parameter 
when Digest-Qop is set to "auth-int" in a response.

Regards,

          Miguel

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