Re: [Sipping] Decision needed on final issue with draft-ietf-sipping-update-pai-07

[Dean Willis <dean.willis at softarmor.com>]

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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP