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: draft minute notes for Wednesday AM


Here are the notes I collected on this morning's session.  

--jl

Minutes for Wednesday morning session of SSTC meeting, collected by John
Linn

Rob Philpott called the session to order, and Prateek Mishra collected
attendance. 

Discussion of W-5b: SOAP Client Profile (Mike McIntosh):

The document covers 3 scenarios: 
		SOAP requestor of SAML assertion to be sent to service
provider; 
		proxy-based SOAP request for SAML assertion, where proxy
forwards assertion; 
		service requests SAML assertion for SOAP client
For each case, the WSS SAML token profile is used to protect the SAML
assertion.  The client authenticates to the service provider using some
mechanism other than SAML.  

Tony observed that this proposal represented one of many possible
integration approaches. Scott observed that the use of the SAML token
profile to protect the returned assertion appeared unusual. Irving Reid
observed that credentials in WSS messages seem to serve two distinct
purposes: message protection and/or proof of identity, and that this overlap
can be confusing. 

Towards the end of Sec. 3, Ron Monzillo observed that step 2 might represent
an appropriate use of the SAML Token profile, rather than step 5 as
described.  Per steps 4 and 5, Irving commented that it seemed strange to
use SOAP header elements; Tony Nadalin asserted that it appeared natural for
use within a WSS environment.   Generally, there was controversy about the
relative merits of applying SOAP header elements vs. layers enclosed within
SOAP messages.  

Irving presented a diagram for a candidate flow, in which a SOAP client
requests an operation from an SP, carrying an abstract ticket to
authenticate itself.  The SP, in turn, invokes an IDP to obtain an
assertion. Irving recommended that these elements be placed in the SOAP body
rather than the header.  Mike compared this to his proposal, where the
client authenticates using WSS.  Irving believed that, in certain deployment
models, WSS wrappers might be applied and removed at lower implementation
layers, making it difficult to also use the WSS layer to provide the
functions being considered.  Irving observed that Mike's model appears to be
oriented to a relatively low-function SP, performing only limited processing
and acting as a pass-through for unmodified data elements.  Tony sees some
similarity between aspects of Mike's proposal and Scott's proxy materials. 

Bob Morgan was unclear as to what models this proposal would enable which
are not already possible within SAML.  Rob noted that this adds
specification for the use of authentication based on WSS.  Scott was not
sure as to whether the SSTC should profile WSS usage.   Prateek asked about
next steps, based on these proposed use cases and solution elements.  Irving
believed that the translation of one WSS message to another is properly a
WSS profiling activity, rather than a SAML activity; Tony believed that
profiling WSS, carrying SAML assertions, was no less appropriate as a SAML
activity than profiling HTTP-based SSO protocols.  Eve asked, what would
this solution provide that composition of existing elements couldn't offer?
One possible value is that it provides a push model.  

Prateek asks whether the TC will accept the use case; Eve believes that the
TC does not yet fully understand the proposal and its benefits, and asks for
timely clarification.  Given the SAML 2.0 schedule, she further observes
that such work may need to be considered within a subsequent phase.  Scott
believes that existing elements (possibly with certain extensions, as to
request a token for another identity) can satisfy the first two proposed
functional scenarios, assuming that requests are made within the SAML
protocol.  Eve Maler suggests (and Prateek concurs) that the proposal's
proponents should provide additional use case motivation and clarification
for follow-up discussion (possibly tomorrow), in the context of SAML and the
WSS SAML token profile.  Scott and Irving also plan to contribute to this
analysis, considering both aspects of SAML 1.1 and of current SAML 2.0 work
in progress. 

Discussion of W-25: Kerberos Support (John Hughes, Tim Alsop):  

Two documents have been offered, per restructuring discussed on TC con call:

		Generalized AuthnRequest Protocols and 
		Kerberos SAML Profiles. 
The Kerberos-specific profile needs an updated solution proposal, which is
hopefully to be provided this week.  A user's workstation runs code causing
the described SAML service (which corresponds to the SAML authority as
described in other terminology) to return an AuthnResponse, using Kerberos
to protect the interaction with that service.  While Kerberos can be used
for a number of functions, the proposal emphasizes its use to securely pass
a user identity to the SAML responder via the SAML service. Among several
other uses, Kerberos can also be considered as an alternative to SSL to
provide a secure channel.  Noted: Kerberos TLS ciphersuite definition
exists, but has not been widely implemented.  John Linn asked whether it was
within SSTC scope to define approaches to provide secure channels, vs.
recommending that secure channels be provided at layers below SAML? 

The primary use case concerns use of a Kerberos ticket as input to obtain a
SAML assertion, reflecting the identity obtained from the ticket.  The
proposed approach establishes a GSS-API security context to the SAML
service, carrying GSS tokens within a variety of protocols; identified
customer requirements have not been SOAP-oriented. Jeff Hodges suggested
that this use case be treated generically, also accommodating other
mechanisms than Kerberos. 

Schema elements were proposed to represent DCE/Microsoft privilege attribute
certificate (PAC) contents within attribute statements.  Name identifier
forms were also proposed to represent Kerberos principal names; following
recent reconsideration, proponents now suggest that the Kerberos realm be
included as a qualifier to the individual principal name.  Hal Lockhart
asked whether UUIDs should be represented. 

Identified outstanding issues include mapping to Microsoft PAC data, how and
why to bind Kerberos credentials to SAML assertions (e.g., including
Kerberos keys as confirmation methods), additional detail on
Kerberos/GSS-API bindings, and appropriate use of existing Liberty, WSS, and
Microsoft Passport Kerberos-related standards and drafts.  In future, also,
SAML and Kerberos might be combined as a means to establish cross-realm
trust. Scott raises the use case of incorporating forwardable Kerberos
tickets within attributes.  Jeff Hodges clarifies that Liberty is not doing
work specific to Kerberos, but that its ongoing SASL work can accommodate
Kerberos along with other mechanisms. 

Suggested next step: elaborated proposal could be discussed at upcoming
focus call.  Rob questions whether this will fit into the SAML 2.0 schedule.
Mike Beach suggested that it could be useful for the SSTC to define mappings
between Kerberos and SAML data elements. 

Prateek introduced discussion of a pending LECP motion, containing the
following elements:
		Adopt LECP solution proposal, Draft 5, 2 Jan 04
		Adopt PAOS+LECP solution proposal, Draft 1, 8 Jan 04
		Integrate into SAML 2.0 Bindings and Profiles specification

Ron questioned whether these elements were necessarily within SSTC scope;
Scott believes that they are appropriate profiles to consider for SSTC
purposes.  To this point, SAML has not specified that particular profiles
must be implemented for conformance purposes.  Prateek observed that
conformance criteria are likely to become more complex for SAML 2.0.  

Tony indicated that he found the supporting use case for PAOS to be unclear.
Frederick Hirsch suggested that it allowed use with non-SOAP service
providers, and that it was compatible with operational models common in
mobile environments.  Greg Whitehead commented that LECP offers particular
value in multi-IDP scenarios, taking advantage of information resident on
mobile terminals.  Attendees indicated that they perceive existing and
emerging interest in SOAP-capable mobile terminals, and it was suggested
that definition of a standard approach for their support would be useful.  

Mike McIntosh and Tony Nadalin object to the motion, particularly
questioning its inclusion of PAOS.  Prateek takes a vote of attendees.  11
yes, 7 abstain, 4 no; vote passes on simple majority. 

The morning session was adjourned at 12:16 PM. 




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