Subject: RE: [Sip] Open Issue #164: Proxy-Authentication-Info

From: "Sanjoy Sen" <[email-masked]>
Date: Thu, 6 Dec 2001 16:19:38 -0600

Jonathan,

   From reading RFC 2617 (Sec 3.6), I had the impression that
Proxy-Authentication-Info is used by the origin server (which maps to UAS in
SIP) in responses towards the Proxy. Sec 3.6 reads:
"  On subsequent responses, the server sends Proxy-Authentication-Info
   with directives the same as those for the Authentication-Info header
   field. " 
Actually, I'm not sure, on reading the RFC, what header should be used in
this case - it seems that Authentication-Info and Proxy-Authentication-Info
are used by the server to authenticate itself to the client and Proxy,
respectively. I've mentioned this in the
draft-sen-sipping-onehop-digest-00.txt.

  Anyway, if the problem of distinguishing multiple
Proxy-Authentication-Info header needs to be solved, I would support
approach (3), since (1) this (multiple Proxies) would be a SIP specific case
(or does HTTP need this too?) and (2) there's no standard's change.

Thanks,
Sanjoy

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 11:37 PM
> To: [email-masked]'
> Subject: [Sip] Open Issue #164: Proxy-Authentication-Info
> 
> 
> Issue:
> 
> bis-05 does not use Proxy-Authentication-Info. This response 
> header, defined
> in rfc2617, allows for mutual authentication between a client 
> and proxies.
> THe header is not used since it has a flaw that is bad for 
> SIP - it appears
> to assume a single proxy. This is because it omits the realm 
> as a parameter.
> From the brief amount of text about 
> Proxy-Authenticatiopn-Info, it appears
> that it was added as an afterthought, and this issue was not 
> considered.
> Thus, if a UAC gets a 2xx response that came through three 
> proxies, and each
> of them inserted a Proxy-Authentication-Info header, the UAC 
> would not be
> able to determine which header is for which proxy. 
> 
> Discussion:
> 
> This header can either be:
> 
> (1) omitted entirely, so that mutual auth between client and 
> proxy is not
> possible
> (2) it can be fixed. The fix is to simply extend the header 
> and add the
> requisite realm parameter. 
> (3) we can instead use the nonce to distinguish the headers. The
> Proxy-Authorization headers in the request would each contain 
> a DIFFERENT
> cnonce for each proxy that is being challenged. The proxies 
> mirror this
> cnonce in the response. The UAC can therefore use the cnonce 
> to figure out
> which header is for which proxy. 
> 
> Although (3) is somewhat ugly, it is the least amount of 
> work, as it allows
> us to directly use rfc2617, with some additional explanatory 
> text. I believe
> mutual auth between client and server is important. 
> Therefore, the proposal
> is:
> 
> Proposal:
> 
> Take approach (3), which allows Proxy-Authentication-Info, 
> but document the
> issue with cnonce as a selection parameter. 
> 
> -Jonathan R.
> 
> 
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>  
> 
> _______________________________________________
> Sip mailing list  http://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: "Sanjoy Sen" <[email-masked]>
Date: Thu, 6 Dec 2001 18:01:53 -0600

> From: Michael Thomas [mailto:[email-masked]]
> 
>    What I'm most worried about is diverting energy
>    -- which is already in pretty low supply -- away
>    from dealing with the long term security needs
>    for SIP. Also: the more we hack on old stuff,
>    the more confusing it's going to be for
>    developers/deployers to choose sensibly. It's
>    relatively easy at this point to say that HTTP
>    authentication is vestigial and leave it at
>    that; but if we start adding SIP specific
>    fixes, we're going to have to figure out how
>    it interoperates with anything new, how we know
>    when to stop fixing it, etc, etc. It make my
>    head hurt.
> 
HTTP Digest is widely, widely supported. There's a huge 
benefit from software reuse point of view. Granted it does not solve
all problems, but it does solve some critical ones well - such as
authentication,
replay protection etc. If the fixes are small (as they appear to be), we get
a cheap, lightweight solution applicable to many scenarios. 

My 0.5 cents.