OK, based on a private discussion on this topic with John, I’m
going to suggest that we change the language “The IP/STS MAY use
this value as-is or as an input seed to a custom function to derive a value for
the PPID claim” to “The IP/STS SHOULD combine this PPID seed
value with constant information known to the IP/STS and pass the combination
through a cryptographically non-invertible function, such as a cryptographic
hash function, to generate the PPID claim value sent in the signed token”.
--
Mike
From: John Bradley
[mailto:jbradley@mac.com]
Sent: Wednesday, January 07, 2009 1:02 PM
To: imi@lists.oasis-open.org
Subject: Re: [imi] Clarifications to the spec to discuss for our call on
Thursday
<snip>
On 7-Jan-09, at 5:17 PM, Michael McIntosh wrote:
John Bradley <jbradley@mac.com> wrote on 01/07/2009
02:21:00 PM:
>
> <inline>
> On 7-Jan-09, at 1:18 PM, Michael McIntosh wrote:
>
> > John Bradley <jbradley@mac.com>
wrote on 01/07/2009 11:00:04 AM:
> >
> > <snip>
> > >
> > > However a IP/STS trusting a PPID coming from a selector has
always
> > > made me a bit nervous. I could as an example modify
the Higgins
> > > selector to send arbitrary PPID values in a RST. If
the IP/STS say
> > > Verisign blindly includes it in its signed response the RP
checking
> > > the PPID and sig as it would for a p-card could be spoofed
if it was
> > > relying solely on those two values.
> > >
> > > Including a pre-calculated PPID may make some IP/STS lazy
and not
> > > calculate it themselves when they clearly can.
> > >
> > > Minimally I think the PPID coming from the selector should
be used
> > > as input to some other hash function to at-least make
spoofing
> > more difficult.
> > >
> > > I know the spec allows for using the PPID as input to a
custom
> > > function, but I have never seen an explanation of why
that is a
> > good idea.
> > >
> > > I am OK with always including the PPID in the request if
someplace
> > > we document the security issues around PPID in m-cards.
> >
> > In order for the IdP to compute the PPID, it needs to know the RP
ID.
> > A user may not want to tell the IdP the name of every site they
visit.
> >
> Agreed that is why we have the two options though they are at the
> discretion of the card issuer not the user.
Not completely.
The IdP (AKA Card Issuer) gets to specify
whether the RP identity is required, not required, or optional - and that
information is in the card and/or IdP metadata (I forget which).
The RP gets to specify whether or not a
specific IdP is required, or whether any is acceptable.
The user gets to select which card (and
therefore which IdP) will be used.
If a user does not want to use a card that
requires disclosure of RP identity to the IdP, it can choose another card.
If the only cards the user has that match
the RP policy are cards that require RP disclosure, the user can go elsewhere.
As far as I know there is nothing in the selector that tells
the user that it is going to disclose the identity of the RP to the IdP.
So I agree that in principal the user is free to select any
card that matches the required claims but if they have two cards one
auditing and one not they have no easy way to distinguish between them.
I have to go back and look at how optional auditing mode
works that is a new one to me.
As near as I can see with current selectors the power is in
the hands of the IdP, unless I am missing something.
|