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
