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