RE: Some initial security consideration thoughts

["Flinn, Don" <DFlinn@hitachisoftware.com>]

Title: RE: Some initial security consideration thoughts

Hi Bob

Thanks for your clear and illuminating comments.  Your four points are very helpful.

The reason that I picked on Kerberos or some Kerberos protocol is that we are attempting to define a three body problem, i.e. the client, the authentication service and the target and this maps directly to the Kerberos paradigm. (If I remember my physics, moving from a two to a three body problem results in a huge jump in complexity :-)   Another approach is to use a series of point-to-point solutions to the two body problem and solve the store and forward problem that you mentioned below. (I'm not sure whether you meant store and forward in the context that I am using it or whether you meant it as in the messaging paradigm, or both.)

This mail is an attempt to define the problem in general terms.  At this level of discussion I am using the term document to mean either an artifact as defined in previous mails or a SAML assertion document.

I'll use the traditional Alice, Bob, Carol, Trent and Mallory in my discussions.  Alice wants to talk securely with Bob and Carol. Trent is the authentication service and Mallory is the bad guy.

- Conditions to be satisfied by the protocol

(single signon) Alice will proactively authenticate once, i.e. Alice the person will be physically involve once by supplying some authentication evidence.

Assume that Mallory can get the document.

- Steps in the protocol

* Alice authenticates to Trent. (Outside SAML spec., The one and only proactive authentication, it is Mutual Authn.)
* Alice requests and receives a document from Trent.
*Alice uses this document to authenticate to Bob at a number of later times.
* Alice wants to use the same document to authenticate to Carol. (This might not be possible.)

- Questions that the protocol has to answer.

* What needs to be in the document to assure Bob that it comes from Alice?
        Some secret that only Alice knows or has and which only she can prove possession.

* How can the document be used to talk to Bob multiple times?

* Can the same document be used to talk to both Bob and Carol?

* What needs to be in the document to assure Carol that it comes from Alice?
        Some secret that only Alice knows or has and which only she can prove possession.

* How to prevent Mallory from using the document to impersonate Alice? 
        Mallory can't prove he has Alice's secret.

* How do we prevent replay?
        We can prevent replay if we have a nounce that can't be changed in the artifact.

* What is Alice's secret?
        The $64 question -:)

        Unique value from Trent, encrypted in Alice's public key.
        Alice modifies Unique value in some deterministic way & creates
                symmetric key.
        Re-encrypts with Bob's Public key and sends to Bob.
        Bob decrypts and sends to Trent encrypted in his public key.
        Trent verifies the Unique Value.
        Bob and Alice use symm key.

 Trent steels artifact.
        Can't get Symm Key so can't decrypt messages.

Authentication is implicit in the use of the symm key.
Doesn't work if want to just authenticate.  In that case need another pair of messages between bob and Alice where Bob sends a unique value that Alice modifies in a

-----Original Message-----
From: George Robert Blakley III [mailto:blakley@us.tivoli.com]
Sent: Monday, August 20, 2001 5:23 PM
To: Flinn, Don
Cc: 'security-consider@lists.oasis-open.org'
Subject: Re: Some initial security consideration thoughts

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.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>