Re: Some initial security consideration thoughts

[George Robert Blakley III <blakley@us.tivoli.com>]

Don,

>The security in SAML should, if and where possible, use time tested
security protocols.

Just to be clear, SAML doesn't "use" protocols.

SAML:

(1) Defines a format for assertions by authorities
(2) Defines an ABSTRACT protocol for requests and responses to allow
requestors to get assertions from authorities
(3) Defines a set of BINDINGS of these protocols to concrete protocols

     In this context SAML bindings should (and, we all expect, will) use
the security "native" to these protocols
     to protect its request/response exchanges

(4) Defines a set of PROFILES for passing SAML assertion tokens within
existing protocols like SOAP

     In this context SAML profiles should (and, we all expect, will) use
the security "native" to these protocols
     to protect its assertion tokens -- THOUGH THIS MAY REQUIRE CHANGES OR
ADDITIONS TO THE
     NATIVE PROTOCOLS IF SAML IS TO BE USED TO ESTABLISH SESSION SECURITY
CONTEXTS.

>There are numerous protocols in the literature that cover the space that
SAML is in the process of defining.

Essentially every protocol environment in existence is a candidate for a
SAML binding, and many are also
candidates for SAML profiles.

>The authentication/key management protocols are of special interest to
SAML.
>
>Authentication/Key Management Protocols
>
>A number of the protocols that I have seen suggested in the SAML mailing
list seem to be variations of the Kerberos protocol
>in which some portion or other of the Kerberos protocol was left out.

SAML itself will define some mechanisms for establishing whether a relying
party should trust the assertion of an issuer.
This is NOT the job of an underlying protocol, but is the job of the SAML
layer and should be independent of the underlying
protocol, particularly in environments where we want end-to-end security
over a heterogeneous multi-hop protocol topology.

>As a general principal one should be very careful when one drops or
changes a portion of a security protocol
>as this can easily lead to making that protocol insecure.  (Kerberos
itself is a variant of the Needham-Shroeder protocol.)

Yep.  However it's also the case that a security protocol needs to be
designed to accomplish a specific purpose, and
not every environment has the same security goals as Kerberos.
Nevertheless, caution is warranted as you point out.

>The Kerberos protocol has some advantages and some disadvantages when it
comes to solving the distributed network
>authentication problem that is a goal of SAML.
>
>Disadvantages:
>        *       Requires coordinated time between entities
>        *       Requires KDC to have secret (symmetric) keys for each
client/server it supports.

My strong preference is not to build ANY reliance on synchronized time into
any aspect of SAML, given that a primary
goal is interoperability between security domains which are heterogeneous
from an organizational, policy, and
technology point of view.

>Advantages:
>        *       The ticket granting ticket and the specific server ticket
can be used over a number of sessions without
>                reauthenticating.
>        *       It roughly matches the distributed use cases where
the Kerberos KDC is equivalent to the Source Site.
>
>Coordinated Time
>
>... snip
>
>The Neuman-Stubblebine Protocol (corrected) overcomes the problem of
non-synchronized clocks
>by using the time relative to the server's clock on all the machines.  One
constraint is that
>this protocol requires that the client contact target before the source
server.

Neither this protocol nor Kerberos is appropriate IN GENERAL in a SAML
context, as we need to
support connectionless store-and-forward environments as well as
session-oriented environments.

>It should be noted that some of the protocols proposed on the SAML mailing
list use time stamps
>without addressing the time variance problem on the different machines in
the system.

The documentation doesn't explicitly address the time variance problem but
I think I summarize the intent
of the group correctly when I say that our intention is NOT to rely upon
time synchronization.

>Secret Key Requirement
>
>...snip
>There is work in process for using public key in the initial
authentication in the Kerberos protocol,

Again I guess I'll say that SAML will not require any particular
authentication protocol (initial authentication of
users is out of scope, and authentication of partners is a binding issue
and will differ from binding to binding
and profile to profile), and that in any event ANY flavor of Kerberos
cannot be the sole solution since we need
to support connectionless store-and-forward cases.

>In the overall picture, one of the things said in the "Risks of Passport
Single Signon Protol" paper that Hal
>sent the reference to was that - "Passport's attempt to retrofit the
complex process of single sign-on to fit
>the limitations of existing browser technology leads to compromises that
create real risks".
>I don't know if we can construct a secure protocol without requiring
additional work at the client.

I do!  We can't.  There are man-in-the middle attacks that can't be
defeated if you have the combination
of oblivious clients and either descriptive or indexical reference by
servers to the holders of assertions.

>One other matter, Kerberos defines an "Authenticator".  I don't know if
this was the origination of the
>Authenticator used in SAML.

In a generic way it's an ancestor of the SAML notion.  An authenticator is
simply a token used to prove that
the sender of a token is also the subject to whom the token refers.  In
this sense the SAML authenticator and
the Kerberos authenticator are functionally identical.

--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.