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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Dec 2001 04:13:39 -0600

I definitely agree that mutual authentication overall seems to have been an
afterthought in rfc2617; the focus of the document is clearly on
undirectional (server authenticates client) operations. Moreover, rfc2617
states that Proxy-Authenticate and Proxy-Authorization are hBh, not e2e, and
that undoubtedly removes the need for any differentiation of challenge
responses.

I suppose the argument could be made that if you want to perform mutual
authentication, you should defer to an external mechanism like TLS or IPSec
rather than using the built-in auth mechanism - that might soften the blow
of selecting (1).

But that much said, I agree that cnonce should be sufficient for the client
to differentiate Proxy-Authentication-Infos from various servers. It does
seem kind of awkward to use realms to differentiate challenge responses in
one direction and cnonces to differentiate them in another, but on balance
it's probably worth it.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 9: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
> 

_______________________________________________
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: "Jari Arkko" <[email-masked]>
Date: Thu, 6 Dec 2001 12:40:59 +0200

> rather than using the built-in auth mechanism - that might soften the blow

That would be otherwise fine, but it's hBh. I think we should fix digest auth,
ie pick alternative (2).

Jari

---

From: "James Undery" <[email-masked]>
Date: Thu, 6 Dec 2001 15:07:57 -0000

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jari
> Arkko
> Sent: 06 December 2001 10:41
> To: Peterson, Jon; 'Jonathan Rosenberg'
> Cc: [email-masked]
> Subject: Re: [Sip] Open Issue #164: Proxy-Authentication-Info
>
>

I'd agree with Jari here as I'd also like to "fix" Authentication-Info as
currently it only applies to digest authentication and making it more like
WWW-Authenticate (in terms of flexibility) would be nice.

Also TLS/IPSec are first hop rather than hBh solutions in the terms of
authentication Proxy-Authenticate/Proxy-Authentication-Info provides.
(Although they still form an important yet different role.)

James