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


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




> -----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.

But creating a new protocol does not "leverage Kerberos". Instead it
represents a large commitment to design and debug a new Authentication
protocol and then wait for years for the industry to deploy it.

>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.

This is absolutely untrue. A SAML Authentication authority can report
Kerberos authentication just like any other form of Authentication.

The restrictions lie in the area of supporting both cryptographic and
non-cryptographic protocols via a Credentials Collector. In other works, a
SAML AuthN Authority can support Kerberos just as well as it can support TLS
with user certs. The restriction has nothing to do with Kerberos in
particular.
>
> 	Supporting Kerneros natively also helps SAML enabled services to
> interact with Kerberos servers.

But in environments where this is desired, they are already running one of
the standard Kerberos's.
>
> 	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.

I really don't follow the use case motivating this discussion. But it
doesn't seem to have much to do with Kerberos which is strictly a req/resp
protocol.

Hal

>
> -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




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