OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Draft note Comment to NIST regarding 800-63-1 prohibition ofassertions at LOA 4

Here is a first attempt at some language that the SSTC could provide to NIST
as a Comment/Advice on the Draft 800-63-1 (Feb 2008) document[1].  The main
goal is to suggest that the prohibition on assertions at LOA 4 is too
strong, and that assertions could be allowed at LOA 4 with suitable
restrictions.  Most of this is based on my earlier review of the NIST
document in the SSTC list [2].

I'm not sure of the exact form this submission should take, or what OASIS
hoops need jumping through.  My thought is that this should be discussed in
the SSTC, edited, and voted out, and then submitted to the appropriate
person(s) at NIST as a letter from the SSTC chairs including (or attached
to) the following text:

(I won't be able to respond to comments on this text until shortly before
the next call on 10/21 as I will be off the grid in the Andes)

It has recently come to our attention that the February 2008 draft revision
of NIST Special Publication 800-63-1 "Electronic Authentication Guidline"
explicitly prohibits the use of "assertions" at level-of-assurance 4

We agree that existing published specifications (including SAML 2.0 and
subsequent profiles) do not meet the strict requirements defined for LOA-4,
we also feel that mechanisms exist that can be employed to provide adequate
protection for assertions that will satisfy LOA-4 needs.  In the particular
case of SAML assertions, a draft "Holder-of-Key Web Browser SSO Profile" now
being discussed in the SSTC defines a method for achieving the required
protections for using SAML Single-Sign-On (SSO) at LOA-4.

v=security >

As a consequence, we are suggesting some changes to the language in the
800-63-1 draft to stipulate the conditions necessary for assertions to be
used at LOA-4.

We feel that this is an important modification for several reasons:

  o It enhances security and economy if the same protocol suite can be
deployed for use at all LOAs.  Problems with configuration, maintenance, and
procurement can arise when there is one set of protocols, implementations,
and vendors at LOA 1-3 and a separate set of protocols, implementations, and
vendors for LOA 4. 

  o Many organizations around the world use the NIST 800-63 as a model for
their own authentication schemes.  NIST should propose the best and most
precise set of requirements while allowing for evolution in the protocols.

The following are some specific changes we would suggest:

The justification for prohibiting assertions is found on 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.

We would suggest the following alternative:

    Assertions are only allowed at Level 4 if conveyed via protocol
    mechanisms that allow a strong binding between the authentication
    activity established between the Claimant and the Verifier,
    the secure session established between the Subscriber and the
    Relying Party, and the assertion itself.

Section 10.3 specifies the Assertion protections at each LOA.  Currently,
sectionn (p. 85) simply says " At Level 4, assertions shall not be
used. ".  We would suggest that this be modified to the following:

    Assertions are allowed at Level 4 if carried via protocol
    mechanisms that allow a strong cryptgraphic binding between
    assertion and the transport mechanism used to convey the assertion
    between the claimant, the verifier, and the relying party.

We also suggest 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, to have YES in
every cell.  We also suggest the addition of a row to that table for (e.g.)
"Cryptographic binding of assertion to channel" that is Yes for the Level 4

Ultimately, we believe that the SAML HoK SSO profile will satisfy these
requirements; updates to other protocols may also make it possible to use
their versions of  assertions at LOA-4 as well.  Future versions of the NIST
800-63 document may make specific reference to these updated protocol
profiles as they are approved in the relevant standards bodies.


[1] http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-63--1


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]