[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: UPDATED Consolidated f2f5 minutes
UPDATED: Consolidated minutes for SSTC SAML V2.0 F2F #5,
Tues-Thurs 15-17 June 2004 (Updated with Thursday morning minutes) ====================================================================== Summary ====================================================================== Votes: ·
None - quorum not achieved New Action Items (Note that this list simply consolidates
the items in the raw minutes that were highlighted as AI’s. There are
additional items that folks said they would do that are described in the
minutes. Everyone should review the raw notes for any items they agreed to
take on): 1. Editors to
resolve submission process for additional Authn Context classes / Bindings /
Profiles 2. JohnK and
Scott to move Authn Context Declarations to XML Schema centric approach 3. Scott to
ping Peter for additional text, subsequent to that there will need to be a
review to ensure that the appropriate SHOULDs etc are there. 4. Scott to
reorganize section 4 (Metadata) to clarify 5. Scott to clean
up the text around the different types of profiles in Section 1.1 6. investigate
profile designator for statement and query - potentially allowing for endpoint
metadata 7. Scott to
talk to RL Bob (re: BER & DER issues in LDAP/X.500 profile?) 8. Prateek to
ping John H for clarification (re: UUID’s being used with attribute
values) 9. Scott to
incorporate into document. include reeference to Appendix A. (re: XACML
profile) 10. Need
clarification as to what is the target namespace for the DataType element? (re:
XACML profile) 11. Paul Madsen
to take the exec overview document 12. Scott will
investigate use of wiki on Oasis site 13. chairs to
put item regarding errata process on the concall agenda 14. (Jeffh)
Resolve status of RFC (re: syntax of UUID as URI) 15. (Scott) to
document the well-known values for the DCE attribute name 16. (Scott) Will
fix spec. to be more precise about use of encryption with name identifiers (per
discussion on PKI-based attr profile) 17. Rick R. (and
customer) should read and accept the OASIS IPR policy for document submission 18. (chairs)
discuss + resolve general approach to new profiles 19. Jeff to add
security context to Glossary 20. Jeff to help
with sequence diagrams for profiles 21. Rob to
enumerate the implementation declarations/claims of interest. Prateek and Scott
will contribute. 22. Hal will
look at OneTimeUse text again and attempt to clarify 23. John K. to
clarity text on 909-911 on SessionIndex 24. John K. to
look up why SessionIndex is required 25. Scott to o
propose alternate text for section
3.2.3.1 o
strike 3.2.3.2-3.2.3.4. o
rewrite 3.2.2.3-3.2.2.5 26. Hal to get
expert advice on how to prevent caching by proxies and user agents 27. JohnL and
Prateek to draft up a document commenting on, acknowledging, and clarifying
certain points in the IBM Research Report RZ 3501 (# 99427) 06/30/03 New Issues:
Existing Issues:
====================================================================== Raw Notes ====================================================================== [Steve Anderson begins as minute-taker]
·
Conor P. Cahill AOL, Inc. ·
Hal Lockhart BEA ·
Rick Randall Booz Allen Hamilton ·
John Hughes Entegrity Solutions
(dial-in) ·
Paul Madsen Entrust ·
Dana Kaufman Forum Systems ·
Irving Reid Hewlett-Packard Company ·
Michael McIntosh IBM ·
Scott Cantor Individual ·
Prateek Mishra Netegrity ·
Frederick Hirsch Nokia ·
John Kemp Nokia ·
Charles Knouse Oblix ·
Steve Anderson OpenNetwork ·
Darren Platt Ping Identity (dial-in) ·
John Linn RSA Security ·
Rob Philpott RSA Security ·
Jahan Moreh Sigaba (dial-in) ·
Jeff Hodges Sun Microsystems
·
Gavenraj Sodhi Computer Associates -
Lost voting status after 6/15/2004 F2F ·
Emily Xu Sun - returned from LOA
6/14
·
Quorum not achieved
- John Kemp walking thru Authn Context doc (draft 5, PDF) - discussion of need for process for registering new
context classes - Hal: process should just verify
that doc is in right form, rather than verifying technical
merits - JohnK: line 4849, copied from
other SAML docs - Conor: do we need sanity check for
new classes? - Paul: thinks so - Conor: in - Scott: sees difference in
accepting for web site, and accepting into core doc set - Jeff: let's not rathole on this
now, just leave this section (5.5) TBD - JohnL: don't want to appear to
make commitment to post any submission on website - JohnK: proposed text? - Scott: if we change this, we need
to change other docs - Conor: OK for anyone to submit
anything, as long as we categorize sanctioned vs. not sanctioned - Hal: IPR issues with submissions
... but not going to rathole on that now - Prateek: thinks the stated
guidelines are helpful - [ACTION] Editors to resolve
submission process for additional Authn Context classes / Bindings /
Profiles - Conor: care should be taken to try
to define new submissions as member of existing class, rather
than entirely new class - JohnK: implemented Eve's suggestion: Authn
Context Statement -> Authn Context Declaration - need to clean up capitalization - JohnK: implemented former Authn Method as
Authn Context Class - Paul: noticed reference to Authn Method
that needs to be updated (line 121-122) - JohnK: will fix - JohnK: (line 2827) declarations must
conform to a class - discussion of formal XML issues around
AuthnContextDeclaration - taking example of Password (line 3712,
with real example starting on 3769) - Scott: this is not any formal use of XML
Schema that you would ever find - it's a documentation use - Prateek: and the reason for not putting
this in a schema-centric model was expedience? - Paul: (originally did this work in - Jeff: we're talking about putting
machinery into the schema that would enforce lines 3797-3799? - Scott: yes - JohnK: as well as lines 2827-... - Scott: doesn't think this is a big effort,
and even willing to do the work - discussion of derivation by extension vs.
derivation by restriction - Conor: has received feedback, falling into
two cases - authn context has to be explicitly
recognized - authn context has to be "at
least" X - [ACTION] JohnK and Scott to move Authn
Context Declarations to XML Schema centric approach - Rob: schedule is tight, so can this work
be done in next few days? - JohnK/Scott: yes, might have schema by
Thursday - JohnK: Kerberos (line 3925) - not all interested parties present - principal authentication mechanism is
represented - JohnL: confused by "Kerberos
Protected Transport" - JohnK: was going to do this, but didn't,
so should just be "Kerberos" - Hal: thinks right way to do this is to
treat the initial handshake (preauth, PKI, whatever) as a
property of Kerberos - Scott: the other case was this web use
case, where principal sends password to server, who happens to
use Kerberos to verify it - called
"PasswordProtectedTransport" (3819) - don't want to confuse this with
"Kerberos" - Jeff: suggests
"PasswordOverProtectedTransport", because "PasswordProtectedTransport" is
misleading - - now AuthnContext is optional -- is this a
problem? - Scott: could make it required - also, none of the 1.0 URIs should be used - JohnK: (line 4430) Secure Remote Password
modeled after Kerberos class - Rob: line 4429, parenthetical is confusing - is reference to old value - Scott: move to migration guide - JohnK: SSL/TLS Certificate Based Client Authn - Rob: same comment, move old URI to
migration guide - JohnK: X509 Public Key - Rob: mixture of old approach
("am" in URN) with new ("ac") - JohnK: will strictly use new - - needs to be clarified - JohnK: all of these public key methods are
very similar - Scott: (line 4712) not sure what
XKMS has to do with user authn - - but that seems to belong inside
X509 class - Scott: slippery slope, having this
as its own class - resolution is to drop it as a
class - Rob: add to migration doc - Jeff: suggests that we maintain an
issues list for authn context - we want to get doc out the door,
but we don't want to lose issues for future work - Rob: we can track in current
issues doc - [ISSUE] Deprecation/removal of
XKMS authn context class - Paul: prefers something other than
"keyAuthn" (ex line 4817) in all public key classes - group prefers "keyValidation" - Rob: Table of Contents needs to be regen'ed
- Scott: walking thru Metadata doc (draft 06, PDF) - changes - mainly reformatted doc to match
template - made some changes for uniformity - not many others - Version in EndpointType (line 165) - profiles have changed in 2.0, so they're
really the first version of their respective forms - are the same - Scott: still thinking on what Version means in
this context - we've never versioned a profile before - [ISSUE] Versioning in Profiles and Metadata - Scott: has considered moving away from
element-based approach to metadata, in favor of
attribute-based - but makes XPath searching more complicated - Jeff: solution could be to have separate
element for each profile supported, and to include Version info
if relevant - Scott: "families" of profiles will
be seen in Profiles doc - [discussion ...] - [resolution] drop Version, and any subsequent
versions of profiles will result in new metadata elements - e.g., if we create V2 of SingleLogout profile,
we'll either create a new SingleLogoutV2 element in
existing metadata namespace, or create new metadata namespace - issue still open regarding versioning profiles - continuing with Section 2.3 Root Elements - <EntitiesDescriptor> is just a container - <EntityDescriptor> is really the unit of
metadata - beneath that, can have either
AffiliationDescriptor or (more commonly) a sequence of one or more RoleDescriptor
(or a derivation) - AdditionalMetadataLocation allows implementations
that support both ID-FF and SAML 2 metadata to publish both
forms, cross- linked - really, is a form of versioning - [ISSUE] How to represent support for attribute
profiles in metadata - Scott: on SP side, added attribute indicating
desire to have assertions signed by IDP, independent of profile
requirements - Conor: what about on IDP side, stating that
assertions will be signed? - Scott: didn't do that, but can - Prateek: more generally, can't endpoints have way
to state what optional features they need or will provide? - Scott: will require more thinking - Conor: difference between what is wanted vs what
is accepted - Scott: the reason signing got special attention is
overhead, moreso than security - KeyDescriptor (line 503) - Scott: recollection is that EncryptionMethod
speaks to encryption OF the key rather than encryption
BY the key (which is why it states it in the doc), but needs to
verify - [ISSUE] Verify purpose of EncryptionMethod in
KeyDescriptor in metadata - SSODescriptorType (line 536) - Scott: "ArtifactLookupService" doesn't
sound right - "ArtifactResolverService"?
"...Dereference..."? - needs to be consistent with related protocol
components - winner: ArtifactResolverService / ArtifactResolve
/ ArtifactResolveResponse - [ISSUE] AssertionConsumerService ID attribute is a
string, but attr name suggests xsd:ID type - change to "Index"? - Indexes are usually thought of as numbers - can restrict values to be numeric - [RESOLVED] - [OLD ISSUE] some wanted to add location hinting to
artifact, to support multiple artifact resolvers - ArtifactResolverService will resemble
AssertionConsumerService, including Index - Artifact format will include space for this Index - [RESOLVED] - [ISSUE] SSO profile is different in how role division
is split across request response - In other profiles, request and response were
combined - doesn't think it's a problem, it's just
different - [ISSUE] SSODescriptorType shouldn't be a base - Scott: how about eliminating the type, and move
the components into SP and IDP descriptors? - Jeff: we need to determine what
must be changed now vs. what can we live with for now and
publish - Rob: could rename SP and IDP descriptors
to SPSSO... and IDPSSO... - Scott: agreed - Scott: continuing with
AttributeRequesterDescriptor (line 712) - the IsRequired attr inside
RequestedAttribute allows the expression of necessary attrs in SSO - If we add indexes to
AttributeRequestingService, you can provide a reference into metadata from attribute
queries - AttributeRequestingService was previously
called AttributeConsumerService, and someone
specifically asked for name change - Scott: dislikes "Service" in
"AttributeRequestingService" - [ISSUE] Need new name for
AttributeRequestingService [Paul Madsen taking over minute-taking] June 15, 2:45 - 5:00, Minutes --------------------------------------------------------------------------- Metadata tail-end John Linn raises concerns about the complexity of some of
the metadata mechanisms. Scott asserteed that it was in there becausee Neeustar has
implemented it and they need it in. Need to make sure that text makes clear that this is
optional. Jahan - I had thought we had decided to forgo the DNS stuff Scott - we did, but a member pushed back. [ACTION] Scott to ping Peter for additional text, subsequent
to that there will need to be a review to ensure that the appropriate SHOULDs
etc are there. [ACTION] Scott to reorganize section 4 to clarify Section 3 – Signatures Scott suggests that we create a profile of XML-Sig for
signing metadata elements. might just be stating that you're signing one of
these three elements etc --------------------------------------------------------------------------- SAML 2 Schedule June 15: V2.0 F2F in June 22: Review updates since f2f. June 29: Both Prateek and I will be out – anyone want
a focus call this week? July 6: All specification suite documents must have
incorporated all input from the list and F2F #5. Note that this gives us 3
weeks since the F2F to complete all document changes and to resolve issues and
action items. This now begins sort of a pre-last-call deadline for final
input. Depending on how well things come together, we might possibly start our
TC last call here, but we opted to allow another week before doing that. July 13: VOTE to start 2-week committee last call period
(includes external public review). July 20: Review any last call input to date. July 27: Cut-off date for TC last call input. All
outstanding issues have been dealt with according to the last call process. The
specs now become our "candidate” Committee Drafts and the TC
addresses any outstanding non-normative editorial issues August 3: VOTE to move spec’s to “Committee
Draft” status (requires YES votes from 2/3 of ALL voting members). VOTE
to move CD spec’s into 30-day Public Review for OASIS standardization
(majority vote). Edit doc’s for CD status. Notify TC admin of the start
of formal Public Review. September 7 (first call following 30-day public review): Make
sure all public review comments have been properly dispatched. Final editorial
changes must be complete. VOTE to re-approve spec’s as final Committee
Draft and VOTE to submit to OASIS for standardization. September 8-15: Complete all submission paperwork. All
submissions for an October voting period must be complete by September 15. Rob's biggest concerns are around outreach docs ---------------------------------------------------------------------------
Profiles Discussion sstc-saml-profiles-2.0-draft-10-diff.pdf To cover -Attribute profiles -Connecting to Metadata --------------------------------------------------------------------------- Attribute Profiles Prateek took us through the recent changes to the Profiles
doc docussed on Attributes. A new section provides a set of guidelines for defining
attribute profiles as well as 3 three specific attributee profiles 1) Basic Attribute Profile 2) LDAP/X500 3) UUID Jeff Hodges asked for clarification as to whether the
profiles was for the reequest/response or for the designator/values? Scott
suggested that using 'query' in the intro text on line 125 was misleading as it
implieed something to do with the request/reequest protocol - text should be
expressed instead in terms of attributedesignator and attribute. Prateek suggested that the implication on AttributeeQuery
should be noted John suggested that Seection 1.1 Profile Concepts should be
moved before Prateek's text and then refereenced. [ACTION] - Scott to clean up the text around the different
types of profiles in Section 1.1 Section 7.1 Provides a checklist of items that MUST be addressed by each
attribute profile. Scott says that bullet 2 within guidelines 'Unique URI to be
used for the NameFormat attribute of the <saml:AttributeDesignator>
element' - NameFormat is inappropriate. A profile may need an identifier but
should it go on the designator? May suggest that we need an new element more at the protocol
element. Resolution1 - we should retain NameFormat for its original
use. Do we need to carry the profile name as part of the
attribute or attributedesignator? What is the unit at which it makes sense to
specify profile. Discussion as to the relevance of being ablee to specify
profile on specific attributes. Conor - are we accounting for XML attributes? Yes. Rob- propasal that we be able to describe profile at the
statement and query level. [ACTION] - investigate profile designator for statement and
query - potentially allowing for endpoint metadata. Scott asserts that agreeeing on what to go in
attributedesignator and attribute elements is a subset of a whole bunch of
things you have to come to an agreement upon for attribute sharing. Prateek
acknowledges this but questions whether we want to think about this right now.
Agreement. Rick - two levels of profiles Basic Profile Jeff - why does xsi:type neeed to be present? To know
whether its a datetime or string etc LDAP/X.500 Names constrained to come from URN oid namespace (following
Bob) Scott - I pushed back originally on Bob's proposal. No
longer an issue. John - any BER & DER issues? Section 7.3.3 says the
canonical representation is an octet sequence. Scott- this was not Bob's
intent. So what should we do? What did DSML do? NA. [ACTION] - Scott to talk to RL Bob. UUID Profile Intent is that UUIDs occur as attribute names. Not so clear
whether there are values. [ACTION] - Prateek to ping John for clarification. --------------------------------------------------------------------------- XACML Profile Led by Prateeek Submission from XACML TC to add to attributee profile
section 'SAML Attribute Assertions may be used as input to
authorization decisions made according to the OASIS eXtensible Access Control Markup Language (XACML)
standard specification [XACML]. Since the SAML Attribute format differs from the XACML Attribute
format, there is a mapping that must be performed. The OASIS XACML TC has defined a Profile for
doing this mapping [XACML-Profile], but that Profile imposes constraints on the meta-data provided
with the SAML Attribute. This Profile describes those meta-data constraints' ACTION - Scott to incorporate into document. include
reeference to Appendix A. ACTION - Need clarification as to what is the target
namespace for the DataType element? Scott is conceerned that the profile doesn't say anything
about what can go in the XML instance. Hal doesn;t see it as a concern. --------------------------------------------------------------------------- From: John Kemp [john.kemp@nokia.com] Minutes 2004-06-16 (morning) SSTC F2F -------------------------------------
Arch overview ------------- summary of overview doc looked good. some things missing - use of queries - federation + other protocol profiles (logout, RNI etc.) - discussion of general background to saml (web services
work, ID-WSF, WSS STP) discussion of 11-20 differences as separate document instead
of as part of overview - only a bulleted list migration + what's new combined in document exec overview targetted to journalists + CEO (Paul Madsen
volunteers to take this document) AI: Paul Madsen to take the exec overview document rob: when can we get first draft of tech overview? john hughes: 22nd July (JohnH is on vacation after) hal: publish first detailed outline sooner prateek: id-ff 1.2 arch overview could be used as source
document conor: use as much as is useful - it was contributed work to
SSTC JohnH: next version of ppt on 22nd June prior to call? rob: discussion on schedule yesterday. these docs are not
part of core, but want to put out as part of last call. doesn't look like
we can do that. would hope to get them complete by august 3rd johnh: if eve can tidy it up, august 3rd id do-able rob: get normative spec. work done first. jeffh: no need to release all together paulm: exec overview draft next week rob: start in july, but prateek and i on holiday. need a
substitute chair hal: should definitely do the meeting with substitute chair jeffh: eve and/or i can do this. official business could be
done first, and then focus on technical issues rob: prateek and i will figure it out offline implementation guidelines ------------------------- charles: use ID-FF guidelines johnk: a lot of mobile specific guidance prateek: should add enterprise guidance, i'll be happy to
review hal: cumulative knowledge johnk: need to point to impl guidelines on website too, to
allow quick updates discussion of use of saml-dev list members or adding a wiki AI: Scott will investigate use of wiki on Oasis site rob: when can we get first draft? charles: end of july... migration doc (scott, prateek) ------------------------------ scott: very busy, won't get to it until late july, early
august prateek: also busy scott: will happen somewhat organically in liberty rob: (reviews schedule) we require attestations before
august 3rd prateek: "attestations" by some definition... rob: talk about attestation process hal: issue is granularity. doing every combination will not
fly. rob: we're not doing implementation yet hal: points out ability to waffle scott: don't need to cover the whole spec. we required 3
doing each piece of the spec. in 1.1 hal: definition is loose enough to lower the bar rob: but is anyone actually going to do this? jeffh: sun may attest, but depends on where we set the bar scott: should agree on an errata process. just want to be
able to fix the spec. don't know oasis rules. rob: no Oasis errata guidelines - may not modify spec. till
public review is done jeffh: but should not be known flaws in spec. when go public hal: oasis did not ack. AI: chairs to put item regarding errata process on the
concall agenda hal: recommends XACML errata process rob: (break?) prateek: should discuss attribute profiles GUIDs afterwards -- break
prateek: start with attribute profiles johnh: yes johnh: want to be able to transport PAC (or parts thereof)
in SAML attrib stmt. prateek: these are GUIDs, right? johnh: (explains DCE use of GUID, friendly name) prateek: we understand johnh: not seen the ability to do this in the specs. prateek: optional XML attrib for friendly name. we struggle
with the attrib value - is there one? johnh: repeats use-case prateek: all of that is captured in attrib designator scott: trying to understand what the value is johnh: value is GUID scott: profile is "backwards" hal: well-known uuid that represents Principal? prateek: summary - name is UUID, value is also UUID johnl: line 907 - dashes - is this a common way to represent
UUID as URI? prateek: we need a normative ref to UUID as URI syntax scott: uuid as uri sidesteps some of the punctuation issues rob: would that be acceptable (UUID as URI)? johnh: these are just nasty unreadable strings usage of UUIDs (discussion of what to reference) johnh: that would be acceptable AI: (Jeffh) Resolve status of RFC scott: more concerned about what it is we're trying to do
here. all attribs in PAC must have an value associated with the name.
(walks through his understanding of the profile) hal: it's little more complex. johnh: extended PAC is more complicated, but we really need
only a subset. You'll have only a single instance of a Principal.
we just want to carry the UUID+friendly name of Principal + Principal's
group info rob: can we do an example? scott: (draws it) can we define a friendly name attrib in
the SAML namespace? hal: call it DCE name instead of friendly name? scott: we already have a friendlyname attrib. so just use
that --- example --- <Attrib NameFormat="URI"
Name="urn:uuid:..." FriendlyName="Principal"> <attribValue
FriendlyName="(principal-name)"> urn:uuid:representing:dce_principal </attribValue> </Attrib> --- end example --- value itself conor: don't need to argue about element vs. attribute (discussion of multiple lists of values mostly between hal
and conor) rob: need to specify this in the profile - is name of
profile relevant to profile? scott: profile is addressing two things - primarily use of
UUIDs in attrib values. The secondary purpose might be to call out
the applicability of this to DCE use-case. No need to call out
that these attribs are part of a format. hal: should document the well-known formats for attribute
name. there's a short list AI: (Scott) to document the well-known values for the DCE
attribute name scott: silly to add sub-element to attribute value when we
already have a structur efor this (discussion of XML attribute values) rob: leave it to profile johnh: (signs off) (no answer) PKI Cross-domain profile (pki-cross-domain-profile-draft-01.doc) --------------------------------------- rick randall: (introduces himself) rickr: profile user is a large gov't agency interested in
SAML rickr: (explains use-case) rob: want to exchange attributes to allow authz rickr: subject name is carried, they want xml encryption +
signature hal: are they using public keys for subject confirmation? hal: info about subject could be obtained from cert. rob: in the PKI environment - there is one domain issuing
certs for its users. Other domain issues certs for its own users. There is
mutual auth between domains, but one domain doesn't know the other's
users scott: grid community has same use-case rickr: (explains profile) rickr: auth over client-auth SSL paulm: could be other type of cert-based auth hal: doing exact match on subjectname of cert. query will require
encryption prateek: is this the Shib use-case? scott: yes, not necessarily doing client-auth rob: and the grid... scott: main issue is use of temp ID during auth exchange.
there is a weak implicit presence proof. there is nothing that connects
the auth exchange betwene the client and domain b and the attrib
query at domain a. so, it's dependent on policy at domain a. johnl: decision at domain a has nothing to do with user
presence + confirmation hal: this is not the issue - some people only want to
release info when user is present. (gives example) rob: no tie between the auth exchange and the attribute
release scott: as long as authorities understand that there is no
ability to determine user presence.... rob: short-term identifiers cna be used to do this rob: customer is not concerned about another random site
doing queries? rickr: PKI trust is already established between domain a and
domain b prateek: SAML 2.0 can model these flows scott: we'd need to check the encryption requirements.
domain b can encrypt keys for domain a. scott: can sign the request, can pass the encrypted name
identifier, and we support attribute encryption (as well as encrypting the
entire assertion). steve: subject is encrypted for different party scott: encrypted thing is the subject of the query hal: need to re-encrypt scott: why? (symmetric key is encrypted with public key of domain a) hal: at minimum should use a different public key scott: why re-encrypt? steve: sender needs to keep a copy of the blob. (discussion of how to do this) hal: you have to correlate these things. profile could say
that you could just send the encrypted id back, or re-encrypt. rob: we say it must be the same subject going back scott: id must be identical rob: what does exact match, "identical" mean in
this case? We should clarify this scott: encryption should not affect this equivalence - don't
mean to preclude a name id being re-encrypted. hal: one way to disambiguate is to differentiate name id
from encrypted name id AI: (Scott) Will fix spec. to be more precise about use of
encryption with name identifiers. Steve: profiles should say something about this - for this
one, profile should state that either the name identifier will come back
with same encryption, could be multicast encrypted, or re-encrypted by
domain b. prateek: this use-case is covered prateek: what is the status of this profile? we can meet
your requirements? rickr: yes. they want to do a procurement, and want a
specification to point to. prateek: already done. FORMALLY: Rick (and customer) should read and accept the
OASIS IPR policy. rob: (explains IP policy) rickr: willing to accept now scott: reads text to meet previous AI rob: need to see it written down prateek: rick should send an email making a patent
disclosure to TC mailing list prateek: does this have to be a 2.0 work item? Alternative is to make a separate document to decouple from
current release schedule. mikem: two months ago, we closed for new work items different timeline jeffh: this raises the SAML versioning issue again (versioning discussion) paulm: if just a resource issue, then i would be happy to
help get this work done in saml 2.0 timeframe hal: goal is to have something official out of oasis as soon
as possible (discussion of the cut-off date) prateek: (summarizes) (group discussion of profile name) hal: if you give a general name, there will be pressure to
generalize the profile scott: should be fairly general prateek: is there an issue? hal: no well-formed profile yet prateek: what instruction are we giving? group: new ref of draft incorporating comments received
today scott: if goal is just product conformance, then conformance
would be at product level, and profile would be quite general. rickr: customer wants profile to be more stringent prateek: agrees that we should work this out within the TC,
rather than leaving it to RFPs etc. scott: seems like a missed opportunity if we write the
profile too narrowly rickr: (lays cards on table) would very much like to include
this profile in main profiles document, and explains reasoning hal: maybe we should reconsider the cut-off date, if we have
a full profile document conor: acceptance for what you want to do, it's just a
question of timing scott: look at SSO profile for example (and explains how to
reference other profiles) (group) profile can treate domain b auth server at domain b
destination web site as same entity for purposes of profile. (if you
don't want to use custom product for destination web site) rob: other questions? rickr: what happens after new version of profile? rob: (explains process) we'll discuss this on a call steve: any general disposition on profiles? AI: (chairs) discuss + resolve general approach to new
profiles rob: do rest of profiles document after lunch scott: want to leave with a good idea of what profiles need
to be in the document prateek: modify schedule to do profiles next, instead of
conformance rob: (modifies schedule, adjourn for lunch) -- lunch -- From: Charles Knouse [cknouse@oblix.com] PROFILES (Scott) Section 4.1.6 Use of Metadata Discussion of coupling of profiles with metadata. Prateek: How does metadata coupling show up in conformance? Scott: Intent not to require use of metadata to configure
implementation; but if using, then conform to normative rules for use. Section 4.1.4.3 "Security context SHOULD be discarded once
SessionNotOnOrAfter reached". Discussion of what security context is. "derived from
assertion", ACTION ITEM: Jeff to add security context to Glossary. Should be SHOULD or MUST? MUST in ID-FF. Leave as SHOULD;
explain implications in Implementation Guidelines. Scott: Profiles to be done 1. Single Logout 2. NameID Management 3. Authn Query 4. Attribute Query 5. Authz Query 6. Assertion Request 7. Artifact Resolution Only profile 3-7 for synchronous exchange (e.g. SOAP
binding) What is Authn Query for? Rob has seen use case. Should 1, 2 be pair of profiles for front channel and back
channel? optional vs. mandatory for conformance. Conclusion: single profile. Profiles that are done: Browser SSO, NameID mapping, ECP SSO Sections: Single Signon Profiles: Browser SSO. ECP SSO, Single
Logout Queries: Authn, Attribute, Authz NameID Management AssertionID Request Artifact Resolution ACTION ITEM: Jeff to help with sequence diagrams for
profiles. -----------------
Scott: Should change Response to AuthnResponse, since every
one keeps using that? no SAML Core message formats e.g. AuthnRequest Response Bindings: HTTP Redirect Form Post HTTP Artifact HTTP URI SOAP PAOS Messages over bindings, e.g. HTTP-Redirect(<AuthnRequest>) SOAP(<AttributeQuery>) Profiles, e.g. Browser SSO ECP Logout NameID Management Roles IdP SP Conformance statement: e.g. Product in role IdP implements Browser SSO profile consumes HTTP-Redirect(<AuthnRequest>) responds Form Post(<Response>) Scott: SOAP has additional interop requirements, e.g.
security, which metadata does not cover. How granular should conformance statements be? Too fine grain has negative impact for marketing. Precise product specification vs. mandatory to implement Need term from claims of support; want to use same language
for conformance statements Hierarchical approach: higher level for marketing, lower for
product specs General agreement that SSTC needs to define the language,
else someone will. Proposal for course grain conformance matrix
IdP
SP Web Browser SSO and logout Name ID mapping and management Mobile device Assertion query/request Scott: lumping queries together a mistake. Conor: good for implementers, doesn't solve deployers needs Prateek: conformance for vendors, not deployers Jeff: approach worthwhile, may disagree with individual
categories; Scott: Prateek: As ISV, sees Scott: Likes Conor: list of all possible knobs in SAML (!) Jeff: to make workable, not a lot of options in rows Scott: in Conor: battle in Scott: Displayed rows: features (e.g. SSO using Artifact Profile) columns: roles (IDP, SP Basic, SP, LECP) cells: MUST, OPTIONAL, blank Jeff: Prateek proposing unit of conformance is a cell, Scott: tool for combinatorial explosion of profiles x
messages x bindings Scott: no MUSTs in ACTION ITEM: Rob to enumerate the implementation
declarations/claims of interest. Prateek and Scott will contribute. Darren: agrees with new format and agrees need more
granularity than -----------------
SP uses PAOS; IdP uses SOAP Flow 1. EC -> SP: HTTP Request + PAOS header 2. SP -> EC: PAOS(<AuthnRequest>) + PAOS
header + ECP header 3. EC -> IdP: SOAP(<AuthnRequest>) 4. IdP-> EC: SOAP(<Response>) + ECP header 5. EC -> SP: PAOS(<Response>) 6. SP -> EC: HTTP Response Schema for ECP header goes into Core. -----------------
Subject Confirmation Scott: Assigned own subsection and type used for derivation
in subsequent sections. Also common attributes Scott: "Authenticating the subject" wrong? Jeff and Frederick: line 587 "specifies a subject"
should be "provides a means for a relying part to verify the
correspondence of the subject of the assertion with the party with whom they
are communicating." Scott: subsequent "authenticates" to be
"confirms". Scott: IPAddress attribute take the place of
<SubjectLocality> for products that need the user agent address (e.g. to
stick in a cookie). Should remove <SubjectLocality>? No resolution yet Discussion between Rob and Scott on whether in the Artifact
profile, does the browser present the assertion to the SP? Conor and Scott: In Artifact: browser presents assertion by
reference; In Post: browser presents assertion by value. KeyInfoConfirmationDataType Can hold multiple KeyInfos for multiple confirming entities.
Everything inside each KeyInfo must refer to the same key. Can be used for impersonation. AuthnMethod removed in favor of AuthnContext; AuthnContext
now required. SessionIndex moved from Statement to AuthnQuery. Cleaned up MUSTs for certain status codes. Cleaned up name IDs to support encrypted IDs. Removed authentication methods from Section 8. Changed language in Section 8.4.7 Persistent Identifier to
be less specific. Prateek to review. John Linn's issues (e-mail Monday June 7: comments on
sstc-saml-core-2.0-draft-14-diff.pdf) Assertion ID uniqueness OneTimeUse confusion: Hal: intended for attributes and authz decisions;
doesn't know how this applies to authentication John L: should tighten language to indicate this Scott: Bob M. suggested text missing on what
NotBefore/NotOnOrAfter means for attributes. ACTION ITEM: Hal will look at OneTimeUse text again and
attempt to clarify. DNSAddress vs. DNSName Security context needs to be in the Glossary. ACTION ITEM: John K. to clarity text on 909-911 on
SessionIndex. Steve: Why is SessionIndex required? John K: For logout. If you don't care, can always be 0. Conor: Does everyone support multiple simultaneous sessions? ACTION ITEM: John K. to look up why SessionIndex is
required. Discussion on what to do if signature verification fails?
Relying party SHOULD not rely on rely on assertion (!) Scott: Nothing in spec that requires second level status
codes. Can add codes that can be used. Implementations can have switch to report or suppress
secondary codes. Also can be logged. -----------------
Line 900: Artifact MessageHandle at least 16 (up from 8)
random bytes. Scott: Planned to steal 2 bytes from MessageHandle to hint
on AssertionConsumer metadata. Rob: If using SHA-1 hash for handle, need all 20 bytes. Scott to look at this again. Scott: security discussion in SOAP binding (sections
3.2.3.2, 3.2.3.3, 3.2.3.4) should be in conformance instead. Hal: Should be option to use WSS. Steve: Should call out several options MAY be used for
integrity and confidentiality. General confusion and amazement about section 3.2.3.1 on
HTTP headers and caching. Hal: Line 324 should declare the intention to not cache
response. Prateek: Preceding Sections 3.2.2.3-3.2.2.5
(protocol-independent SOAP) refer to sections 3.2.3.2-3.2.3.4 (SOAP over HTTP). ACTION ITEM: Scott to propose alternate text for section 3.2.3.1 strike 3.2.3.2-3.2.3.4. rewrite 3.2.2.3-3.2.2.5 Jeff: Some security choice needs to be mandatory to
implement, e.g. TLS. Section 3.4.5.1: similar issues to section 3.2.3.1. ACTION ITEM: Hal to get expert advice on how to prevent
caching by proxies and user agents. John Linn's issues Protecting association of RelayState with other SAML message
elements. Does ID-FF Security Considerations document issue? Need to say something in SSO profile and security
considerations about the issue. -----------------
Because of lack of quorum, recommendations will be made for
resolution at the next quorum call. CORE-7: SOAP Version in Protocol Binding RECOMMENDATION: CLOSE. Leave binding at v1.1 CORE-9: Wildcarding and Extensibility in the SAML Schemas Leave OPEN CORE-12: Consider Changing Name Identifier Format Default
for Issuer RECOMMENDATION: CLOSE. In prose, state the default is
"entity". CORE-16: Inconsistent Naming RECOMMENDATION: CLOSE. Make "Reference" to
"Ref" change. CORE-22:URIs vs.Prefixed QNames in Status Codes RECOMMENDATION: CLOSE. Scott to rework specs to use URIs as
appropriate. CORE-25: Require SessionIndex on LogoutRequest RECOMMENDATION: CLOSE. Scott to update prose to explain why
not required. CORE-27: Consider Limiting Datatype of Attribute Name Leave OPEN BIND-3: Establish a Mandatory Profile Leave OPEN. TECH-1: Identity/Service Provider Terminology and Domain
Model Leave OPEN. TECH-3: Impersonation Using SubjectConfirmation and KeyInfo RECOMMENDATION: CLOSE. Check with Ron if HolderOfKey issue
resolved. TECH-4: Glossary Additions: Artifact, Binding, Profile Leave OPEN until associated action item is done. TECH-5 Improve Federation Terminology Leave OPEN until associated action item is done TECH-6 Highlight Privacy Considerations Leave OPEN. TECH-7 Add/Correct Instance Examples Leave OPEN. From: Jeff Hodges [Jeff.Hodges@Sun.COM] Sent: Friday, June 18, 2004 12:13 PM To: Prateek Mishra; Robert Philpott Cc: Jeff.Hodges@Sun.COM; Eve L. Maler Subject: raw notes from Thur 17-Jun -------------------------------------------------- Thur Morn – Jeff Hodges 17-Jun-2004 Fredrick Hirsch -- Sec & Privacy issues going thru changes to latest rev of the doc intends to ref other docs eg Lib Sec & Priv Guidelines Hal notes that there may be other orgs that are
privacy-centric that have docs we may want to also ref notes that achieving privacy isn't necessarily simple or
a clear goal in itself so upshot is that we probably want to catagorize the SAML
features that can be used in crafting some notion of privacy in addn to
ref'g the other docs Fredr still needs to insert the profile-specific sec cons
from the SAMLv1.1 prof spec Fredr commenting on the addn's to the doc.. binding of identity to key -- clarified notions [various detailed review comment ensued where Fredr
maintained his own detailed notes] scott will have suggestions about URI bindings kemp: can we update the ref to "reliable
messaging" stuff? fredr: concurs -------------------------- [capture my update wrt app/saml+xml MIME media type
registration] draft-hodges-saml-mediatype-00 has been pub'd as an
Internet-draft. sent it to ietf-types@iana.org for review. Graham Klyne sez it is "looking fine" to him
modulo the "and/or" cite (in the sec cons section) of diff versions of SAML. draft-hodges-saml-mediatype-01 will be pub'd soon -- only
diff is that it will be rfc3667/8-compliant. so reg of application/saml+xml is in the pipeline and the
stake-in-the-ground has been publicly set. so in our samlv2 spec, in the one (we believe) place where
this media type is mentioned, the worst case we will have to do for final
samlv2 specs in the fall is to say something like.. official IANA reg of application/saml+xml is pending, see [draft-hodges-saml-mediatype-xx] (informative reference).
in the meantime implementors and deployers SHOULD use
"x-application/saml+xml" until said reg is accomplished and
[draft-hodges-saml-mediatype-xx] is pub'd as an RFC. --------------------------- Review of... Security Analysis of the SAMLS SSO Browser/Artifact
Profile Thomas Gross 6.1 Step 1 prateek: this step is actually out-of-scope of the pub'd
SAML spec ie. the UA determining that the "source" site
is indeed the expected/ desired source site is out-of-scope of the pub'd
sAML spec this is a reasonable comment technically. scott: however the author presented the above as if it
*is* a portion of the spec and thus the paper is arguably misleading [ the paper says "In the first protocol
step,...", but the paper's step 1 is *not* normatively specified in the SAML spec ] wrt "msg format attack" -- this is an attack on
HTTP in general in that parties may attach any amounht of gunk to a URL and it
also refers to repetition of some steps that are not ... it is not
clear... hal: every http msg is subject to this attack, so it
isn't particular to saml "user tracking" subsection in section 6.1 of
the paper refers to an issue that is out-of-scope for SAML and is not required
in any SAML prot step 6.2 Initiating the Redirect to the Destination Site scott: uncomfortable with the discussion of relating the
artifact url to the destination site. the author is apparently loosing the context that there
is a seperate base of knowledge that a given "assn consumer
svc" and a given "dest site" is linked. without that knowledge
one can hand an artifact to the wrong party prateek & Hal: but that isn't a viable threat because
just obtaining an artifact is not necessarily a concrete threat in the
overall scenario -- one may not be able to dereference it and so it is
worthless. 6.3 Step 3: Redirect to dest site wrt "lack of authn" para, the bindings spec
does indeed specify using TLS as a SHOULD thus it is a misleading claim to imply that the spec does
not specify authn at this point. 6.4 Step 4: SAML Request wrt "specification of the source site lookup"
para: the author is apparently mislead by the wording in the saml bindings
spec, or that his point is that the spec doesn't make things
sufficiently clear here. however, in line 541 & 542 of samlv1.1 bindings spec,
we do specify a a MUST for bilateral authn. prateek: thus the author is saying that the bindings spec
is not sufficiently clear that the source site needs to pay
attention to *who* is authn'g and def'g an artifact. ie it needs to
apply some policy. rob: in bindings 1.1 line 579 notes that the source id
is used to determine source site *identity* as well as location,
thus the author is in error. line 551 in the 1.0 bindings spec. wrt "one-request property of the SAML artifact"
para: prateek: artifacts are explicitly specified as being
short-lived. scottc: tho the author's right about that there being an
attack where an attacker may capture an artifact being retgurned from
the source site to the UA and then front-run the UA and present it to
the dest site and thus impersonate the UA. 6.5 Step 5: SAML Response wrt "one-req property of the saml artifact"
para: scottc: author is saying that this property is hard to
impl Hal: author is saying that "simple things are
easier to make secure, and here's a complex thing" fredr & scott: this is a good catch, in actuality prateek: so we should spec in samlv2 that dest sites as
well as source sites should enforce the one-time use of artifacts. all: yes. wrt "multiple services on one host" para: scott: author is claiming that because the sec is
host-name-based (which is false), then ... but the granularity is "destination 'site' "
where a dest site can well be mapped to specific sec credentials, and one can
host mult such sites on a given web server. hal: author's prob rite... scott: the host-named-based claim made by the first
sentence in this para is fundamentally misleading. prateek: so the way we should reply to this is that this
is broken in the paper, but that yes, we need to make the samlv2
spec more clear about the various means available to the source and
dest sites to identify each other and recommend strong means as
appropriate. 6.6 step 6: response to the browser wrt "specification of this step" para: scott: note the sentence "We also assume that it
has the same sec props as in step 3." which implies that there's no
security becuz that was the author's claim back on step 3. thus we rebut step 3 and thus we should rebut here. wrt "HTTP referrer tag" para: scott: this is a good catch. in samlv2, our specifying the dest site maintaining
state mitigates this also, delivering artifact via POST eliminates it prateek: concurs 7. Attacks 7.1 connectino hijacking / replay attack wrt "possible solution" para: prateek: the spec strongly encourages the use of TLS,
and if so used, this is moot. 7.2 MITM attack 7.2.1 prateek: even tho it is out-of-scope, we'll add lang to
samlv2, that you shouldn't give yer id & pswd to a site wihtout
authn'g the site first ie. the author simply identified "phishing" as
a threat, which is a known issue wiht the web and endemic to it. 7.2.2. other MITM attacks scott: the prob here is the sentence " as the saml
sso prot specs no security props for this step 0, we can assume that the
connectioon is unsecured" prateek: the resp to this is that indeed use of TLS is
recommended. 7.3 http referrer attack prateek: first point of rebut is that TLS is indeed
rcmd'd in spec scnd point - yes we should mention use of some sort of
referral clearing 3d pt - is that in samlv2 we'll ahve the artifact POST'g 8. Vulnerability of the SSL/TLS Binding scott: mid of para 2, there's some miss-statements, aka
wrong, things 9. conclusion johnl: if you assume that saml is deployed in an environ
with no TLS, then yes, there are design issues with saml. but the domain
of applicability of SAML is wider than that. ----- prateek: am looking for an owner for someone to take the
above and start a document johnl: will work with prateek to draft it up. AI: johnl and prateek to draft up a document commenting on,
acknowledging, and clarifying certain points in the IBM Research Report RZ 3501
(# 99427) 06/30/03 ---------------------------------- working on the conformance spreadsheet longish not-terribly-conclusive discussion about what it
means to "support the metadata spec" scott: a tentative suggestion was made that mebbe we want
to try to somehow make the use of particular elemens requiring the
use of metadata easier to use in the case where one is not
actually using the metadata spec. recommendation: make spec set more generic where it
referes to metadata, make guidelines for creating new profiles be
more specific wrt needing to spec needed metadata. -------------------- the TC formally thanks adjourned. ============================================================================ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]