RE: : ISSUE, SIP, authentication parameters

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


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


> 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