Subject: Unique Shared Secrets (4.4.2) in opes-authorization

From: "Eric Burger" <[email-masked]>
Date: Mon, 21 Oct 2002 22:35:11 -0400

Why must the shared secrets be unique for each requestor / responder pair?
Why do we care?  In fact, such a requirement opens a security hole: I can
guess someone else's key by trying to enter keys until the "system" tells me
I can't because someone else has that key.

I would drop the bullet.

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 21 Oct 2002 22:35:09 -0400

Section 4.2 states, "The service provider MUST keep a log of all requests
for OPES services".

Last I looked, the IETF is a protocol standards body, not a legislative
body.  Unless the *protocol* REQUIRES the service provider to keep the log,
this is an unenforceable requirement.  I agree that we need to state our
sentiment.  A better place may be in the security section.

Likewise, "The trusted users must be authenticated before being allowed to
take actions" is a similar policy, not protocol statement.  The good news is
"must" is not capitalized.  However, this statement again does not belong in
this section, and should be a SHOULD.

The next paragraph is a place where we can have protocol machinery: "The
PEP's should be authenticated before they receive policy rules".  If we
care, then I would propose, "Because of the sensitivity of user profiles,
the PEP Interface between the PEP and the PDP MUST use a secure transport
protocol."

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 21 Oct 2002 22:35:13 -0400

How can a user know that the PDP has user profiles so they can limit the
promulgation of their profile data?

As pointed out in the thread on Authentication Requirements, how does the
PROTOCOL limit traffic data from being sent to third parties?  How does the
PROTOCOL know the difference between a server run by the service provider
and a server run by a third party?

In the real world, the user and the service provider enter into a trust
agreement (outside of the protocol).  Part of that agreement is that the
service provider can or cannot let third parties do work on their behalf.
This, again, is outside of the protocol.  POLICY dictates whether a service
provider may or may not send traffic data to third parties.

---

From: "Oskar Batuner" <[email-masked]>
Date: Wed, 23 Oct 2002 11:14:43 -0400

Eric, technically you right - if we are looking only at transport
protocols many things in this draft are not relevant. But
essentially OPES (as well as WEBI and CDN) works on "overlay
network" - the architecture describes system structure built
above application level protocol. This structure sets requirements
for protocols and policies. In this sense one might look at
policies as a very high level protocols that control
communication of certain application level information.

IETF often ventures beyond protocol level considerations. A good
example is RFC 3238 - IAB Considerations for OPES. Out of all
considerations listed in the summary only one - 2.2, IP-layer
addressing - is talking about protocol level requirements, and
even this one is based on policy considerations that are
not dictated by the data transfer needs.

Again, I agree that many OPES drafts do have some inconsistencies
that are due to the fact that each of these drafts deals with
variety of protocol levels. Comments like this one may help
to improve them - but we should always keep in mind that this
group is working not on protocol, but on multilevel
infrastructure.

Oskar

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Eric Burger
> Sent: Monday, October 21, 2002 10:35 PM
> To: OPES Group
> Subject: Authentication Requirements in opes-authorization-00 (section
> 4.2)
>
>
>

---

From: Markus Hofmann <[email-masked]>
Date: Sat, 26 Oct 2002 13:52:00 -0400

Eric Burger wrote:

> The next paragraph is a place where we can have protocol machinery:
> "The PEP's should be authenticated before they receive policy
> rules".  If we care, then I would propose, "Because of the
> sensitivity of user profiles, the PEP Interface between the PEP and
> the PDP MUST use a secure transport protocol."

How about phrasing it more like "Because of the sensitivity of user 
profiles, the PEP Interface between the PEP and the PDP MUST use a 
secured communication channel" rather than requiring a "...secure 
transport protocol...". Communication between PEP and PDP can be 
secured in different ways, and does not always require a secure 
*transport protocol*. (Assume, for example, that PDP and PEP are in 
the same administrative domain, which is protected via firewalls or so...)

-Markus