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

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

Miguel Garcia wrote:

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

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.


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


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.

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

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)."


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

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


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

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?


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

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

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

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 
> 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'. 

Good point. It would be interesting to clarify it.

> This is possible of 
> course also if the Diameter client sent several credentials, but does 
> the text refer to this case?
> 

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

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