RE: : ISSUE, SIP, authentication parameters

Hi,

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

The scenario described in Section 5.5 can be enabled with
or without SIP-Method AVP. I agree informing Diameter server
about the method can be used by the server as you describe.
I agree it can be a useful feature.

The issue is: why this feature needs to be mandatory/required?
I think you didn't answer this question, but at this
point I give up and say that let's keep SIP-Method AVP as required
and move on.


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

I think this text is not needed. The contents of the SIP-Method AVP
and Digest-Method AVP are the same. It doesn't matter which one is used.
If we keep SIP-Method AVP we should delete Digest-Method AVP from
the Diameter SIP Application because it is redundant information.

There is no need to transfer the information twice in the
Diameter message.


BR,
Mikko


> -----Original Message-----
> From: Miguel Garcia [mailto:[email protected]]
> Sent: 27 October, 2005 13:38
> To: Aittola Mikko (Nokia-NET/Tampere)
> Cc: [email protected]
> Subject: Re: [AAA-WG]: 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
> 
>