Subject: RE: [Sip] FW: I-D ACTION:draft-khartabil-sip-auth-analysis-00.txt

From: [email-masked]
Date: Tue, 17 Feb 2004 16:57:17 +0200

Scott,

Thanks for the comments. Responses inline...

> -----Original Message-----
> From: ext Scott Lawrence [mailto:[email-masked]]
> Sent: 16.February.2004 22:10
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Sip] FW: I-D
> ACTION:draft-khartabil-sip-auth-analysis-00.txt
> 
> 
> On Fri, 2004-02-06 at 02:48, [email-masked] wrote:
> > Having tried to implement HTTP Authentication for SIP, we faced 
> > a few problems. This draft tries to highlight those problems and 
> > in some cases suggests a solution.
> 
> Comments on draft-khartabil-sip-auth-analysis-00
> 
> > 2. Use of 401 and 407 Responses, www-authenticate and
> >  proxy-authenticate headers
> >  [...]
> >  The use of 401 and 407 must be more normative. Text should read: A
> >  UAS that require authentication MUST use 401 in a response and MUST
> >  challenge with a www-authenticate header. Registrars and redirect
> >  servers MUST use 401 and www-authenticate header. Proxies MUST use
> >  407 and proxy-authenticate header.
> 
> That would be a clear improvement, I think.
> 
> > 3. Rendering to user
> 
> It's not clear to me what it is you're objecting to in this section,
> except perhaps that the user interface guideline is poorly rendered.

Yes, this is the point I was trying to make. The fact that a username and password for a realm is preconfigured does not mean that the user does not get to re-enter those credentials if the server rejected the ones sent earlier.

> 
> The real requirement, I think, is that if the user is being asked for
> credentials, they should be shown the realm value at that time; a fact
> that is made clear in RFC 2617 (sec 3.2.1):
> 
>   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.

> 
> > 4. Rejected or not
> >
> >  Section 22.1 of RFC 3261 says: "A UAC MUST NOT re-attempt requests
> >  with the credentials that have just been rejected (though 
> the request
> >  may be retried if the nonce was stale)".
> >
> >  The problem with this is that how do you know if the 
> request has been
> >  rejected or it is just the next hop proxy challenging with the same
> >  realm?
> 
> This case couldn't come up in HTTP, since proxy authentication in HTTP
> is hop-by-hop, and 407 challenges are never passed back to the user
> agent by a proxy.  

In SIP, unfortunately it is possible.

> However, the reset of the description of realm is
> good advice:
> 
>                 ... 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??

> 
> > 5. Use of To-header vs. Remote URI (Request-URI)
> >
> >  Section 22.2 of RFC 3261 says: "The UAC may require input from the
> >  originating user before proceeding.  Once authentication 
> credentials
> >  have been supplied (either directly by the user, or 
> discovered in an
> >  internal key-ring), UAs SHOULD cache the credentials for a given
> >  value of the To header field and "realm" and attempt to 
> re-use these
> >  values on the next request for that destination".
> >
> >  It is more appropriate to cache request-URI, and not rely 
> on what is
> >  in the To-header.
> 
> Agreed - the To header value is not protected by the hash, so
> associating it is not appropriate.  In addition, this paragraph
> encourages the existing confusion between these two values
> (admittedly, they are often the same, but it is the Request URI that
> is used in authentication).
> 
> > 7. Caching outbound proxy credentials
> >
> >  Section 22.3 of RFC 3261 says: "if a UA is configured with 
> the realm
> >  of its local outbound proxy, when one exists, then the UA MAY cache
> >  credentials for that realm across dialogs".
> >
> >  It cannot be assumed that the domain name of a configured outbound
> >  proxy is its realm. Therefore a terminal configured with only the
> >  outbound proxy URI cannot and MUST NOT cache credentials 
> or any proxy
> >  challenge across dialogs.
> >
> >  This introduces the problem of multiple proxies in a chain
> >  challenging with the same realm. How does a UAC know that the
> >  challenge was from the outbound proxy and not from a 
> downstream proxy
> >  with the same realm as the outbound proxy? Can we mandate that the
> >  outbound proxy must have a unique realm?
> 
> 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?

> 
> > 9. The realm Issue
> >
> >  Section 22.3 of RFC 3261 says: "When multiple proxies are used in a
> >  chain, a Proxy-Authorization header field value MUST NOT 
> be consumed
> >  by any proxy whose realm does not match the "realm" parameter
> >  specified in that value".
> >
> >  Another question: Is it possible that multiple proxies 
> with the same
> >  realm are placed in a chain? I.e. the first proxy challenges, user
> >  provide correct authentication. That proxy authenticates 
> and forwards
> >  the request to a down stream proxy. That down stream proxy has the
> >  same realm as first proxy. There are a few issues here:
> 
> >  examining the nonce is the only solution.
> 
> Essentially, I think that putting two proxies in a row with the same
> realm is a difficult configuration to diagnose.  If administrators do
> this, they are asking for trouble.  But there is another approach I
> don't think you examined.
> 
> >  Another issue is at the UAC side. If 2 proxies are in a chain and
> >  share a realm, how does the UAC know, when the second proxy
> >  challenges, that it is not the first proxy re-challenging 
> because the
> >  credentials provided to it were wrong?
> 
> 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.

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

/Hisham

> 
> All this is even more reason to use qop (which was the intent of 2617
> in the first place).
> 
> -- 
> 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

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 18 Feb 2004 10:29:32 -0500

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

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

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

What difference does it make?  You just use the credentials you have in
either case, or you fail...  As I pointed out, you can tell the
difference if the server is using qop.

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

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

-- 
Scott Lawrence        
  Pingtel Corp.