[Fedsec-cg] [Idel-wg] OIDC/OA4MP Specification v0.2 - please read and comment

[Mischa Salle]

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.

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.

> >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
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 at nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4332 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/fedsec-cg/attachments/20150609/86ebca6b/attachment.bin>