Subject: RE: [Sip] draft-khartabil-sip-auth-analysis-00.txt

From: [email-masked]
Date: Thu, 19 Feb 2004 12:28:55 +0200

> -----Original Message-----
> From: ext Scott Lawrence [mailto:[email-masked]]
> Sent: 18.February.2004 17:30
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Sip] draft-khartabil-sip-auth-analysis-00.txt
> 
> 
> 
> 
> > >   realm
> > >     A string to be displayed to users so they know which 
> username and
> > >     password to use.
> > 
> > I don't think this takes into consideration pre-configuration.
> 
> That's not really the point; the realm needs to provide 
> enough of a hint
> for the UA to determine which credentials it should use.  Setting up a
> configuration that requires different credentials for the 
> same realm at
> different servers is dumb, and not something I think we need to spend
> much worry on.

It not about setting different credentials for the same realm. It is about pre-configuring the wrong credentials for a realm. If my phone is preconfigured with username: hisham, password: hishampass, realm: nokia.com and:

--> INVITE
<-- 407
--> INVITE
<-- 407 (credentials where wrong)

At this stage, the user should be prompted to enter new username/password. My objection is to the text quoted below from RFC3261:

"  A service provider that pre-configures UAs with credentials for its
   realm should be aware that users will not have the opportunity to
   present their own credentials for this realm when challenged at a
   pre-configured device".

I think the users should have the opportunity.

> 
> > >                 ... This string should contain at least 
> the name of
> > >    the host performing the authentication and might additionally
> > >    indicate the collection of users who might have 
> access. An example
> > >    might be "[email-masked]".
> > 
> > Can we mandate that for SIP??
> 
> I don't think that we can mandate anything that is by nature an
> administrative decision - we already provide good advice.  
> However, 3261
> does say (22.1):
> 
>       o  Realm strings MUST be globally unique.  It is 
> RECOMMENDED that
>          a realm string contain a hostname or domain name, 
> following the
>          recommendation in Section 3.2.1 of RFC 2617 [17].

MUST be globally unique for every proxy in the same administrative domain? I don't think this is required.

> 
> > > As a practical matter, if you have the same username and 
> password in
> > > both domains it doesn't matter - if you don't, then it's 
> an impossibly
> > > clumsy situation (this problem is part of the reason that 
> we defined
> > > proxy authentication to by hop-by-hop in HTTP in the first place).
> > 
> > Perhaps I was not clear in my text. Imagine this scenario: 
> I have cached my credentials for an outbound proxy with realm 
> proxy.nokia.com from an earlier transaction. Now I send a new 
> INVITE routed through the outbound proxy that gets a 407 from 
> a second proxy with the same realm. How do I know if the 407 
> came from the outbound proxy (the username password might 
> have changed in the meantime) or from the next hop proxy?
> 
> What difference does it make?  You just use the credentials 
> you have in
> either case, or you fail...  

It matters because the UA doesn't know if the credentials supplied to the first proxy were wrong and therefore is sending another 407 or if the second proxy is challenging with the same realm. The qop ting you mention below should fix this.

>As I pointed out, you can tell the
> difference if the server is using qop.
> 
> 
> > > If the proxy is using the 2617 version of Digest (with the qop
> > > attribute) as opposed to the 1867 version, then the UA can tell
> > > the difference.  The message flow looks like this:
> > > 
> > >         UA                    P1                  P2
> > >     a    +------REQ 1--------->|                   |
> > >     b    |<----407(1)----------+                   |
> > >     c    +------REQ 2 -------->+----REQ 2--------->|
> > >     e    |<---407(2)-----------+<-----407(2)-------|
> > >          +------REQ 3--------->+----REQ 3--------->|
> > > 
> > >  a) initial request
> > >  b) challenge from P1, with the qop parameter specified
> > >  c) retried request, with a qop parameter, and therefor 
> also a cnonce
> > >     chosen by the UA; it is passed on (now without 
> > > authentication) to P2
> > >  d) P2 challenges, also specifying a qop parameter
> > >     P2 challenge is forwarded by P1, with the WWW-Authenticate
> > >     header as provided by P2, but also with an Authentication-Info
> > >     provided by P1.
> > > 
> > > The UA can recognize that authentication to P1 was 
> successful, because
> > > P1 returned an Authentication-Info header that contained 
> the cnonce
> > > and nc values from message c (REQ 2), and a correct 
> response hash to
> > > show that P1 knows the authentication secret.
> > 
> > This is not mandated for SIP entities, maybe it aught to be.
> 
> Actually, it is, but it's the usual unfortunate incorrect 
> intrepretation
> of SHOULD that is biting us again.  RFC 2617 says:
> 
>    qop-options
>      This directive is optional, but is made so only for backward
>      compatibility with RFC 2069 [6]; it SHOULD be used by all
>      implementations compliant with this version of the Digest scheme.
> 
> Since SIP references only 2617, and backward compatibility 
> with 1867 is
> not important, all SIP servers should be using qop-options.

This is all great, although I prefer for this to be called out explicitly for SIP, making the SHOULD a MUST. Also, there is nothing mandating a proxy to send the Authentication-info header. Perhaps that aught to be mandated also if a proxy server proxies a request it had previously challenged and another proxy downstream challenges the same request with the same realm.

> 
> > > > 10. Authentication-Info
> > > >
> > > >  RFC 3261 allows the usage of Authentication-Info 
> header. The BNF in
> > > >  RFC 3261 allows multiple authentication-info headers 
> where RFC 2617
> > > >  allows only one. Is it only the terminating UAS that 
> is allowed to
> > > >  insert this header. If so, why allow multiples to be 
> > > present. If not,
> > > >  how does the UAC know which proxy added this header? 
> It cannot know
> > > >  since there is no parameter indicating so, not even nonce.
> > > 
> > > As I noted earlier, 2617 allows only one because proxy 
> authentication
> > > is hop-by-hop, but the cnonce value allows the UA to 
> disambiguate them
> > > (if they are carefully constructed, but then they should 
> be anyway).
> > 
> > SIP BNF allows multiples of those headers. Is this a BNF 
> bug? If not, then some Authentication-Info parameters need to 
> be mandated.
> 
> The BNF is never the last word - the text MUST be read too, and the
> requirement there is, I think, already clear.

Ok, although it is only implied that message-qop MUST appear in Authentication-info header if the earlier challenge/response contained the qop.

> -- 
> Scott Lawrence        
>   Pingtel Corp.   

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip