[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Comments on draft-sstc-solution-profile-kerberos-01.pdf
Jeff, many thanks for the comments. Tim A. and I were discussing this yesterday - and our opinion is that the KRB/SAML profile will probably turn out to be more like a "recipe" rather that defining specific protocols. Perhaps at the telecon later today we can spend 10mins or so on what direction we want to go down as far as documentation structure is concerned. John > -----Original Message----- > From: Jeff Hodges [mailto:Jeff.Hodges@Sun.COM] > Sent: 20 January 2004 01:58 > To: 'SAML' > Subject: Re: [security-services] Comments on > draft-sstc-solution-profile-kerberos-01.pdf > > > My thoughts/comments on draft-sstc-solution-profile-kerberos-01 > parallel those > of ScottC's, so I'll just mention the aspects that are a little different > and/or more detailed. > > My impression of these sections.. > > 3.3 Non-Browser client – Client requesting SAML assertion > 3.4 Non-Browser client – Application requesting SAML assertion > > ..is that they are pretty close to comprising a solution proposal > for work item > "5b SOAP Client Profile". > > Tho there are a couple of key things that are different than what > I imagine wrt > the way to do it. Obviously, in those two sections ("[3.3,3.4]"), > you folks > didn't spec the transfer/transport protocol in use. Settling on > one will cast > these as specific profiles wrt the selected protocol, which is > fine, we can > have multiple such profiles spplying to multiple > transfer/transport protocols > if there is need (such need is usally concretely expressed by > someone rolling > up their sleeves and wading in and actively working on such > profiles ;-) So > for sake of this argument, let's say the transfer/transport > protocol is SOAP, > and then indeed we're talking about W-5b. > > Another item is the manner in which this protocol is wedded (welded?) to > Kerberos. Krb is fine stuff, lotsa folks use it, but there are other > peer-entity, proof-of-secret-possession authentication protocols > out there. > Nominally, one can take [3.3], say, and extract the Krb specifics > out of it, > build on some of the stuff ScottC's saying, and say something > along the lines > of (this is admittedly rough).. > > 1. client sends AuthnReq msg over SOAP to the Local Site SAML > Service. If > client isn't yet authenticated, SAML Service responds with a message that > initiates a SASL-over-SOAP authentication interaction (potentially > muli-round-trip, depends on SASL mechanism employed). > > 2. Upon successful completion of SASL interaction, client is > authenticated > and the last thing the SAML Service sends the client is an AuthnResponse > message containing SAML Authn Assertion. This could sport either > holder-of-key > and/or bearer confirmation method(s). Or mebbe also, there's an > option for the > SAML Service to supply an artifact in some fashion. > > 3. Client incorporates SAML Authn Assertion (eg via WSS SAML > Token Profile) > in downstream interactions with parties. > > > Why SASL (http://www.ietf.org/rfc/rfc2222.txt) ? Because it > abstracts the > actual authentication protocol out from our protocol here at > design time and > allows for a "late binding" at implementation and/or deployment > times. It is > used by several protocols, notably LDAP (http://www.ietf.org/rfc/rfc2251.txt, section 4.2) and IMAP. There is a Kerberos SASL mechanism :) (albeit it is Krbv4, but it's just SMOD [1] to get a Krbv5 one conz'd up (and mebbe that's afoot)). Additionally, SASL already has IANA support for registration of, and dissimenation of information about, SASL mechanisms [2]. Since SASL itself is freely available and unencumbered, as are in-practice examples of it's use (eg in LDAP (http://www.ietf.org/rfc/rfc2251.txt, section 4.2)), perhaps we (SSTC) should just take that prior IETF work and apply it to the case of a SOAP-speaking entity who engages in a SASL-based authentication operation with another SOAP-speaking entity, using SOAP, and just design it ourselves. Liberty, as I've mentioned, is working in this direction too, and there are spec drafts publicly available. But perhaps we (SSTC) shouldn't actually look at it (it's just an early mock-up work-in-progress in any case) -- rather, we can just invent it ourselves since SASL and how to apply it to protocol designs and specifications are already publicly known. But if you really want to take a look...[3]. thanks, JeffH ----- [1] Small Matter of Design. 8^) [2] "Simple Authentication and Security Layer (SASL) Mechanisms," Internet Assigned Numbers Authority (IANA) http://www.iana.org/assignments/sasl-mechanisms [3] draft-lib-arch-soap-authn-v1.0-03.pdf http://www.projectliberty.org/specs/draft-lib-arch-soap-authn-v1.0-03.pdf draft-id-wsf-client-profiles-v1.0-01.pdf http://www.projectliberty.org/specs/draft-id-wsf-client-profiles-v1.0-01.pdf --- end To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to 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]