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             |  
Interop Tech  Lead        |  +1 413-458-3743
Liberty Alliance          |  +1 413-627-1778 mobile