Re: [rtcweb] IdP and universal trust

There is a more basic problem here, which is that "legacy" scenarios are typically about reaching an E.164 number.   Given that IdP (or PKI for that matter) cannot be used to prove ownership of an E.164 number, such as +14255551212@example.com, it is difficult to see how identity can be provided by any mechanism for the legacy cases, and MITM attacks seem intrinsic to the scenario.  For example, +14255551212@example.com is equivalent to +14255551212@eviltwin.example.net so that first-party IdPs are not authoritative for E.164 numbers, and MITM attacks have long been acknowledged as possible within the SIP DTLS/SRTP framework (e.g. eviltwin.example.net can change the E.164 URI and resign the message via RFC 4474 without being detected).

On Mar 29, 2012, at 13:26, "Martin Thomson" <martin.thomson@gmail.com> wrote:

> On 29 March 2012 08:08, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
>> Yeah I've been trying to figure out if there's some advantage to having a gateway be able to indicate "gateway@telco.com", once there is an IdP model.  I would think it's a major pita to deploy such a thing on gateways, unless there's a very popular IdP they could know everyone would trust.  It would actually be easier to just give the gateway a real TLS cert for DTLS to use, from a major CA, since gateways are the types of systems real certs would be reasonably possible to install on.
> 
> This is an important point, and I think that perhaps you missed the
> distinction. Iff third party assertions are permitted, then the
> problem that you refer to - namely, finding someone that others trust
> - is somewhat difficult.  On the other hand, it is also true that you
> can gain multiple assertions and increase the chances of finding an
> acceptable IdP.
> 
> What seems more likely is that IdPs are only going to be authoritative
> for their own domain.  The overall story is a lot easier to tell.
> This has the nice quality that you don't have to trust the IdP, you
> only have to trust their CA.
> 
> --Martin
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb