[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for F2F, Morning Wednesday 11 June 2003
Plan to update with attendance after close of F2F.
Minutes for WSSTC F2F, Morning Wednesday 11 June 2003
Dial in info: 1-425-703-7700 Passcode: 4545/4546/4545
Minutes taken by Steve Anderson
======================================================================
Summary
======================================================================
Votes:
- Minutes from 3 June 2003 meeting accepted (unanimous)
New (General) Action Items:
- Editors to add common interop pitfalls to spec
- Editors to update table in core spec that indicates when to
use wsu:id vs id defined by other schemas
- Editors to look into SHOULD vs. MUST for order of encrypted
elements
- Editors to update spec to require Zulu time
- Hal will update interop spreadsheet based on emails sent
- Chris to post MS contact name for further interop testing
Issues List Action Items & Status Updates:
- 25: resolved to not support
- marked PENDING
- 62: Editors to add text for QName versioning solution
- marked PENDING
- 67: Hal to begin editing a Usage Label document, which may
transition into a profile
- marked PENDING
- 70: Editors to reflect mustUnderstand resolution in docs
- resolved that mustUnderstand on Security header simply
means you are aware of the WS-Sec spec, and there are
no implied semantics
- marked PENDING
- 71: marked CLOSED, with pointer to related issue 84
- 72: separated into discussions on Timestamp trace and Expires
- Timestamp trace: resolved to remove this from core and
possibly put into another doc
- Expires:
- Editors to 1) change lines 1263-1264 of core-13 from
"it is STRONGLY RECOMMENDED that recipients ..." to
"Recipients MUST ..."; 2) change introductory paragraph
around lines 1234-..., clarifying the expiration for
security purposes rather than application purposes,
and clarifying the consideration of clock skew
- Editors to make Timestamp header a child of Security
header, and to remove the ability of Expires to stand
alone (section 10.2.2 moves to child of section 10.3)
- Editors to clarify lines 1243-1244 of core-13
- marked PENDING
======================================================================
Raw Notes
======================================================================
>
> Agenda:
>
> 1. Roll call
>
- Attendance attached to bottom of these minutes
- Quorum achieved
>
> 2. Review minutes from previous meeting (6/3/2003)
> < http://lists.oasis-open.org/archives/wss/
> 200306/msg00025.html >
>
- [VOTE] unanimous consent, accepted
>
> 3. Interop test findings and discussion
>
- Kelvin: spreadsheet divided into 3 scenarios
- each participating company listed
- Prateek: what was final version of interop draft?
- Hal: 6, and there were corrections to that
- it may make sense to update after interop
- Kelvin: on right side of spreadsheet are comments taken at end of
day yesterday
- encouraging to note that it's not a long list
- will go around room and give people a chance to share experience
from interop
- Merlin: none of the issues were WSS issues, were mainly
interpretation issues
- Prateek: what other specs created confusion?
- XML-Encryption was a big one
- Phill: reason VeriSign's implementation didn't do scenarios 1 & 2 is
that it is an actual product, and the product doesn't support such
uses
- Eric: surprised that we didn't have too many signature problems
- Kelvin: and we did a straw poll of whether people were using same
signature implementations or their own, and it was mostly unique
implementations
- Jan: we should do this again after spec is published
- Peter Dapkus: spreadsheet is missing some client results from BEA
- Martijn: would like to see a different interpretation of the list
- if there isn't an X, it may not have been tested
- in particular, Cyclone's machine died midday, preventing further
tests
- Peter Dapkus: can spreadsheet reflect failures vs. not tested?
- Kelvin: can gather that info offline
- Martijn: would like to post this spreadsheet in Kavi, and update
as people do private tests
- Hal: uncomfortable with that, with possibility of journalists making
something out of it
- Kelvin: could post to private area of Kavi and allow updates there
- Henry: there was an issue of UTF-8 and Byte Order Masking (BOM)
- if not implemented correctly, will fail
- also, didn't see any negative testing
- Hal: did anyone try bad passwords?
- Peter Rostin: did try it, but not sure if others did
- Henry: need interoperable behavior for failures
- Hal: observed that security properties are very subtle
- in some cases, had to research XML-Encryption, then FIPS, then CBC
padding
- what appear to be minor changes can have big impact
- Kelvin: Hal did a great job on the interop spec
- Kelvin: other general comments included that future test should
include company identifier in the ping message
- Kelvin: on spreadsheet, we're scrolling to the right
- on left side, summary of what we found, and on right side, a
categorization of whether it is a spec issue or not, etc
- namespace issue had been addressed, but not caught in people's
implementation
- open issue already with key identifier
- had a number of SOAP, WSDL, etc issues
- Chris: we learned alot about how to make future interops more
crisp
- Hal: part of the problem is that SOAP 1.1 & SOAP 1.2 take very
different attitudes towards HTTP SOAPAction header
- Hal: one of the things I tried to do was to not restate what
was clearly stated in other specs
- if other specs gave a choice, interop spec gave a specific
directive
- Merlin: could write an appendix on interop issues
- [ACTION] Editors to add common interop pitfalls to spec
- Hal: concerned with this direction
- Chris: good idea to remind the reader of this passage that they
still need to do due diligence and read those other specs, and
not simply take these comments alone
- Kelvin: concerning multiple signatures, we learned that we
need to be more crisp
- Merlin: for instance, had a very specific state machine written
strictly for the interop scenarios
- Kelvin: on to line 13
- Hal: thinks people misinterpreted the scenario
- Chris: flagged this as needs more research to see if there is
more that needs to be added to spec
- 14 & 17 related, and worded wrong
- Hal: XML-Encryption specifies that a count should be at end
and pad out to the end
- there is explicit directive on padding algorithm, and many miss
it
- Kelvin: line 16 is just basic XML Schema
- line 18 was an implementation issue, not a spec issue
- [ACTION] Editors to update table in core spec that indicates
when to use wsu:id vs id defined by other schemas
- Hal: proposed text a week or so ago to fix issue with line 20
- Chris: there are situations where a MUST cannot always be true
- Hal: hadn't seen that
- [ACTION] Editors to look into SHOULD vs. MUST for order of
encrypted elements
- line 21
- Hal: we should consider requiring people to always using Zulu
time
- Chris: thought that was already in there
- says UTC format, which is different than the timezone of the
value
- Prateek: we went thru this in SAML, and it greatly helps to
specify Zulu time
- [ACTION] Editors to update spec to require Zulu time
- line 22
- Hal: order matters, and question is how you determine the order
- proposed a few different ways of doing that
- Kelvin: we'll get into that later
- line 23
- Hal: interop clearly stated 3DES-CBC, so people didn't follow
it
- don't think we want to restrict algorithms in spec, that's more
of a WS-I profile exercise
- line 24
- Chris: similarly, this is more of a WS-I BP exercise
- first 2 bytes in a SOAP message can be a BOM
- Kelvin: great job to those who participated
- found that docs work
- Chris: learned that we need to have Hal write our interop docs
- big thanks to Hal
- Peter Rostin: learned we need to state more about how we expect
people to use this, because there are surprising variations
- Chris: isn't that more in domain of WS-I BSP?
- Tony: that WS-I effort will get underway next week
- Chris: lots of same people involved in that group
- Tony: trying to correlate work we did over last 2 days to the spec
- sees that there are a few issues to address
- should publish a draft-13
- question is next step, where to go from there
- Chris: we've clearly surpassed the three elements of interop that
OASIS requires
- when through the spreadsheet, and even with connectivity problems,
over 66% of the more than 300 cells are marked positive
- Phill: can people speak to press about these positives
- Kelvin: TC can't really control it
- but, would be very disappointed to read article tomorrow stating who
participated and who didn't, etc
- can say that we've had good progress
- Hal: concerning interop, after talking to people informally, there
are corrections and notations that should be made
- [ACTION] Hal will update interop spreadsheet based on emails sent
to him, and will post to Kavi
- since the raw version went to mailing list last night, the updated
version should go there as well
- can also go to document repository, and be marked TC private
- Chris: his counterparts mentioned value in continued testing
- they have an IP address where their stuff can be tested
- mail list is probably not best place to circulate that
- Kelvin: there aren't any good, secret ways of doing that through TC
- Peter Rostin: can just post each company and a contact
- [ACTION] Chris to post MS contact name for further interop testing
>
> 4. Top down (lightweight) document review/walkthrough
>
- skipped
>
> 5. Discussion of open issues, review latest issues list
>
> 11 PENDING Pick date for OASIS submission date after initial
> drafts available
>
- Chris: on agenda for tomorrow
>
> 25 OPEN Core: How can a Signature element occurring outside of
> the header be referenced?
>
- Chris: Ron was to send proposal to list, not sure if it happened
- Hal: he indicated that he'd be satisfied if spec said this wasn't
supported
- Chris: is there any objection to this resolution
- Hal: Thomas had responded to one of my comments that he wants to
spread signature elements throughout message
- Tony: thinks that is really troublesome, would favor not supporting
- Hal: not necessarily in favor of Thomas' suggestion, and may not
even be representing it correctly
- Chris: we'll resolve this as unsupported, and see if Thomas has any
objections
- PENDING
>
> 30 PENDING How should XML be explained
>
- Phill: has inserted text into his docs
- Chris: will leave as PENDING
>
> 31 PENDING Should use OASIS Namespace
>
- still waiting on OASIS
>
> 62 OPEN Versioning Mechanisms
>
- Kelvin: Jerry did send proposal to list
- Jerry not on list
- Chris: there was discussion on last call on different mechanisms
- thought Jerry was going to propose specifics
- Tony:
- Chris: Thomas posted comment about our QNames, based on URIs,
implicitly having version information
- seems very straightforward, and would solve the problem
- QName's namespace identifier has the URI
- Resolution: Adopt a versioning scheme that has version information in
the URIs
- [ACTION] Editors to add text for QName versioning solution
- change to PENDING
>
> 67 OPEN Resolve usage labels
>
- Tony: there is a proposal up there now
- Hal: proposed everything except the actual symbols
- if we are happy with approach, just pick identifiers
- Tony: slight modification, each profile should state which labels
(and therefore usages) are to be used
- don't want to be limited by core
- Hal: concerned that semantics may be different
- Tony: don't see the practical potential danger there
- there may be specific labeling requirements for each profile
- Chris: there was discussion previously about industries having
different labels
- concerned about trying to put universe in one doc
- Hal: imagines having a consistent set in core, and profiles identify
applicable subset
- Chris: do you have a set in mind?
- Hal: yes, was included in posting, had about 5
< http://www.oasis-open.org/archives/wss/200305/msg00008.html >
- going through them
- Hal: the model here is a very authorization-specific model
- may not accommodate all intentions
- Chris: wondering whether or not the discussion of the base set of
usage values needs to be put in core
- Hal: could make separate doc, but wanted to avoid separate docs
defining the same semantics
- wants symbols defined in OASIS namespace
- discussion of defining symbols, but not complete semantics
- not deemed a good idea
- [more discussion]
- Hal: open to making a separate profile
- Chris: thinks we'll make more progress
- Kelvin: we need to assign an editor for such a profile
- Thomas: thinks message body will need these labels, so they'll have
to define them again
- Hal: this brings up an earlier point of security components in body,
vs. just the security header
- (related to issue 62)
- Jeff: that is a significant decision to make
- Chris: thought we already decided to stick to header
- Jeff: thought so too
- Hal: yes, intention was to keep implementations from hunting through
whole message by keeping security elements in security header
- a change to that would be a fairly radical departure
- Thomas: not proposing we specify the message body stuff
- saying that some security stuff may need to be repeated in body
- resolution: start a separate profile, with Hal as editor, where
motivating scenarios can be captured
- Jeff: suggests it not be a formal profile doc, but rather a proposal
- [ACTION] Hal to begin editing a Usage Label document, which may
transition into a profile
- change to PENDING
>
> 69 PENDING The specification is vague on the topic of Key
> Identifiers
>
- Editors have chatted, and will be reflected in next round of profile
docs
- leave PENDING
>
> 70 OPEN The specification needs to clarify usage of
> S:mustUnderstand. There were several opinions on what
> understanding would include: understanding and processing
> <wsse:Security> header element and all its sub elements when
> the header element is tagged with mustUnderstand="1",
> understanding but not processing, tagging all child elements
> with explicit S:mustUnderstand values of "0" or "1"...
>
- Hal: there has been months/years of discussion in PKIX arena in this
area
- no reason for us to repeat it all here
- Phill: there is a good reason to address it here
- reason for criticality is to break things
- if you don't understand something, stop & discard the received item
- Hal: problem was the there were features that implementations could
recognize, but don't consider relevant to them
- basically not eager to rehash this discussion
- need to capture and summarize their discussions
- Chris: we need to take a position
- Hal: problem in PKIX was that they took a position, but people
determined that the position was ambiguous
- Chris: we need to make an unambiguous position
- Hal: is the problem here different that the problem in PKIX?
- Phill: we could declare that mustUnderstand not be used within
Security header
- Chris: can put mustUnderstand on top level Security element
- what happens to sub-elements?
- Tony: could leave that to policy
- Phill: thinks that for this implementation, there are no requirements
for mustUnderstand
- the security header itself can't be signed, so a mustUnderstand bit
can't be trusted
- Chris: we could say that if you see a Security header, and you don't
understand it, you SHOULD fail, and if the security header has a
mustUnderstand bit, and you don't understand it, you MUST fail
- Hal: going back to inability to sign security header, is that right?
- Phill: not without putting it in another security header
- Chris: could use enveloped signature
- Chris: trying to get agreement at the top level of the decision tree,
where a sender can dictate failure if the recipient knows nothing
of WS-Security
- Frederick: so agrees that if you understand the Security header "in
general", you can pass the first level of mustUnderstand
- Peter Rostin: what does understand "in general" mean?
- Phill: still can't resolve the fact that you can't truly trust the
security header (and it's mustUnderstand bit) until you process the
security header and verify its signature
- [more discussion]
- resolution: mustUnderstand on Security header simply means you are
aware of the WS-Sec spec, and there are no implied semantics
- [ACTION] Editors to reflect mustUnderstand resolution in docs
- change to PENDING
>
> 71 OPEN Inconsistent token pre-pending rules
>
- Hal: related to 84, can't solve one without the other
- mark CLOSED, with pointer to issue 84
>
> 72 OPEN Awkward status of message timestamps in WSS core
>
- Hal: posted comments, but don't recall any responses
- had comments on both expiration and timestamp trace
- boils down to either we should eliminate them or layout a specific
set of rules for them
- profiles can define new sets of rules
- rules aren't currently present, and they couldn't conclude what they
should be
- Tony: other areas, like signature processing, are left without rules
- Hal: but in those areas, the rules are dictated by other people/
specs
- Prateek: there is a body of knowledge in the signature case that we
are pointing to / relying on
- Martijn: the point is that we are leaving technical stuff and getting
into semantics
- maybe this needs to go into a profile
- Hal: a lot of the scenarios that were suggested weren't security-
related
- if other specs, like reliable messaging, want to specify semantics,
that's fine
- we should define semantics that are security-specific, which should
be few
- Hal: with timestamp trace, if we have synch'ed clocks, sees no
security usefulness
- [discussion of possible scenarios]
- Chris: so the suggestion is to drop expiration and timestamp trace?
- Hal: that is one resolution
- Prateek: can see intermediaries indicating that they touched a msg
at particular instances
- Hal: if receiver can't determine that it has/hasn't seen a nonce
before, other timestamps in message won't help
- Peter Dapkus: most of the content for timestamp trace had to do
with time synch, which didn't seem reasonable, but if there are
other usecases, that could be fine
- Peter Rostin: better approach for time synch could be a party
vouching for time synch of previous hops (agreeing with notion of
dropping timestamp trace, and possibly expiration)
- timestamp trace doesn't completely solve the time synch problem
anyway
- thinks we should drop both, but if only one, timestamp trace should
be dropped
- Chris: need to separate these into different issues
- may have the same resolution
- Timestamp trace discussion
- we've discussed this considerably already
- resolution is to remove this from core and possibly put into
another doc
- Expires discussion
- we haven't discussed this much yet
- Chris: looking for opinions on this
- thinks intention was for sender to express desired expiration
of message
- thinks that is security-related
- Tony: considers this much like proposal to include token labeling
- we're leaving the semantics open
- Peter Dapkus: that seems circular
- Chris: do we agree that sender expressing expiration is a good
thing?
- [think so]
- Chris: there is an expiration element, that says semantics will
be specified elsewhere, but there is a timestamp header, and if
expiration is included, the semantics are clearly spelled out
- Frederick: not sure how to reconcile this with semantics in
Reliable Messaging
- Chris: we have this notion of expiration that can be reused, and
we defined the Expires element
- then we defined a specific use, with the Timestamp header, where
the presence of expires has specific semantics
- [this didn't appear to be clear to everyone previously]
- Tim: for parallel, X509 has separate expiration of public keys
and private keys
- [looking at spec, draft-13, Section 10.3 Timestamp Header]
- Peter Dapkus: still seems like sender isn't guaranteed after
sending the message
- Chris: how guaranteed are we of anything after sending?
- Jeff: depends on the protocol, TCP guarantees you a reliable
stream
- Hal: we should have enough mechanisms to prevent things like
replay attacks
- this doesn't seem to be in same category as relay attack
prevention
- Peter Rostin: this doesn't address replay problem
- Chris: actually, it does, because it limits the window of
usefulness, after which, replay wouldn't benefit anything
- in this scenario, there is an acceptable replay window
- John: in a farm scenario, it's hard to manage sequence numbers
so an acceptable relay window approach has been taken
- Hal: traditional approach to security engineering is to identify
threats and to devise complete ways to defeat those threats
- this seems incomplete, and likely to bite us later
- Tony: this is just like expiration of certificates
- Peter Rostin: difference in the significance of clock skew
- for a 10 year cert, skew of an hour is insignificant
- with WS-Sec messages, 1 hour of clock skew seems very significant
- Phill: thinks discussion this belongs in WS-SecureConversation
- Chris: disagrees, thinks we need a primitive at the base level
- John: +1, there are situations where entities don't want to or
can't establish a session, and can't manage sequence numbers,
and want to use an expiration directive
- Tony: suggests we change lines 1263-1264 of core-13:
change "it is STRONGLY RECOMMENDED that recipients ..." to
"Recipients MUST ..."
- Peter Rostin: relative to receiver's clock?
- Tony: that issue applies to many areas, so why choke on it here?
- John: are we disagreeing over MUST?
- STRONGLY RECOMMENDED was used to allow for clock skew issues,
where reliable determination can't be made
- Peter Rostin: can we clarify that expiration of the message is
expiration of the security aspects of the message rather than
some application-specific notion of expiration
- [general agreement]
- Jeff: doesn't understand requirement being met by expiring the
security context of the message
- Hal: thinks the model here is that applications don't want to
see any messages that haven't "passed" the security layer
- Chris: senders are providing authorization with their message,
and it seems reasonable for them to express when that authZ
expires
- Jeff: one scenario is timestamps on security token, but currently
not all token formats have timestamp header defined
- could use token wrapper with the timestamp header, and could
specify that all tokens operate within their expiration period
- Chris: could be an alternative for that scenario, but there are
other scenarios
- Jeff: this seems to bleed over into reliable messaging
- Tony: lots of areas have similar notions
- Jeff: agrees, but thinks this is a layering matter
- Tony: describes scenario with one message where you want to set
an expiration time, which has nothing to do with app-level
- [discussion of clock synch issues]
- Jeff: looking at WS-ReliableMessaging, and another proposal on
their table, and they all have their own similar mechanisms, so
in the case of a single message, what happens when both that
layer mechanism is used and the WS-Sec mechanism is used?
- Chris: there's an issue of bootstrapping to the RM approaches
- there's also some competition between agendas, with RM trying
to repeat messages, and Security trying to defeat repeats
- Peter Dapkus: if we got clearer about how we are to evaluate
times, he could get more comfortable
- Chris: doesn't understand how this is any different than
receiving a cert with a 10 minute lifetime
- Peter Dapkus: doesn't think 10 minute certs are practical
- Peter Rostin: even if the problem is the same in principle, it
is different in practice due to the scale of time periods
- Chris: thinks those differences aren't there with Kerberos
- Phill: now convinced that we need the expires field
- larger argument is whether this should have been taken up by
SOAP, but since they haven't, Security is the next best place
for it
- Prateek: so is expiration linked to a credential or does it
apply to whole message?
- Hal: we were discussing dropping the free standing expiration
and keeping the timestamp header
- Frederick: have we required the use of synch'ed clocks in order
to use WS-Sec?
- returning to Tony's proposal
- Peter Rostin: amends with clarification excluding application-
level expiration concepts
- Gene: so what should happen
- Chris: we should make wording clearly apply to discarding the
security context of the message, not necessarily the whole
message itself
- Jeff: there's a meta-level issue in lines 1242-1244, with other
parties stuffing other timestamp actions in there
- [ACTION] Editors to 1) change lines 1263-1264 of core-13 from "it
is STRONGLY RECOMMENDED that recipients ..." to "Recipients MUST
..."; 2) change introductory paragraph around lines 1234-...,
clarifying the expiration for security purposes rather than
application purposes, and clarifying the consideration of clock
skew
- Martijn: how is Timestamp header related to Security header?
- Charles: should it be a child of Security header?
- Chris: according to spec, there is only one Security header and
one Timestamp header per role
- Hal: Section 10.3 reads like intermediaries can add Timestamps
- Chris: intention of that sentence line (1239) was for "if" to be
"only if"
- There should only be one timestamp per actor
- Martijn: so why not make Timestamp a child of Security?
- Eric: original description of Timestamp was that it applied to
the data in the message, but with the change to making it apply
just to the security aspects, this move seems appropriate
- [ACTION] Editors to make Timestamp header a child of Security
header, and to remove the ability of Expires to stand alone
(section 10.2.2 moves to child of section 10.3)
- Jeff: lines 1243-1244 need to be fixed, seems indeterminate
- sentence is broken, and intent is unclear
- [ACTION] Editors to clarify lines 1243-1244 of core-13
- Jeff: meta issue around 1188
- does this belong here, or does utility schema belong in separate
doc
- deferring this discussion until later
- Peter Dapkus: should sender choose expiration value based on
guess of receiver's clock, or should receiver evaluate expiration
value based on guess of skew from sender's clock?
- third case is to NOT factor any guess of skew
- will defer this until tomorrow, after folks have chance to sleep
on it
- Kelvin: suggests closing this point, and allowing anyone with
strong feelings/questions to open new issue
- mark PENDING
[NEW MINUTE-TAKER TAKING OVER HERE]
-----------------------------------------------------------------------
Attendance of Voting Members:
[TO BE ADDED SHORTLY]
Attendance of Observers or Prospective Members:
[TO BE ADDED SHORTLY]
Membership Status Changes:
[TO BE ADDED SHORTLY]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]