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

Torsten.Lodderstedt at telekom.de Torsten.Lodderstedt at telekom.de
Fri Nov 18 11:23:22 UTC 2016


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:
> 
> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten at lodderstedt.net]
> Sent: Sunday, 16 October 2016 12:06 AM
> 
> .
> > I think it makes sense to give an high-level overview on the message
> flow among RP, new and old OP in the beginning of the document, e.g.
> after section 1.
> 
> DONE. §1.2 "Porting flow"
> 
> 
> > section 4.1:
> > - "A New OP can reuse an "enc_port_token" for logins to multiple RPs
> that share the same "sector_id", but can also calculate a separate
> "enc_port_token" for each." - Why do we need to state anything about reuse
> of encrypted porting tokens? Isn't this just an optimization? I'm concerned
> this optimization could open privacy issues if RPs use the same sector_id
> with the new OP but different sector ids with the old OP.
> 
> DONE. Deleted reuse sentences. Said New OP MUST include sector_id, which
> prevents the potentially dangerous misues.
> 
> 
> > - We should add some text saying that the payload of the porting token
> is anyway opaque to the RP so it does not need to worry about it.
> 
> DONE. §4 says enc_port_token is opaque to an RP. Only OPs have to care
> about §4.1. "Encrypting port_token".
> 
> 
> > - I think using the new OP's client secret with the old OP to derive the
> encryption key as the only option is to limited given OIDC allows to use
> assertions for authentication purposes as well. We potentially should
> come up with a consenous in the working group whether we will recommend
> public key based authentication mechanisms as an option in all our
> specs. In this case, migration should support it as well.
> 
> NOT DONE. Other options could be added, but more choices make interop
> harder.

Pls. see my arguments in my new review 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?

> 
> 
> > 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 assume the old OP uses the porting token obtained from the (even)
> older OP to create the "enc_porting_token" in the aka member? In my
> opinion, some text about this and a reference to the way encrypted
> porting tokens shall be created would helpful.
> 
> HOPEFULLY DONE. §4 "aka" explicitly talks about "aka" in id_token or a
> porting check response.

I agree :-) It should be done.

> 
> >- I was rather surprised to see an client credential flow example in the
> end of this section. I recommend to move paragraph 2 of this section and
> (even better) to an addendum.
> 
> NOT DONE. It is out of order (client cred flow is at the end of the
> section, but must be done first). But is can be done somewhat
> independently; done once, not once-per-user; is standard OAuth, not special
> to porting - so it is tacked on the end.

Then it should better go to an addendum (including a forward reference in section 5). The way it is written right now, it turns up out of order with barely any context. I think this will confuse readers.
> 
> 
> > The approach uses OAuth so there is an additional request to swap a
> client_id/client_secret for an access_token before calling the Porting
> check API. This has its cons: an extra request; reuses the RP's
> client_id/client_secret for interactive logins (code flow; acting on user's
> behalf), and backend API access (client cred flow; acting on RP's behalf).
> >
> >I think it is imperative to use the same client_id for both flows since
> the old OP needs to relate the RP on both interaction points in order to
> come up with the correct client policy and ppid. I also think the RP is
> acting on behalf of the user in both cases (although the access tokens
> might refer to different identities).
> >
> >If we want to omit the extra request, we could also turn the port
> checking API into a new grant type and use the tokens endpoint to
> retrieve the porting data.
> pros:
> - less requests
> - same response handling as for ordinary login requests (including aka
> handling!) - the porting data would be returned in the ID Token, the
> additional access token can be used to access user info at the old OP
> (if that's needed in curse of the migration)
> 
> NOT DONE.

What a surprise ;-) But what is your opinion on my idea?

> 
> --
> James Manger
> _______________________________________________
> Openid-specs-mobile-profile mailing list
> Openid-specs-mobile-profile at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-mobile-profile


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