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 web services-based workflow, can opes use this work? Since an authorization model for setting policies is required we also need an authentication model. There's also the need for an authentication and authorization model vis-a-vis the policy owner and a called service. RFC 3238 has some impact on the document, but a full review hasn't been completed yet. Regardless, one key issue is the need for policy to control notifications suggested in the IAB guidelines. --- 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.