Re: : 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
> 
> 
> 
>>-----Original Message-----
>>From: Miguel Garcia [mailto:[email protected]]
>>Sent: 25 October, 2005 17:06
>>To: Aittola Mikko (Nokia-NET/Tampere)
>>Cc: [email protected]
>>Subject: Re: [AAA-WG]: ISSUE, SIP, authentication parameters
>>
>>
>>Inline discussion.
>>
>>[email protected] wrote:
>>
>>
>>>>and we wanted to add a possibility to enable the scenario 
>>>>described in Sections 5.5 and 5.6, where an outbound proxy is
>>>>authorizing request. Some users might be authorized to use any
>>>>SIP method, others only a few of them. In order to do this,
>>>>the SIP-Method must be present.
>>>
>>>
>>>I think in order to do that it's enough to define that the 
>>
>>default-behavior
>>
>>>of Diameter server is that all SIP-methods are authorized. 
>>
>>This is applied
>>
>>>in the case where no Digest-Method is received. If the 
>>
>>Diameter server receives
>>
>>>Digest-Method then it can apply some other policy. This is 
>>
>>what the text
>>
>>>I proposed does. So there is no need to have SIP-Method as required
>>>AVP.
>>>
>>
>>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.
>>
>>
>>>
>>>>And at that point in time, the user might not have sent any
>>>>Authorization header, so the Digest-Method might not be present.
>>>
>>>
>>>The Diameter client can fill the Digest-Method to the 
>>
>>SIP-Authorization
>>
>>>AVP even if there is no Authorization header in the SIP-request.
>>>
>>>What about the other problems I indicated in the issue?
>>
>>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.
>>
>>I am sorry, but the current text is technically correct. If 
>>you find a 
>>defect we can discuss it, but I am saying that there is not 
>>such defect.
>>
>>Ah, are there any other problems in the issue? I thought one issue 
>>equals one problem...
>>
>>/Miguel
>>
>>
>>>
>>>BR,
>>>Mikko
> 
> 

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