these are draft minutes. please comment with respect to accuracy, etc.
in the absence of substantive comments, the official minutes will be
published next week.
thanks,
/mtr
#######
Minutes of the OPES Meeting at IETF53
=====================================
Wednesday, 3/20/02, 1300-1500
Chairs: Markus Hofmann, Marshall Rose
AD: Ned Freed
Advisors: Hilarie Orman, Allison Mankin
Minutes: Marshall Rose
- Agenda bashing - Markus Hofmann
A discussion on VPCN is not on the agenda due to lack of time. Abbie
Barbier will host an informal discussion after the meeting concludes.
No other comments, or changes to the agenda.
- Charter walk-through - Markus Hofmann
The final charter was presented for remedial purposes. The key
points:
- both server-centric and client-centric issues are in scope
- endpoints must be able to determine that an intermediary was
involved in a communication, so transparent services are not
in scope
- regardless, the endpoint's determination of an intermediary
needn't occur as a part of the original communication.
- endpoints must be able to bypass the opes service, if desired
("opes must be reversible")
- specification of an opes policy framework is not in scope;
however, reuse of an existing framework is acceptable
- limited to use for HTTP and RTP/RTSP
-- Discussion:
Ned Freed suggests that the "work item" text in the charter that
says:
Define policy specification method(s) and rules for
controlling execution of OPES services
may be revised to avoid confusion with earlier text in the charter,
a prohibition on developing a policy frameworks.
- Discussion of workplan, milestones, and how we want to get there - Hofmann
The wg's milestones are timely. In order to continue forward
movement, some editing teams will be formed to work on documents
in parallel, with their results being given back to the wg
- Architecture: Barbier, Chen, Condry, Penno, Tomlinson
- Scenarios: Chen, Condry, McHenry, Penno, Tomlinson
- E2E Integrity: Orman, Cooper?
- Protocol Requirements: Beck, Penno
- Threat Model: TBD
- Endpoint authorization/enforcement: TBD
Given the dependency hierarchy of the documents, the chairs will be
initially focusing their efforts on developing the first two
documents.
- Disussion on the end-to-end integrity and encryption compatibility
issue for proposal to the ADs - Hilarie Orman
Although the IAB is asking if OPES can be compatible with
e2e-encryption, a more general question is whether OPES can provide
confidentiality.
As a first principle, OPES will not transparently insert itself in
an e2e-connection. However, if an OPES service offers something of
value to the endpoints, then an endpoint may choose to trust an
OPES intermediary in order to access that service. Adding more
parties (e.g., when the intermediary invokes a callout server)
introduces more complexity.
This raises some questions:
- should OPES support concatented confidential links?
- how are confidentiality requirements communicated?
- in what configurations should confidentiality be perpetuated?
-- Discussion:
- multiparty key management is very hard
- an explicit trust model is superior to an implicit trust model
- encryption and integrity are seperate functions, although the same
technologies may be used to achieve both tasks
- perhaps a new model is needed to relate intermediaries and
endpoints to clarify these issues
- if opes is to provide confidentiality, it can do so only between
each application hop (e.g., between the origin client and an
intermediary), and not between the origin client and origin server
(as the intermediaries need plaintext access to the
data. independent of confidentiality, message integrity can be
used to allow the origin client and server to examine the original
data and any intermediary transformations.
- Discussion of next WG documents
For all documents, it is noted that volunteers are still welcome to
join the editing teams.
-- Scenario document, presented by Abbie Barber
Still fluid, large changes in the works:
- Remove business case text
- new discussion on the applicability of callout servers
- new taxonomy of services: on requests, responses, or taking a
request to generate a response.
-- Architecture document, presented by Abbie Barber
Major emphasis on addressing issues presented in RFC 3238. Progress
being made on several fronts; however, many open questions require a
protocol "fix", perhaps one of:
- some new HTTP extensions (headers, methods, etc.)
- some new markup tags
- a OPES signalling protocol
--- Discussion:
- must be sensitive to embedding literal addresses (ipv4/ipv6)
- must also be sensitive to the interaction with authoring tools.
in particular, authoring programs (WebDAV clients) use the GET
request (just like a browser) to retrieve a page for
editing. accordingly, an intermediary must not alter the content
being transfered for the purpose of authoring. at least one
authoring product includes a proprietary header in the GET request
to indicate that the client is in "authoring mode". Similarly,
Section 14.9.5 of RFC 2616 also provides a "No-Transform"
directive in the HTTP response for this purpose.
-- Callout protocol/tracing requirements, presented by Andre Beck
Current draft is based on pre-charter OPES and was heavily
influenced on existing callout protocols. As such, some early
assumptions may no longer be valid.
The authors suggest that the existing draft be an input to the wg,
but not as a starting point for the working group's deliverable.
--- Discussion:
- what does it mean to "bypass" an OPES service: just bypassing one
intermediary or all of them?
- what about performance? should there be requirements to optimize this?
-- Callout protocol/tracing requirements, part deux, presented by Abbie Barber
The authors suggest a new approach: consider requirements without
being influenced by existing callout protocols.
In particular, what about these requirements: flow control,
failover, capability negotiation, NATs/firewalls, and so on.
--- Discussion:
- what about interaction with the webi and cgi working groups?
- what about using soap or web services? -- really should be
requirements driven before picking a particular protocol
-- Endpoint authorization and enforcement document, presented by Lee Rafalow
Other groups are working on workflow, can opes use this work?
Should an authorization model be developed in addition to an
authentication model.
RFC 3238 has some impact on the document, but a full review hasn't
been completed yet.
--- Discussion:
- the "general" issue is that the origin server doesn't see what the
originally client actually asked, nor does the origin client see what
the origin server actually responded with.
-- Threat/risk model document, discussed by Markus Hofmann
To repeat, for all documents, it is noted that volunteers are still
welcome to join the editing teams.
Adjourn.
#######