[Openid-specs-mobile-profile] Issue #50: Authenticate RP to Old OP during porting (openid/mobile)

Arne Georg Gleditsch argggh at telenordigital.com
Fri Nov 18 15:21:04 UTC 2016

Hi guys,

Comments inline:

On Fri, Nov 18, 2016 at 12:23 PM, <Torsten.Lodderstedt at telekom.de> wrote:

> James,
> see inline.
> best regards,
> Torsten.
> > -----Ursprüngliche Nachricht-----
> > Von: Openid-specs-mobile-profile [mailto:openid-specs-mobile-profile-
> > bounces at lists.openid.net] Im Auftrag von Manger, James
> > Gesendet: Sonntag, 13. November 2016 21:17
> > An: Torsten Lodderstedt; openid-specs-mobile-profile at lists.openid.net
> > Betreff: Re: [Openid-specs-mobile-profile] Issue #50: Authenticate RP to
> > Old OP during porting (openid/mobile)
> >
> > Torsten,
> >
> > draft-account-porting version 03 fixes some of your comments:
> > > - "SHOULD verify that the "sector_id" from the JWE header (if present)
> > matches the value for the RP. The only exception to this is when the Old
> > OP uses public Subject Ids and does not know the "sector_id"." I think
> > this could be to restrictive. The purpose of this member was to identify
> > attempts of a single RP to obtain multiple (ppid) subject values using
> > the same porting token (even if we need to assume the sector_id is not
> > excactly the same). As far as I remember the idea was to at least check
> > the host component of the sector id for equality (or to use other shared
> > knowledge about the RP for that purpose).
> >
> > MAYBE DONE. The spec matches sector_ids (domain names), not
> > sector_identifier_uris (scheme+domain+path).
> Looks good to me
> @John, Arne: Can you please check?

Okay, so in any case we protect against exposure of pairwise subject ids to
random RPs, as the subject id returned will always be scoped according to
the client id that the RP authenticates towards the Old OP with.  However,
if a nefarious entity is in control of several RPs (with different sector
ids), they could conceivably pass the same enc_port_token around and derive
subject ids for all it's RPs, effectively linking the user's account at the
different RPs.  Right?  I suspect there are likely to be other ways an
entity like that can do this, but if we enforce the requirement as it
stands in section 5, at least we have a first line of defense.  I don't
think it's too strict, and I don't think we have any other candidates for
"shared knowledge about the RP". Looks good to me.

> > section 5
> > - I think the iss should be contained in the porting data along with the
> > subject sub as it is always being interpreted in the context of this
> > particular iss.
> >
> > NOT DONE. If "iss" is part of the Old OP's response it introduces the
> risk
> > that a malicious Old OP returns another OP's "iss". So RPs would have to
> > check that "iss" was the expected value (in which case, why not just use
> > the expected value the RP knows). The one benefit of returning "iss" (and
> > the RP checking it) is it prevents a malicious OP putting a
> > port_check_endpoint in its metadata that points to another OP's Porting
> > check API. I'm not sure if that is bad or irrelevant.
> I think mix up is an example of this class of attacks. I recommend to
> reconsider it and would like to know the opinion of other WG members.

I agree that I don't see any avenues to exploit this.  I have no strong
opinions either way on this one, but as James says introducing information
redundancy that must be verified at the RP end is also a way of increasing
the attack surface, as it were, since attackers can then try to exploit
weaknesses in the consistency checking of the RPs.

Language nitpicks:

   - 1.2, first bullet list, point 1: "User browsers to"
   - 1.3, second bullet list, point 3, "an version"
   - 6, extra : after "Old OP has:"
   - 7, Attackers -> Attacker's,  victims -> victim's, analysis -> analyses

All in all I'm really happy with the way this spec is turning out, let's
get it out there. :)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-mobile-profile/attachments/20161118/a9b66b4c/attachment.html>

More information about the Openid-specs-mobile-profile mailing list