Hopefully last change to the IMI spec before producing a CommitteeDraft

[Mike Jones <Michael.Jones@microsoft.com>]

In reviewing the IMI spec draft, one of our security experts identified a non-protocol security issue in the present draft that I believe we should address.  Fortunately, it’s a very simple and, I suspect, non-controversial change to fix.

 

The proposed change in Section 3.3.4 (Client Pseudonym) is to change the sentence:

The IP/STS SHOULD combine this Client Pseudonym 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 token.

to:

The IP/STS SHOULD combine this Client Pseudonym value with user-specific information and 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 token.

 

Here’s an explanation of why this change is a good idea…

 

IMIv1 (and similarly, in ISIP) specify in section 3.3.4 that, when generating a PPID value from Client Pseudonym: "The IP/STS SHOULD combine this Client Pseudonym 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 token."

 

This could lead to a security vulnerability if the IP/STS uses the Client Pseudonym value "as-is", or if only a constant is used as input to the function. Indeed, if malicious Bob learns Alice's ClientPseudonym value for a RP, it can authenticate as Bob to the IP/STS and requests Alice's PPID value. This would not be detected by the IP/STS because the spec states that the IP/STS MUST NOT record the received Client Pseudonyms and the generated PPID values (and therefore can’t verify that it issues consistent PPID values per user).

 

For these reasons, the text above should be modified as follows:

 

 "The IP/STS ***MUST NOT use the value as-is, it*** SHOULD combine this Client Pseudonym value with constant information known to the IP/STS ***and a unique user identifier*** 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 token."

 

I’ve also discussed this change with John Bradley, who was the one who pointed out that it was a bad idea to use the Client Pseudonym value verbatim in the first place, and he agrees with this additional to our guidance to Identity Providers.

 

Talk to all of you in the morning!

 

                                                                -- Mike