RE: : ISSUE, SIP, authentication parameters

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?
2. What AVP is used to transport the method?
3. Where is the AVP that transports the method inserted
   in the message?
4. Is there need to transport the method twice in the message?

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