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

From: [email-masked]
Date: Fri, 6 Feb 2004 09:48:43 +0200

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.

Please read and comment.

Thanks,
Hisham

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: 05.February.2004 22:42
> Subject: I-D ACTION:draft-khartabil-sip-auth-analysis-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Analysis: HTTP Authentication for SIP
> 	Author(s)	: H. Khartabil
> 	Filename	: draft-khartabil-sip-auth-analysis-00.txt
> 	Pages		: 9
> 	Date		: 2004-2-5
> 	
> The Session Initiation Protocol (SIP) provides a stateless,
>    challenge-based mechanism for  authentication that is based on
>    authentication in HTTP. RFC 3261 fails to indicate the behaviour of
>    SIP intermediaries and User Agents in certain scenarios. This
>    documents presents such scenarios, analysis the currently available
>    text, and where possible, offers a solution.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-khartabil-sip-auth-a
nalysis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-khartabil-sip-auth-analysis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-khartabil-sip-auth-analysis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Scott Lawrence <[email-masked]>
Date: Mon, 16 Feb 2004 15:09:37 -0500

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.

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.

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

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

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

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

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