RE: [security-services] SAML 2.0 Work items - Kerberos

["Hal Lockhart" <hlockhar@bea.com>]

I agree with Polar. It took a long time to get Kerberos right. The
properties of the protocol are quite subtle. Creating an XML version of
Kerberos is a highly risky and likely to be lengthy process with little
payback.

When we started SAML, we agreed (in the Charter) that we would not invent
any new Authentication protocols. I assert that an XML version of Kerberos
would be a new protocol.

I think it makes a lot of sense to use the SAML credentials format to
enhance the expressive power of Kerberos tickets for Authorization purposes.
If the three schemes mentioned by John Hughes, only DCE offers an extensible
attribute format. Plain Kerberos has only string names and MS-Kerberos has
only a fixed Group scheme.

I wrote a memo outlining the situation back in April 2002.

http://www.oasis-open.org/archives/security-services/200204/msg00041.html

The main issue I saw was that for certainly highly useful scenarios, a SAML
Attribute Authority would have to be closely coupled with a KDC.

Hal

> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Monday, August 04, 2003 6:01 PM
> To: 'Polar Humenn'
> Cc: security-services@lists.oasis-open.org
> Subject: RE: [security-services] SAML 2.0 Work items - Kerberos
>
>
> Polar,
>
> 	Good observations.
>
> 	The reason we are going to support Kerberos natively in SAML is to
> leverage Kerberos. In SAML 1.1, one needs to do Kerberos stuff out of band
> and then possibly issue an authorization assertion. May be even
> this is not
> possible. Anyway Kerberos cannot fully participate as, for example, an
> authorization authority in the SAML world.
>
> 	Supporting Kerneros natively also helps SAML enabled services to
> interact with Kerberos servers.
>
> 	I was exploring how far we should go in terms of Kerberos support.
> We are not out to XMLise all the ASN.1/DER protocols.
>
> 	Re. the MEP question, SAML authorities now support only the req-resp
> protocol. We would need more MEPs. Again remember, we are only
> capturing the
> mechanism and the elements required. We are *not* developing the
> mechanics -
> like replacing CORBA. The SAML MEP messages might very well be
> carried in a
> CORBA substrate or a SOAP/HTTP substrate or even a XML/carrier-pigeon :o).
> But once a SAML authority gets a package, it needs to understand the
> interaction context to act accordingly and we are defining the propagation
> of the interaction context in terms of SAML.
>
> -k.
>
> >
> > -----Original Message-----
> > From: Polar Humenn [mailto:polar@syr.edu]
> > Sent: Monday, August 04, 2003 2:33 PM
> > To: Krishna Sankar
> > Cc: security-services@lists.oasis-open.org
> >
> >
> > On Mon, 4 Aug 2003, Krishna Sankar wrote:
> >
> > > 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).
> >
> > Why do we want to XMLize every protocol in creation? What is
> > wrong with
> > the ASN.1 and DER encoding?
> >
> > > 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.
> >
> > Isn't the Microsoft implemenation just standard kerberos with some
> > authorization information that there wasn't a standard for anyway?
> >
> > I think you might be able to stick a SAML Authorization
> > assertion in that
> > area, wouldn't you?
> >
> > > 			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 ?
> >
> > What weaknesses does Kerberos have, other than notoriously
> > compact data
> > and quick authentication response times?
> >
> > Are you thinking of using the SAML Authentication Assertion?
> >
> > > 				ii)	Is there an industry demand for
> > > Kerberos support for SAML ?
> >
> > That indeed, definately needs to be explored.
> >
> > > 	c)	Should we add the Kerberos messages as SAML
> > extensions or as
> > > native SAML assertions ? I think native support is better.
> >
> > Again, why translate all that ASN.1 into XML?
> >
> > > 	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.
> >
> > Sorry to be scarcastic, doesn't this sound like reinventing CORBA just
> > using XML instead of GIOP?
> >
> > > 	Thoughts ?
> >
> > Just my 28,438.93 Turkish Liras
> >
> > Cheers,
> > -Polar
> >
> > > -k.
> > >
> > >
> > > You may leave a Technical Committee at any time by visiting
> > http://www.oasis-open.org/apps/org/workgroup/security-services
> > /members/leave_workgroup.php
> > >
> >
> >
> > You may leave a Technical Committee at any time by visiting
> > http://www.oasis-open.org/apps/org/workgroup/security-services
> > /members/leave_workgroup.php
> >
> >
>
>
> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave
_workgroup.php