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] | [Elist Home]


Subject: RE: [security-services] SAML & kerberos


Title: RE: [security-services] SAML & kerberos

Krishna,

It would be helpful to have a usecase or two, since both Kerberos and SAML provide quite general capabilities.

A few obsrvations.

A. It is necessary to be specific about what you mean by Kerberos. This is driven by the use cases, but will have a substantial inpact on the design. Even if we ignore Kerberos 4, there are at least three distinct things called "Kerberos".

1. RFC1510 specifies a specific set of messages, which are typically carried directly over TCP/IP. DES is the only cryptosystem allowed. Users are identified by a name and realm, there is no provision for expressing user attributes.

2. The GSSAPI/Kerberos binding (RFC 1964) has the same characteristics, but it makes it possible to use any transport mechanism in place of TCP/IP. This includes imbedding the Kerberos tokens in some application context. The availability of an API provides flexibility beyond a client that simply knows how to authenticate.

3. Microsoft has extended Kerberos by making it possible to use cryptosystems with longer keys and by defining a format for including the specific user attributes utilized by the Windows authorization service (ACLs). [DCE did something similiar, but more extensible.] In the Microsoft scheme, messages are carried over the RPC protocol. I am not sure what APIs are provided, however it is safe to assume that the vast majority of systems will be client systems with largely fixed behavior. This may constrain the design in various ways. Microsoft has expressed an intention to use Kerberos in .net, but as far as I am aware has not published anything other than the WS-Security and WS-License specifications.

In spite of industry criticisms of Microsoft's use of Kerberos, I think they are on the right track. Nobody wants to go through the pain of converting their infrastructure to a system using 56 bit keys. Unfortunately, nobody is using AES, which is the correct long term solution. Further, identifying users only by their name is hopeless in a large scale environment. Unfortunately, a small, fixed number of attributes is probably not sufficient either. This is a need SAML can fill.

B. It seems reasonable to assume that when Kerberos is used for authentication, Kerberos will also be used as the subject confirmation method. However, I have been analyzing this and I believe there are some difficulties involved. They revolve around the fact that Kerberos tickets, unlike X.509 certificates for example, are not generic, but are addressed to a specific server that knows the key to decrypt it. The ticket is also specific to the principal and session, as it contains a unique session key which has been shared with the principal.

Suppose a user wants to present an Attribute Assertion to some server. The subject confirmation method should contain a ticket addresed to that server. The Attribute Assertion is created and signed by an Attribute Authority, but how is the Attribute Authority to get the ticket? It cannot get it directly, as the Kerberos KDC will not issue a ticket to a different principal.

One possibility is that the user can provide it. This could work, but there is currently no defined way to put it in the SAML request message. This approach assumes some kind of Kerberos API which allows the principal to ask for a ticket addressed to the server and send it to the Attribute Authority. Unfortunately, this limits the application to a very specific data flow.

Another approach that could work is if the Attribute Authority is closely integrated with the Kerberos KDC. Then it could issue the necessary ticket. However, there is still the problem of getting the session key to the principal. Plus this kind of integration would probably not be feasible in most cases for a variety of reasons. So this approach seems impractical.

Of course, if the initial request from the principal goes first to the server, the server can forward the ticket to the Authentication Authority. However, since the AA will not be able to decrypt it, that doesn't really help it determine that both it and the server are talking about the same principal. And if it blindly sticks the ticket in the assertion and retuns it to the server that provided it, I don't see that we have accomplished anything.

A final approach would be to have the Kerberos server act as an AA and insert a secure reference to an Attribute Assertion in the ticket. This essentially what Windows and DCE do, but SAML has a more general attibute syntax. I think this would require a specific Profile if it were to be used widely.

C. As has been pointed out by people from Sun, if Kerberos is used to authenticate, an Authentication Assertion doesn't make much sense. There is not a lot of additional data, and each RP can confirm the ticket for itself. As discussed previously on a SAML concall, this might make sense for an Authentication Authority that supported multiple authentication methods and always issued an Authentication Assertion.

D. I think the use of Attribute Assertions, as discussed above is a real opportunity for SAML to add value to Kerberos, assuming it can be agreed how to do it.

E. In principal I don't see why Authorization Decision wouldn't also be useful in conjunction with Kerberos. Many people have made the observation "Kerberos doesn't include authorization." However the usecase here is not as clear to me.

F. The discussion above has deliberately omitted lots of important details. For example, Kerberos suppports a lot of different front end authentication protocols: password, preauthentication, PKI, user-to-user, etc. Some people might want to distinguish between them for policy decisions. Also, I have just been saying "ticket" but really what you need is a ticket and a fresh authenticator. This also implies you can't cache the assertions. There are also issues of ticket lifetimes and delegation policy.

My conclusion is that integrating SAML with Kerberos involves a lot of careful design and a clear understanding of the problem your are trying to solve. It is not enough to point with your finger and say "insert ticket here."

Hal

> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Saturday, March 23, 2002 10:36 PM
> To: security-services@lists.oasis-open.org
> Subject: [security-services] SAML & kerberos
>
>
> Hi all,
>
>       Am trying to write a briefing on SAML and Kerberos. Would
> appreciate any thoughts and pointers. Hopefully we will start
> discussing
> this soon after V1.0 is out the door.
>
> cheers
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



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


Powered by eList eXpress LLC