<div dir="ltr">Hi guys,<br><br>Comments inline:<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 18, 2016 at 12:23 PM,  <span dir="ltr"><<a href="mailto:Torsten.Lodderstedt@telekom.de" target="_blank">Torsten.Lodderstedt@telekom.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">James,<br>
<br>
see inline.<br>
<br>
best regards,<br>
Torsten.<br>
<br>
> -----Ursprüngliche Nachricht-----<br>
> Von: Openid-specs-mobile-profile [mailto:<a href="mailto:openid-specs-mobile-profile-">openid-specs-mobile-<wbr>profile-</a><br>
> <a href="mailto:bounces@lists.openid.net">bounces@lists.openid.net</a>] Im Auftrag von Manger, James<br>
> Gesendet: Sonntag, 13. November 2016 21:17<br>
> An: Torsten Lodderstedt; <a href="mailto:openid-specs-mobile-profile@lists.openid.net">openid-specs-mobile-profile@<wbr>lists.openid.net</a><br>
> Betreff: Re: [Openid-specs-mobile-profile] Issue #50: Authenticate RP to<br>
> Old OP during porting (openid/mobile)<br>
><br>
> Torsten,<br>
><br>
> draft-account-porting version 03 fixes some of your comments:<br>> > - "SHOULD verify that the "sector_id" from the JWE header (if present)<br>
> matches the value for the RP. The only exception to this is when the Old<br>
> OP uses public Subject Ids and does not know the "sector_id"." I think<br>
> this could be to restrictive. The purpose of this member was to identify<br>
> attempts of a single RP to obtain multiple (ppid) subject values using<br>
> the same porting token (even if we need to assume the sector_id is not<br>
> excactly the same). As far as I remember the idea was to at least check<br>
> the host component of the sector id for equality (or to use other shared<br>
> knowledge about the RP for that purpose).<br>
><br>
> MAYBE DONE. The spec matches sector_ids (domain names), not<br>
> sector_identifier_uris (scheme+domain+path).<br>
<br>
Looks good to me<br>
@John, Arne: Can you please check?<br></blockquote><div><br></div><div>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. <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > section 5<br>
> - I think the iss should be contained in the porting data along with the<br>
> subject sub as it is always being interpreted in the context of this<br>
> particular iss.<br>
><br>
> NOT DONE. If "iss" is part of the Old OP's response it introduces the risk<br>
> that a malicious Old OP returns another OP's "iss". So RPs would have to<br>
> check that "iss" was the expected value (in which case, why not just use<br>
> the expected value the RP knows). The one benefit of returning "iss" (and<br>
> the RP checking it) is it prevents a malicious OP putting a<br>
> port_check_endpoint in its metadata that points to another OP's Porting<br>
> check API. I'm not sure if that is bad or irrelevant.<br>
<br>
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.<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>Language nitpicks: <br><div><div><div><ul><li>1.2, first bullet list, point 1: "User browsers to"</li><li>1.3, second bullet list, point 3, "an version"</li><li>6, extra : after "Old OP has:"</li><li>7, Attackers -> Attacker's,  victims -> victim's, analysis -> analyses</li></ul><p>All in all I'm really happy with the way this spec is turning out, let's get it out there. :)</p><p>BR,</p><p>Arne.</p><p><br></p></div></div></div></div></div></div></div></div>