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