Re: [imi] Clarifications to the spec to discuss for our call on Thursday

[Michael McIntosh <mikemci@us.ibm.com>]

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.

> >
> > If the User's client computes a partial ClientPsuedonym as input to  
> > the PPID computation,
> > a proper PPID can be computed by the IdP,
> > assuming it also includes some additional user specific "secret"  
> > into the computation,
> > without letting the IdP know the RP.
> >
> >
> True we just need to make certain that issuers understand that.

Yes we do.

> > Any RP that blindly accepts a PPID and not a signed PPID+Issuer Key  
> > as the User's identifier is looking for trouble.
> > Any user can set up an Issuer to generate a token with any PPID.
> >
> Agreed I think people are a bit clearer on this point.  However as you  
> point out if the IdP is doing something stupid generating the PPID  
> then the RP would be none the wiser even if it is doing the correct  
> thing and checking PPID+Issuer Key.

There is nothing the RP can do to prevent IdP stupidity, other than refusing to accept tokens issued by that IdP.
Stupidity in IdPs can manifest itself in many ways and this is only one of them.

> > Any IdP that blindly returns the ClientPsuedonym as the PPID is  
> > looking for trouble.
> > Any user with an account on that same IdP can send another user's  
> > ClientPsuedonym and get a token from the IdP.
> >
> >
> However the spec allows the IdP to do exactly that "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"
>
> We may want to have some words regarding the use of the value as is  
> has potential security issues.
>
> My only concern around Mike J's proposed change is that it now  
> potentially allows the IP/STS to use the value as-is as opposed to  
> calculating it itself for auditing mode cards.
>
> Yes a IP/STS would have to be stupid to do that but they are out  
> there,  we should have a word of warning why it is a bad idea.

Agreed. We cannot prevent IdP stupidity but we can explain why its bad to trust stupid IdPs.
 
> > > Mike Jones <Michael.Jones@microsoft.com>
> > >
> > > In practice, the IssuerId is only used for managed cards backed by
> > > self-issued cards. Therefore, I propose to change “The element
> > > content may be empty” to “The element content may be empty when the
> > > card is not a managed card backed by a self-issued card” and to  
> > change “The
> > > ic:IssuerId value SHOULD be the empty string for self-issued  
> > cards” to “The
> > > ic:IssuerId value SHOULD be the empty string for self-issued cards
> > > and MUST NOT be empty for managed cards backed by self-issued  
> > cards”.
> > >
> >
> > I don't agree. There are some IdP endpoints hosting multiple logical  
> > Issuers (different signing keys) that need this value to determine  
> > the correct Issuer.
> >
> >
> Yes I think Parity is doing that with card press now that you mention  
> it.
> > > 3. Clarifying that self-issued cards support the PPID claim even
> > > though not listed as an ic:SupportedClaimType element
> > >
> > > I have recently learned that even though all self-issued cards
> > > support the PPID claim, when self-issued cards are written to the
> > > Information Cards Transfer Format (a .crds file), the PPID claim is
> > > not listed as a SupportedClaimType in the card’s
> > > SupportedClaimTypeList. I propose that we document this anomaly in
> > > the specification so implementations behave consistently.
> >
> > Why not just add the ClaimType for PPID? I agree with Tony that  
> > there might need to be multiple PPID algorithms supported and maybe  
> > the claim type would need to specify the algorithm(s) supported.
> >
> =jbradley