Some initial security consideration thoughts

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

Title: Some initial security consideration thoughts

The security in SAML should, if and where possible, use time tested security protocols.  There are numerous protocols in the literature that cover the space that SAML is in the process of defining.  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.  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.) 

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.

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

In order to protect against a replay attack, Kerberos use a timestamp and a lifetime.  Highly skewed times on the machines involved in the message exchanges can cause the protocol to be susceptible to a replay attack.  DCE in its use of Kerberos goes to some length to set up a secure time service and assure that the time on the various machines are within a given delta time.  There is no such mechanism in place in the Internet space.  Further, some of the machines, e.g. client machines run by non-technical users, especially NT machines, will almost be guaranteed to have widely spaced time differentials.

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.

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.

Secret Key Requirement

The use of secret keys by Kerberos results in scaling problems in large systems since the KDC needs a key for each client and server that it supports.  There is also the problem of key management with respect to these keys.

There is work in process for using public key in the initial authentication in the Kerberos protocol, e.g the IETF draft, draft-ietf-cat-kerberos-pk-init-10.txt.   Public key technology is not a cure-all for key management.  While it simplifies the key management problem, it does require an infrastructure of its own, e.g. certificate authorities and/or some way to assure the availability of certificates and a way to protect the private key of the public/private key pair at the client machine.

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. 

One other matter, Kerberos defines an "Authenticator".  I don't know if this was the origination of the Authenticator used in SAML.  An Authenticator in Kerberos is defined as - the client's identity, a timestamp and an optional session key, all encrypted by the secret key used between the client and the target.  This is sent along with the ticket when the client wishes to use the server's services.

Don