Dear IDEL-WG and FedSec-CG folks, Thought you would be interested in the following link. Please consider reading and commenting on this ongoing work by Jim Basney, Jeff Gaynor and Wendy Edwards. For further details, please see the message at the second link below. Topic: OpenID Connect for MyProxy Protocol Specification Version 0.2 (Dec 2014 - IN PROGRESS) Jim Basney <jbasney@illinois.edu> Jeff Gaynor <gaynor@illinois.edu> Wendy Edwards <wedwards@illinois.edu> Link: http://goo.gl/VnMKXS Further information: https://www.ogf.org/pipermail/idel-wg/2013-September/000011.html Alan P.S.: Happy new year!
Dear Jim, others, as discussed during the AARC meeting, here's some high-level comments on the document. 1) I would try to focuss on the MyProxy specific features. Currently a large part of the document is redescribing the standard OpenID-Connect specification/architecture which distracts. 2) As I suggested, it would be good to use the information retrieved from the userinfo endpoint to put in the CSR. As you mentioned, this gives an extra check for binding the token with the user. 3) Also I would probably demand some form of client auth (e.g. the client_secret) for the /userinfo endpoint. This is one of the things I don't like so much in the OpenID Connect spec, it leaves this auth too much open (and so does google): if someone intercepts the access token, (s)he can get all the /userinfo information. By preventing that, point 2) becomes much stronger. Personally I would have liked if OIC would use (also) the ID Token for that, since it can contain audience and authorized party restrictions, but the spec doesn't seem to want you to do that... Perhaps I don't understand the ID Token rationale sufficiently yet. 4) Likewise, doing a GET /userinfo request with an access_token in the URL is IMHO a bad idea as the token ends up in logfiles and/or leak in other ways (this is the second example at the UserInfo Request). I don't think the OIC spec mentions this, but RFC6750 mentions it in section 5.3 (last point). 5) You give an example of a /getcert request passing the CSR via a GET request in the URL. That will give problems on certain platforms due to maximum length of URLs. I would make it a POST. I think that's most of it for now... Best wishes, Mischa Sallé On Wed, Dec 31, 2014 at 11:22:39PM +0000, Sill, Alan wrote:
Dear IDEL-WG and FedSec-CG folks,
Thought you would be interested in the following link. Please consider reading and commenting on this ongoing work by Jim Basney, Jeff Gaynor and Wendy Edwards.
For further details, please see the message at the second link below.
Topic: OpenID Connect for MyProxy Protocol Specification Version 0.2 (Dec 2014 - IN PROGRESS) Jim Basney <jbasney@illinois.edu> Jeff Gaynor <gaynor@illinois.edu> Wendy Edwards <wedwards@illinois.edu>
Link: http://goo.gl/VnMKXS
Further information: https://www.ogf.org/pipermail/idel-wg/2013-September/000011.html
Alan
P.S.: Happy new year!
_______________________________________________ Idel-wg mailing list Idel-wg@ogf.org https://www.ogf.org/mailman/listinfo/idel-wg
-- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
Hi Mischa, Thanks very much for your comments on http://goo.gl/VnMKXS. We'll work on a revised version.
1) I would try to focuss on the MyProxy specific features. Currently a large part of the document is redescribing the standard OpenID-Connect specification/architecture which distracts.
For our implementation work we've found it useful to have all the protocol messages specified in a single document, but I agree if we make this an OGF specification we'd just document the GetCert endpoint since the rest is standard OIDC/OAuth.
2) As I suggested, it would be good to use the information retrieved from the userinfo endpoint to put in the CSR. As you mentioned, this gives an extra check for binding the token with the user.
I like the idea of doing some "channel binding" for the CSR in the GetCert request. I think I'd use the Subject Identifier from the ID Token so the client isn't required to call the UserInfo endpoint before calling the GetCert endpoint. I don't think we want a dependency between the GetCert and UserInfo endpoints. The client may call either UserInfo or GetCert but need not call both.
3) Also I would probably demand some form of client auth (e.g. the client_secret) for the /userinfo endpoint. This is one of the things I don't like so much in the OpenID Connect spec, it leaves this auth too much open (and so does google): if someone intercepts the access token, (s)he can get all the /userinfo information. By preventing that, point 2) becomes much stronger. Personally I would have liked if OIC would use (also) the ID Token for that, since it can contain audience and authorized party restrictions, but the spec doesn't seem to want you to do that... Perhaps I don't understand the ID Token rationale sufficiently yet.
I don't think we want to deviate from the OIDC standard's UserInfo endpoint behavior. We need to interoperate with other OIDC implementations.
4) Likewise, doing a GET /userinfo request with an access_token in the URL is IMHO a bad idea as the token ends up in logfiles and/or leak in other ways (this is the second example at the UserInfo Request). I don't think the OIC spec mentions this, but RFC6750 mentions it in section 5.3 (last point).
Thanks. Agreed. I think the final OIDC/OAuth specifications don't require us to support that, so we should drop it.
5) You give an example of a /getcert request passing the CSR via a GET request in the URL. That will give problems on certain platforms due to maximum length of URLs. I would make it a POST.
Thanks. Agreed. Regards, Jim
Hi Jim, a few more remarks, one important one, inline below. On Mon, Jun 08, 2015 at 03:25:09PM +0000, Basney, Jim wrote:
For our implementation work we've found it useful to have all the protocol messages specified in a single document, but I agree if we make this an OGF specification we'd just document the GetCert endpoint since the rest is standard OIDC/OAuth. I agree it's useful at this stage. It probably even could stay in as long as it is very clear which points are the additions.
2) As I suggested, it would be good to use the information retrieved from the userinfo endpoint to put in the CSR. As you mentioned, this gives an extra check for binding the token with the user.
I like the idea of doing some "channel binding" for the CSR in the GetCert request. I think I'd use the Subject Identifier from the ID Token so the client isn't required to call the UserInfo endpoint before calling the GetCert endpoint. I don't think we want a dependency between the GetCert and UserInfo endpoints. The client may call either UserInfo or GetCert but need not call both. Okee, that's of course equally fine, to use info from the ID Token. It only might be more in line with the spec to use the userinfo.
3) Also I would probably demand some form of client auth (e.g. the client_secret) for the /userinfo endpoint. This is one of the things I don't like so much in the OpenID Connect spec, it leaves this auth too much open (and so does google): if someone intercepts the access token, (s)he can get all the /userinfo information. By preventing that, point 2) becomes much stronger. Personally I would have liked if OIC would use (also) the ID Token for that, since it can contain audience and authorized party restrictions, but the spec doesn't seem to want you to do that... Perhaps I don't understand the ID Token rationale sufficiently yet.
I don't think we want to deviate from the OIDC standard's UserInfo endpoint behavior. We need to interoperate with other OIDC implementations. see above. Especially for the getcert this must somehow be better
One very important point, which David (Groep) and I discussed this afternoon: there currently isn't any protection, unless I'm missing something, against a malicious user obtaining a valid certificate using a stolen token and a CSR and key-pair he created. That would give him a valid certificate in some else's name, for which he owns the private key. OAuth2.0 tokens aren't the best protected secrets typically, as they are passed around. If they never leave the client in this scenario, apart from being send to the getcert endpoint, it is probably still manageable, but I think it would certainly be better to demand some form of client authentication. If it is the client in any case, then it already has the client_secret, so you could then demand that the client authenticates using client_id and client_secret to the getcert endpoint. Restricting it to the specific client is probably what you want to do in any case? An encrypted ID token, which is encrypted with a public key used by the getcert endpoint could also solve this (the ID token can contain a nonce set at the auth request time) but I think that's against the spec: the client also must be able to read it, and the malicious user can obtain the nonce. As far as I understood, the SURFnet APIS also demands client_id+client_secret for accessing the /userinfo endpoint. I don't think it's per-se against the OIC spec, the SPEC basically leaves it open. protected then only via an access token. The good thing is that you are writing the spec for that endpoint (-;
4) Likewise, doing a GET /userinfo request with an access_token in the URL is IMHO a bad idea as the token ends up in logfiles and/or leak in other ways (this is the second example at the UserInfo Request). I don't think the OIC spec mentions this, but RFC6750 mentions it in section 5.3 (last point).
Thanks. Agreed. I think the final OIDC/OAuth specifications don't require us to support that, so we should drop it. I think it might be required for some of the flows, not for all...
Best wishes, Mischa -- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
Hi Mischa, Thanks again for the comments. I've started to update http://goo.gl/VnMKXS based on our discussion.
One very important point, which David (Groep) and I discussed this afternoon: there currently isn't any protection, unless I'm missing something, against a malicious user obtaining a valid certificate using a stolen token and a CSR and key-pair he created. That would give him a valid certificate in some else's name, for which he owns the private key. OAuth2.0 tokens aren't the best protected secrets typically, as they are passed around. If they never leave the client in this scenario, apart from being send to the getcert endpoint, it is probably still manageable, but I think it would certainly be better to demand some form of client authentication. If it is the client in any case, then it already has the client_secret, so you could then demand that the client authenticates using client_id and client_secret to the getcert endpoint. Restricting it to the specific client is probably what you want to do in any case?
Yes, I'm convinced. :) If I understand correctly it means that GET requests to the GetCert endpoint will contain two Authorization headers, one of type Basic containing the client_id and client_secret and another of type Bearer containing the access_token. However, as previously discussed, we prefer POST requests to the GetCert endpoint, in which case client_id, client_secret, and access_token are included in the application/x-www-form-urlencoded body. I've updated http://goo.gl/VnMKXS to match my understanding. Regards, Jim
On Wed, Jun 10, 2015 at 06:32:40PM +0000, Basney, Jim wrote:
Hi Mischa,
Thanks again for the comments. I've started to update http://goo.gl/VnMKXS based on our discussion. Hi Jim,
great! I'll have a look in detail later (probably during TNC).
Yes, I'm convinced. :)
If I understand correctly it means that GET requests to the GetCert endpoint will contain two Authorization headers, one of type Basic containing the client_id and client_secret and another of type Bearer containing the access_token. However, as previously discussed, we prefer POST requests to the GetCert endpoint, in which case client_id, client_secret, and access_token are included in the application/x-www-form-urlencoded body. I've updated http://goo.gl/VnMKXS to match my understanding.
I think that sounds fine. One remark: is it allowed to have multiple Authorization headers? It's not entirely clear from https://tools.ietf.org/html/rfc7235#section-4.2 I think it's probably not intended, as it explicitly mentions in 4.1 that there can be multiple WWW-Authenticate headers... For a POST this is obviously not an issue. Also, putting the client_secret in a GET is generally not a good idea for the same reasons as we discussed before (ends up in logfiles, browser caches etc.). Best wishes, Mischa -- Nikhef Room H155 Science Park 105 Tel. +31-20-592 5102 1098 XG Amsterdam Fax +31-20-592 5155 The Netherlands Email msalle@nikhef.nl __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
participants (3)
-
Basney, Jim -
Mischa Salle -
Sill, Alan