SAML 2.0 Work items - Kerberos

["Krishna Sankar" <ksankar@cisco.com>]

Hi,

	Have been thinking about this topic on my way to UK last night.
Would like to bounce off some of the very initial questions I had.

	a)	What : 

			We want to support Kerberos as an authentication
mechanism. Which means we need SAML equivalents for the various protocols
and message formats for all interactions between Kerberos entities
(AS/TGS/RTS/..) (RFC1510, Kerberos now uses ASN.1 and DER encoding). 

			I assume we will support Kerberos 5.0 and above. We
will support cross-realm & transitive cross-realm authC and user-to-user
authC. We will also support different tickets like forwardable, renewable
and postdatable. We should be able to leverage existing SAML elements.
Haven't thought thru yet.

			What about popular derivatives of Kerberos like the
Microsoft implementation ? I think we should make every attempt to seek out
information and see if we can incorporate it in SAML Kerberos support.

			Should we mandate any security context like secure
channels for cross-realm communication, clock synchronization, 

	b)	Why :

			Leverage synergies between Kerberos and SAML.
Support Kerberos natively thus enabling Kerberos artifacts to be used with
SAML assertions. Kerberos authorities can now use a web service
infrastructure. Applications that support SAML can now "speak" Kerberos.

			To explore :
				 i)	Can SAML strengthen any of the
weaknesses Kerberos has ? 
				ii)	Is there an industry demand for
Kerberos support for SAML ? 

	c)	Should we add the Kerberos messages as SAML extensions or as
native SAML assertions ? I think native support is better.

	d)	For Kerberos support, we need the concept of a SAML
Listener, associated message container and a listener protocol. I think it
would be a good idea to have a generic SAML listener protocol. Extending
further may be it is a good idea to have SAML containers and protocols for
the basic 4 or 5 MEPs. We already have the req-resp MEP.

	Thoughts ?

-k.