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


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



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