Subject: [AAA-WG]: [Fwd: Comments on draft-ietf-aaa-diameter-sip-app-05.txt]

From: Miguel Garcia <[email-masked]>
Date: Tue, 08 Feb 2005 12:48:26 +0200

Howdy!

I got an e-mail with some comments to the Diameter SIP application 
version -05 (the latest version is -06), but I think there are no 
conflicts with the section numbers, so you can take a look at either 
version -05 or -06.

I am posting this so that people can take a look at these comments. I 
will send my answers later today, but I certainly welcome answers from 
anyone or further comments.

BR,

       Miguel

----------

1) In chapter 5.4 SIP Server is not Authenticating the Request. The 
Diameter Server is authenticating the request.

2) In chapter 7.7 it is written: 'Unlike the Diameter UAR command, MAR 
does not store any state in the Diameter server'. What does this mean? 
What state? Authentication pending flag is set in MAR...

3) In chapter 8.5 it is written: ' If the SIP-Auth-Data-Item is used to 
convey a SIP-Authenticate grouped AVP, then the Diameter client MUST 
send a maximum of one authentication data item'. Isn't the 
SIP-Authenticate used by Diameter server?

4) In chapter 8.6 and 10  it is talked about authentication vectors. In 
HTTP Digest authentication there are no really any authentication 
vectors in my opinion and the draft is not only about AKA authentication 
in IMS.

5) Chapter 10, 3rd paragraph: The calculation of H(A1) doesn't depend on 
qop, but on the algorithm. See chapter 3.2.2.2 of RFC 2617.

6) In chapter 10 from fourth paragraph the reader gets the impression 
SIP-Authentication-Scheme AVP will contain data (typically a challenge 
of some kind), which is not true.

7) Chapter 10. It is not clearly told, how many credentials the Diameter 
client must send to the Diameter server. First there can be more than 
one credentail and later on the Diameter client must send zero or 
exactly one credentail to the Diameter server. It is told also that the 
Diameter server may include one or more SIP-Auth-Data-Item AVPs to 
provide further authentication vectors to the SIP server. This is 
possible only if it is known that the realm and method of the next 
request will be the same and qop is not 'auth-int'. This is possible of 
course also if the Diameter client sent several credentials, but does 
the text refer to this case?

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

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 09 Feb 2005 13:47:35 +0200

Inline comments.

I will generate a new version of the Diameter SIP app in the next few days.

I have also listed these issues in the issues tracker at:

http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/

/Miguel

> anyone or further comments.

Oooops, I see the bug. So I guess this section should have been called 
"Stateless SIP proxy requests authentication and authorization" or 
something like that.

> What state? Authentication pending flag is set in MAR...

I think what is wrong is the comparison with UAR. Actually, the 
comparison should be done with SAR, because SAR stores a registration 
state, perhaps the URI of the SIP server, etc.

The "registration pending flag" that you mention is something internal 
to the Diameter server, but is not created due to the protocol, so I 
don't consider this a protocol state.

> SIP-Authenticate used by Diameter server?

This is another bug, the text should refer to the SIP-Authorization AVP 
that is extracted from the Authorization header in SIP. The text should say:

"If the SIP-Auth-Data-Item is used to convey a SIP-Authorization grouped 
AVP, then the Diameter client MUST send a maximum of one authentication 
data item (e.g., in case the SIP request contained several credentials)."

> vectors in my opinion and the draft is not only about AKA authentication 

Ok, this is about terminology. Perhaps we should mention "number of 
authentication credentials" rather than authentication vectors. I guess 
it would be clearer.

> qop, but on the algorithm. See chapter 3.2.2.2 of RFC 2617.

Ok, first I agree that H(A1) does not depend on qop, but on algorithm. 
And I think the bug here has some history... In the past (version -03) 
the Diameter server used to send the whole expected-response to the SIP 
server, and the expected response was dependent on the qop, H(A2), etc. 
You may notice that the text speaks about the "expected response", but 
mentions the Digest-HA1 AVP instead.

Since this behaviour was considered insecure, we changed it, and we made 
the Diameter servr send H(A1) only, which is always dependent on the 
algorithm and not the qop.

So I believe we need to remove that paragraph. Digest-HA1 is always 
valid, no matter whether client nonces are used or not. Any other views?

> of some kind), which is not true.

SIP-Authentication-Scheme will indicate "Digest", which is the only 
value supported for the time being. Perhaps I can clarify this.

> exactly one credentail to the Diameter server. 

I think this was clearly written... The last paragraph in section 10 
clarifies the issue, it reads:

"There are situation where a SIP request traverses several proxies, and 
each of the proxies request to authenticate the SIP UA. In this 
situation, it is a valid scenario that a SIP request received at a SIP 
server contains several sets of credentials. The 'realm' directive in 
HTTP is the key that the Diameter client can use to determine which 
credential is applicable. It may happen also that none of the realms are 
of interests to the Diameter client, in which case the Diameter client 
MUST consider that no credentials (of interest) were sent. In any case, 
a Diameter client MUST send zero or exactly one credential to the 
Diameter server. The Diameter client MUST choose the credential based on 
the 'realm' directive in the Authorization/Proxy-Authorization header 
field, and it MUST match the realm of the Diameter client."

> It is told also that the 
> request will be the same and qop is not 'auth-int'. 

Good point. It would be interesting to clarify it.

> This is possible of 

No, this text is inspired from the 3GPP Cx interface application. The 
functionality was inherited from there, as a mechanism to allow the 
S-CSCF to get a bunch of authentication vectors and stop requesting a 
new authentication vector to the Diameter server.

I am not sure what to do now... We may need to explain what are the 
constraints of this case, or we may need to just remove this from the 
spec. Opinions?

BR,

         Miguel