[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [imi] Hopefully last change to the IMI spec before producing aCommittee Draft
--Apple-Mail-153--996969314
Content-Type: multipart/alternative;
boundary=Apple-Mail-152--996969397
--Apple-Mail-152--996969397
Content-Type: text/plain;
charset=WINDOWS-1252;
format=flowed;
delsp=yes
Content-Transfer-Encoding: quoted-printable
My recommendation at Parity was to store some seed material on a per =20=
card basis in the STS. This would be seeded at card issuance from =20
some entropy source.
I think that this needs to be covered in the explanatory =20
documentation. To properly encourage IdPs to follow this advice. We =20=
can be more verbose there.
I am OK with the proposed change. However if Tony would be happier =20
with "card-specific information" I am OK with that.
The important points are that it is card specific entropy stored by =20
the IdP and never disclosed to RPs in any way.
John B.
On 18-Feb-09, at 10:28 PM, Anthony Nadalin wrote:
> I don't think that wording is right or conveys what the issue =20
> brought up over a year ago at various meetings, as user-specific =20
> information as this can mean static well known user-specific =20
> information which is not what we want, what we want is entropy from =20=
> the user/client (and user is not right term either as may not have a =20=
> user may have a process/client/device, etc)
>
> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
>
> <graycol.gif>Mike Jones ---02/18/2009 06:00:38 PM---In reviewing the =20=
> IMI spec draft, one of our security experts identified a non-=20
> protocol security issue in the present draft that
>
> <ecblank.gif>
> From: <ecblank.gif>
> Mike Jones <Michael.Jones@microsoft.com>
> <ecblank.gif>
> To: <ecblank.gif>
> "imi@lists.oasis-open.org" <imi@lists.oasis-open.org>
> <ecblank.gif>
> Date: <ecblank.gif>
> 02/18/2009 06:00 PM
> <ecblank.gif>
> Subject: <ecblank.gif>
> [imi] Hopefully last change to the IMI spec before producing a =20
> Committee Draft
>
>
>
> In reviewing the IMI spec draft, one of our security experts =20
> identified a non-protocol security issue in the present draft that I =20=
> believe we should address. Fortunately, it=92s a very simple and, I =20=
> suspect, non-controversial change to fix.
>
> The proposed change in Section 3.3.4 (Client Pseudonym) is to change =20=
> the sentence:
> The IP/STS SHOULD combine this Client Pseudonym value with constant =20=
> information known to the IP/STS and pass the combination through a =20
> cryptographically non-invertible function, such as a cryptographic =20
> hash function, to generate the PPID claim value sent in the token.
> to:
> The IP/STS SHOULD combine this Client Pseudonym value with user-=20
> specific information and constant information known to the IP/STS =20
> and pass the combination through a cryptographically non-invertible =20=
> function, such as a cryptographic hash function, to generate the =20
> PPID claim value sent in the token.
>
> Here=92s an explanation of why this change is a good idea=85
> IMIv1 (and similarly, in ISIP) specify in section 3.3.4 that, when =20
> generating a PPID value from Client Pseudonym: "The IP/STS SHOULD =20
> combine this Client Pseudonym value with constant information known =20=
> to the IP/STS and pass the combination through a cryptographically =20
> non-invertible function, such as a cryptographic hash function, to =20
> generate the PPID claim value sent in the token."
>
> This could lead to a security vulnerability if the IP/STS uses the =20
> Client Pseudonym value "as-is", or if only a constant is used as =20
> input to the function. Indeed, if malicious Bob learns Alice's =20
> ClientPseudonym value for a RP, it can authenticate as Bob to the IP/=20=
> STS and requests Alice's PPID value. This would not be detected by =20
> the IP/STS because the spec states that the IP/STS MUST NOT record =20
> the received Client Pseudonyms and the generated PPID values (and =20
> therefore can=92t verify that it issues consistent PPID values per =20
> 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 =20
> this Client Pseudonym value with constant information known to the =20
> IP/STS ***and a unique user identifier*** and pass the combination =20
> through a cryptographically non-invertible function, such as a =20
> cryptographic hash function, to generate the PPID claim value sent =20
> in the token."
>
> I=92ve also discussed this change with John Bradley, who was the one =20=
> who pointed out that it was a bad idea to use the Client Pseudonym =20
> value verbatim in the first place, and he agrees with this =20
> additional to our guidance to Identity Providers.
>
> Talk to all of you in the morning!
>
> -- Mike
>
--Apple-Mail-152--996969397
Content-Type: text/html;
charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; =
"><br><div><br></div><div>My recommendation at Parity =
was to store some seed material on a per card basis in the STS. =
This would be seeded at card issuance from some entropy =
source.</div><div><br></div><div>I think that this needs to =
be covered in the explanatory documentation. =
To properly encourage IdPs to follow this advice. We can be =
more verbose there.</div><div><br></div><div>I am OK with the proposed =
change. However if Tony would be happier with =
"card-specific information" I am OK with =
that.</div><div><br></div><div>The important points are that it is card =
specific entropy stored by the IdP and never disclosed to RPs in any =
way.</div><div><br></div><div>John B.</div><div><br><div><div>On =
18-Feb-09, at 10:28 PM, Anthony Nadalin wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><p>I =
don't think that wording is right or conveys what the issue brought up =
over a year ago at various meetings, as <font color=3D"#FF0000" =
face=3D"Calibri">user-specific information </font>as this can mean =
static well known <font color=3D"#FF0000" face=3D"Calibri">user-specific =
information</font> which is not what we want, what we want is entropy =
from the user/client (and user is not right term either as may not have =
a user may have a process/client/device, etc)<br> <br> Anthony Nadalin | =
Work 512.838.0085 | Cell 512.289.4122<br> <br> =
<span><graycol.gif></span><font color=3D"#424282">Mike Jones =
---02/18/2009 06:00:38 PM---In reviewing the IMI spec draft, one of our =
security experts identified a non-protocol security issue in the present =
draft that</font><br> <br> <table width=3D"100%" border=3D"0" =
cellspacing=3D"0" cellpadding=3D"0"> <tbody><tr valign=3D"top"><td =
width=3D"1%"><span><ecblank.gif></span><br> <font size=3D"2" =
color=3D"#5F5F5F">From:</font></td><td =
width=3D"100%"><span><ecblank.gif></span><br> <font size=3D"2">Mike =
Jones <<a =
href=3D"mailto:Michael.Jones@microsoft.com";>Michael.Jones@microsoft.com</a=
>></font></td></tr> <tr valign=3D"top"><td =
width=3D"1%"><span><ecblank.gif></span><br> <font size=3D"2" =
color=3D"#5F5F5F">To:</font></td><td =
width=3D"100%"><span><ecblank.gif></span><br> <font size=3D"2">"<a =
href=3D"mailto:imi@lists.oasis-open.org";>imi@lists.oasis-open.org</a>" =
<<a =
href=3D"mailto:imi@lists.oasis-open.org";>imi@lists.oasis-open.org</a>></fo=
nt></td></tr> <tr valign=3D"top"><td =
width=3D"1%"><span><ecblank.gif></span><br> <font size=3D"2" =
color=3D"#5F5F5F">Date:</font></td><td =
width=3D"100%"><span><ecblank.gif></span><br> <font =
size=3D"2">02/18/2009 06:00 PM</font></td></tr> <tr valign=3D"top"><td =
width=3D"1%"><span><ecblank.gif></span><br> <font size=3D"2" =
color=3D"#5F5F5F">Subject:</font></td><td =
width=3D"100%"><span><ecblank.gif></span><br> <font size=3D"2">[imi] =
Hopefully last change to the IMI spec before producing a Committee =
Draft</font></td></tr> </tbody></table> </p><hr width=3D"100%" size=3D"2" =
align=3D"left" noshade=3D"" style=3D"color:#8091A5; "><br> <br> <br> =
<font face=3D"Calibri">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=92s a very =
simple and, I suspect, non-controversial change to fix.</font><br> <font =
face=3D"Calibri"> </font><br> <font face=3D"Calibri">The proposed change =
in Section 3.3.4 (Client Pseudonym) is to change the sentence:</font> =
<ul> <ul><font face=3D"Calibri">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.</font></ul> </ul> <font face=3D"Calibri">to:</font> =
<ul> <ul><font face=3D"Calibri">The IP/STS SHOULD combine this Client =
Pseudonym value with </font><font color=3D"#FF0000" =
face=3D"Calibri">user-specific information and </font><font =
face=3D"Calibri">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.</font></ul> </ul> <font face=3D"Calibri"> </font><br> <font =
face=3D"Calibri">Here=92s an explanation of why this change is a good =
idea=85</font><br> <font face=3D"Calibri"> </font> <ul><font =
size=3D"2">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."</font><br> <font =
size=3D"2"> </font><br> <font size=3D"2">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=92t verify that it issues consistent PPID =
values per user).</font><br> <font size=3D"2"> </font><br> <font =
size=3D"2">For these reasons, the text above should be modified as =
follows: </font><br> <font size=3D"2"> </font><br> <font size=3D"2"> =
"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."</font></ul> <font face=3D"Calibri"> </font><br> <font =
face=3D"Calibri">I=92ve 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.</font><br> <font =
face=3D"Calibri"> </font><br> <font face=3D"Calibri">Talk to all of you =
in the morning!</font><br> <font face=3D"Calibri"> </font><br> <font =
face=3D"Calibri"> =
-- Mike</font><br> <font face=3D"Calibri"> </font><br> =
</div></blockquote></div><br></div></body></html>=
--Apple-Mail-152--996969397--
--Apple-Mail-153--996969314
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGrzCCAz8w
ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0
ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx
KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA
dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB
MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d
yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/
p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow
OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js
MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw
DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI
Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggNoMIIC0aADAgECAhAd94+bIYviuSaQ
w/qU/yWPMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u
c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTAeFw0wODEyMTIwMTU0MzFaFw0wOTEyMTIwMTU0MzFaMIGfMR8wHQYDVQQDExZUaGF3
dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBqYnJhZGxleUBtYWMuY29tMR4wHAYJ
KoZIhvcNAQkBFg9qYnJhZGxleUBtZS5jb20xHTAbBgkqhkiG9w0BCQEWDnZlN2p0YkBtYWMuY29t
MRwwGgYJKoZIhvcNAQkBFg12ZTdqdGJAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxB2GGbZ5p8mVtg16CSDXeF8F3D+5sbs8L4b/YrHt/BvtQdE8GY202cUko/b/rXTUA0JC
XZRDrOiH7ZxcqI4alJNel9AcSLepcdHN4+t2zhvWilm+YF0/r6m/1PikkVT9TWic61IZMpNWIUkk
A+MWzEjChYPefdSMhxikhhMFZ0sv2qPE9pmdaPtD2uF4MwKnIzdZYo+X7rWoaXHIdsZwZDU3HdR5
rVuK5s9xvRED7TZgwE1/yHzHnTbedUWPdNNUlL24Jp3iiVzjZan8zOCn6x4b8O1QPN5b/FOZrerq
FDZ2zhIBsWEcKdIxqIqPdVkrYvEfGBLMe1QIORu0J56L/QIDAQABo10wWzBLBgNVHREERDBCgRBq
YnJhZGxleUBtYWMuY29tgQ9qYnJhZGxleUBtZS5jb22BDnZlN2p0YkBtYWMuY29tgQ12ZTdqdGJA
bWUuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEADhjvX5w/BXN7OL5y1ZfydfmJ
RKezNqugUDf8XbKmmMR/o+vjx395pBpO9QF8hQwtKNDuvoxLTNDMWdcCNbvaEpqREXc7liV9FfA5
ndAB1VgDqYDjY9M9LU54LH8uqEx7+pX6qa6KoR8eRHby9zi+iuSkJ4GLI59RBnVI54x4/acxggMQ
MIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5
KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQHfeP
myGL4rkmkMP6lP8ljzAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0wOTAyMTkwMTUxMDhaMCMGCSqGSIb3DQEJBDEWBBRjcVoRN4CeJv6uhZDi
umXcLSntZDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj
VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wDQYJ
KoZIhvcNAQEBBQAEggEAbWmJ5/kzVrcz36yItMRJmfldIs/Aa53YG8S6PP/GiCy6c3KDX49Pmy5B
6TR9fV+KKfsoSdYcMktHNi2RMlrP0hXqsrr0kz9jLmYP+PPDaRcYmmf6apHiiafdqkxv8mJZjL/n
hXsvk/tmMcOSZsX3pATChiIXqFzNl/A1M+07uWcnTab1mke9ArHH21Vx3taEF7oVdAOoDaFwCaNy
F3LMi8wCM0n45fWUZJCfj7mmdLqtwa9FZzkTUqeUuUYfVNrSlo07jlMOb+D47avU5T+lfuSr9lB+
t8hyYO6NVBzW0ZKP5gKkAluhmj7V7XJIpCKDmzK6N3BGiVFPNq/lgA9l4gAAAAAAAA==
--Apple-Mail-153--996969314--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]