Re: [security-services] Comments ondraft-sstc-solution-profile-kerberos-01.pdf

[Jeff Hodges <Jeff.Hodges@Sun.COM>]

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