i think Keith is working the same issue I am. His text should resolve
the immediate concern.
--
Dean
On Oct 25, 2008, at 9:56 AM, Elwell, John wrote:
Dean,
I am looking for somebody to provide some text that could replace or
add
to the text in section 3.3, paragraph beginning "Section 5 of RFC 3325
requires". I spoke to Keith yesterday and I think he will try to do
so.
Nobody objected to the consensus call to remove the response stuff,
and
therefore as editor I removed it. As much as I personally would like
to
include PAI in responses in this draft, I have to go along with the WG
consensus, which, until a couple of days ago was to remove it.
If somebody wants to have it re-instated, they should provide the text
AND convince those who objected to the existing text. I am not going
to
take the lead.
John
-----Original Message-----
From: Dean Willis [mailto:dean.willis@xxxxxxxxxxxxx]
Sent: 24 October 2008 22:46
To: Elwell, John
Cc: DRAGE, Keith (Keith); sipping@xxxxxxxx
Subject: Re: Decision needed on final issue with
draft-ietf-sipping-update-pai-07
On Oct 24, 2008, at 7:55 AM, Elwell, John wrote:
[JRE] This was the example given in earlier drafts, and removed
because
it is broken. There is nothing to bind together the entity
authenticated
by digest and the entity terminating TLS. A request certainly has to
come via the entity that terminates TLS, but this need not
be the same
entity that originates the request. So we could have the following
situation:
+-----+
| UA1 +--------+
+-----+ | +---------+ +---------+
+--------+ | | |
| Proxy 1 +--------+ Proxy 2 |
+--------| | | |
+-----+ | +---------+ +---------+
| UA2 +--------+
+-----+
Proxy 2 accepts an inbound TLS connection and over that
receives a SIP
request, which it challenges. The next SIP request contain correct
credentials for UA1. Proxy 2 then receives a further SIP
request. How
does it know that it comes from UA1 and not UA2, say? In
other words,
how does proxy 2 know that there is a proxy 1 (or some
other form of
SIP
intermediary) between it and UA1?
This scenario drove the requirement for a "P-Asserted-By" header, so
the transitivity could be tracked. We don't have that header
defined . . .
However, there are architectures for which the UA can issue a valid
digest in the response, since the "challenge" per se is
handled at the
SIM level.
--
Dean
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
