[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NIST 800-63 draft doc refs related to assertions and Level 4
Here are the places in [1] that I found relating to the prohibition of "assertions" at level 4. My earlier note with some of these same references is at [2]. I think these first two items are the key pieces. Section 10.3 specifies the Assertion protections at each LOA, and I think we should provide language to modify section 10.3.2.4 (p. 85) which simply says " At Level 4, assertions shall not be used. ". We should probably also provide a replacement for the last column of table 14 (p.84) which describes "threat resisistanc per assurance level" for assertions. We should be able, based on the text we provide for 10.3.2.4, to have YES in every cell. We may also want to add a row to that table for (e.g.) "Cryptographic binding of assertion to channel" that is Yes for the Level 4 column (and maybe a footnote indicating only SAML HoK binding would satisfy). Here are some other locations worthy of attention: Justification for prohibiting p. 84: Assertions are not allowed at Level 4 since it is not possible to establish a strong enough binding between the authentication activity established between the Claimant and the Verifier, and the secure session established between the Subscriber and the Relying Party. In addition, on p. viii, Level 4 is intended to provide the highest practical remote network authentication assurance... And pp. viii-ix: Protocols shall also be strongly resistant to man-in-the-middle attacks. Long-term shared authentication secrets, if used, are never revealed to any party...Strong Approved cryptographic techniques are used for all operations. All sensitive data transfers are cryptographically authenticated using keys bound to the authentication process. (which would not necessarily prohibit assertions given suitable protections). Definition of Assertion in table on p. 17 (which seems OK, as far as it goes): A statement from a Verifier to a Relying Party that contains identity information about a Subscriber. Assertions may also contain verified attributes. The figure on p. 25 shows a transmission of an Authn Assertion directly from the "verifier" to the RP. This is not actually what happens in the eAuthn environment, given that they use the POST/Redirect binding where the assertions loop through the client. The text may clarify this, but I didn't find it. The diagrams in Section 10 on p. 77 are much better. This is also where they implicitly define an assertion as a "secondary authenticator", and then use this term libertally and interchangeably with "assertion". Section 5.6 on p. 28 gives a more comprehensive definition of "assertion". Note that their definition of "assertion" explicitly encompasses both Cookies and SAML assertions. I would note that on p. 29 the first bullet describes SAML assertions, noting: SAML assertions may optionally be digitally signed. Indeed, they may also be encrypted by the CSP for use at the RP. This is noted later in Section 10 at the bottom of p. 80. Section 10.3 specifies the Assertion protections at each LOA, and I think we should provide language to modify section 10.3.2.4 (p. 85) which simply says " At Level 4, assertions shall not be used. ". We should probably also provide a replacement for the last column of table 14 (p.84) which describes "threat resisistanc per assurance level" for assertions. We should be able, based on the text we provide for 10.3.2.4, to have YES in every cell. We may also want to add a row to that table for (e.g.) "Cryptographic binding of assertion to channel" that is Yes for the Level 4 column. And they have added some odd notions about different lifetimes for assertions based on whether they originate from the same internet domain (p. 85): Also, at Level 3, assertions shall expire within 30 minutes when used within a single domain (e.g. Internet cookies). Cross-domain assertions shall expire within 5 minutes. I'm not sure whether this is meaningful for SAML assertions, or maybe only cookies. ET [1] http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-63--1 [2] http://lists.oasis-open.org/archives/security-services/200806/msg00027.html -- ____________________________________________________ Eric Tiffany | eric@projectliberty.org Interop Tech Lead | +1 413-458-3743 Liberty Alliance | +1 413-627-1778 mobile
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]