Re: : ISSUE, SIP, authentication parameters

Mikko, I will try to answer your questions one by one inline.


[email protected] wrote:

> Hi,
> 
> 
>>The reason why this AVP is required is because Digest-Method will not 
>>ever be present, because it depends on the presenece of an 
>>Authorization header in SIP, that typically will not be present.
>>I think it is a bad idea to twist a protocol inserting a
>>SIP-Authorization AVP that contains a Digest-Method for no apparent
>>reason.
> 
> 
> I think there is several issues here (hmm.. should I split this issue
> to smaller pieces :)
> 
> 1. Why is the method required information in MAR?

Because we want to enable the scenario described in Section 5.5, where 
there is an outbound SIP proxy authorizing certain SIP transactions. 
This authorization might depend on the SIP method (for instance, I might 
be able to send instant messages (MESSAGE method in SIP) but not do 
publication of presence (PUBLISH).

> 2. What AVP is used to transport the method?

SIP-Method

> 3. Where is the AVP that transports the method inserted
>    in the message?

I don't quite understand. In the example I gave you, the SIP-Method AVP 
is part of the MAR command.

> 4. Is there need to transport the method twice in the message?

They are used for different things, SIP-Method is exclusively used for 
authorization. The text in Section 8.14 reads (about the SIP-Method AVP):

"The Diameter server MUST use this AVP solely for authorization of SIP 
requests, and MUST NOT use it to compute the Digest authentication. To 
compute the Digest authentication, the Diameter server MUST use the 
Digest-Method AVP instead."

Once more, if you didn't have Digest authentication you wouldn't have 
Digest-Method... but still you may want to do authorization based on the 
SIP-Method.

So I am afraid we can't take your suggestion on board.


/Miguel


> 
> Answer 1: I have no answer for question 1. That is why I proposed
> the information should be [optional] instead of {required}.
> The spec says Diameter server can use this information to authorize
> the method. Does the spec say what does the server respond if it
> doesn't want to authorize the method?
> 
> Answer 2: I don't care. I prefer Digest-Method unless Radius
> starts to use SIP-Method. I don't see a need for having new
> AVP for transporting the same thing. If the wg disagrees it's
> fine if we use SIP-Method and delete Digest-Method from
> SIP-Authorization. 
> 
> Answer 3: I don't care. I think it can be in the "main-level"
> of MAR, in SIP-Auth-Data-Item, or in SIP-Authorization.
> 
> Answer 4: Certainly not. I think it's not good protocol design.
> 
> 
> 
>>Could we delete Digest-Method? Probably, but for consistency and full 
>>compatibilty with the Radius Digest authentication, which already 
>>includes the Digest-Method, we agreed in the past to include it.
> 
> 
> I think from the translation agent point of view this not
> a good solution. It needs to copy the Digest-Method attribute twice
> to MAR. First to SIP-Method AVP and then to Digest-Method AVP.
> I think the full compatibility with the Radius Digest authentication
> can be achieved without the duplicate information.
> 
> 
> BR,
> Mikko
> 
> 
> 
>>-----Original Message-----
>>From: Miguel Garcia [mailto:[email protected]]
>>Sent: 26 October, 2005 13:35
>>To: Aittola Mikko (Nokia-NET/Tampere)
>>Cc: [email protected]
>>Subject: Re: [AAA-WG]: ISSUE, SIP, authentication parameters
>>
>>
>>Inline discussion.
>>
>>[email protected] wrote:
>>
>>
>>>Hi!
>>>
>>>
>>>
>>>>No, it is just simpler to have a specific AVP (SIP-Method) that 
>>>>indicates the method of the SIP request that is under 
>>
>>authorization. 
>>
>>>>Clear semantics of what is the purpose of this AVP.
>>>
>>>
>>>I understand the purpose of the AVP, but I don't understand
>>>why it is a required AVP. 
>>
>>
>>The reason why this AVP is required is because Digest-Method will not 
>>ever be present, because it depends on the presenece of an 
>>Authorization 
>>header in SIP, that typically will not be present. I think it 
>>is a bad 
>>idea to twist a protocol inserting a SIP-Authorization AVP 
>>that contains 
>>a Digest-Method for no apparent reason.
>>
>> >   also don't understand why the Diameter
>>
>>>client needs to transport the same information twice to the server
>>>in the message. It seems redundant. Isn't it so that SIP-Method and
>>>Digest-Method always contain the same value? I think we need only
>>>one AVP for the method.
>>
>>It is correct that, if Digest-Method is present, it will contain the 
>>same value as SIP-Method.
>>
>>If we decide to have only one AVP, then we will need favour to 
>>SIP-Method, because Digest-Method will not ever be present. 
>>Besides, if 
>>in the future we decide to support some other non-Digest 
>>authentication 
>>mechanism but still be able to authorize requests based on 
>>the method. 
>>So we can't delete SIP-Method.
>>
>>Could we delete Digest-Method? Probably, but for consistency and full 
>>compatibilty with the Radius Digest authentication, which already 
>>includes the Digest-Method, we agreed in the past to include it.
>>
>>
>>
>>>
>>>
>>>>What you are proposing is a fake of the whole authorization 
>>
>>mechanism 
>>
>>>>specified in RFC 2617. An Authorization header should contain 
>>>>a number of directives, such as username, realm, nonce, digest-uri, 
>>>>and response, which happen that none of them are present in the
>>>>SIP INVITE request.
>>>
>>>
>>>But isn't it so that the method is not part of the authorization
>>>header? So the client can fill the Digest-Realm exactly the same
>>>way in both cases?
>>>
>>
>>Yes, sorry, it is correct that the method is not part of the 
>>Authorization header.
>>
>>
>>/Miguel
>>
>>
>>
>>>
>>>>Ah, are there any other problems in the issue? I thought one issue 
>>>>equals one problem...
>>>
>>>
>>>I bundled all authentication-parameter issues into a one issue,
>>>but I'll try to separate and clarify them.
>>>
>>>
>>>BR,
>>>Mikko
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email protected]
Nokia Research Center      Helsinki, Finland