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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 6 Dec 2001 00:36:49 -0500

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: Michael Thomas <[email-masked]>
Date: Thu, 6 Dec 2001 11:30:33 -0800 (PST)

> able to determine which header is for which proxy. 

   My general preference would be to stop putting bandaids
   on hacks and do this right. I guess that means I favor
   option (1).

		Mike

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 6 Dec 2001 22:55:15 +0200

>    on hacks and do this right. I guess that means I favor

I'm in favor of 'doing this right' but I think I disagree about whether
(1) is the right thing, given its hBh nature. I think we should have
e2e and e2m authentication and possibly integrity/encryption. I
think in this particular case Digest could be fixed but if folks are
starting to get tired of the bandaids on it, I'd also be happy with a completely
rewritten mechanism -- maybe based on the preshared key crypto system
that you had Mike on your framework draft, or similar.

Jari

---

From: Michael Thomas <[email-masked]>
Date: Thu, 6 Dec 2001 15:33:57 -0800 (PST)

> that you had Mike on your framework draft, or similar.

   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.

	Mike