Hi Joel,
Thanks for forwarding the below - it helps me in understanding the
process. I am not sure whether I am supposed to respond or not on the
comments you provided, but it cannot hurt - so I will do my best. If I
need to provide those comments to a larger forum, or in a different
forum - please advise.
On the 1st comments, regarding IETF consensus, this may be something
that others (e.g. Dan Romascanu maybe) can help with - I am not sure I
am familiar enough with the IETF processes to suggest any changes.
As per the 2nd comment - indeed there are no additional security
concerns with respect to the use of the Diameter protocol for the PEEM
specification. What may help understanding why this is the case, is the
overall approach in OMA specifications. OMA develops granular
specifications, not end-to-end service specifications or solution
specifications. However, there are separate security specifications that
any vendor can bundle with any other enabler specifications, in order to
ensure any security concerns are addressed when a product is built. One
such mechanism is the use of security policies applied in a proxy
pattern (i.e. BEFORE any request reaches its target). Such security
poclieis (e.g. for authentication or authorization) may be applied on
the call carrying the PEM-1 request. A second mechanism is to use
specifications produced by another OMA group (OMA SECurity Working
Group) which produced a set of sepcifications called SECurity Common
Functions, that are used at different protocol layers to ensure
authentication, confidentiality, integrity of the exchange. OMA does
this on purpose to avoid the development of silo-specifications (i.e.
specifications where each functionality also addresses in a
silo-approach all security aspects).
The reason why we have honored the Diameter base protocol security
requirements is simply because we want to take advantage of
client-server implementations that vendors have produced so far, to
simlify adoption of the PEEM application. Any other security needs would
therefore be addressed in addition to, and outside the scope of the
Diameter application. They have therefore nothing to do with the
submitted IETF draft, and are not to be part of it.
I'll be glad to provide any additional clarifications, or point to
additional security specifications - although none of the latter will
give any indication of how one would integrate additional security with
PEEM specifications - that is on purpose left to vendors and service
providers, to allow for differentiation (again - OMA is NOT in the
business to provide specifications of end-to-end services or solutions).
Best regards,
Michael
-----Original Message-----
From: Joel M. Halpern [mailto:jmh(_at_)joelhalpern(_dot_)com]
Sent: Sunday, January 06, 2008 4:33 PM
To: gen-art(_at_)ietf(_dot_)org
Cc: Mary Barnes; ietf(_at_)ietf(_dot_)org; Brenner, Michael Ralf (Michael);
dromasca(_at_)avaya(_dot_)com
Subject: Re: LC reviews: draft-brenner-dime-peem
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: Diameter Polic Processing Application
Reviewer: Joel M. Halpern
Review Date: 6-January-2008
IETF LC End Date: 17-January-2008
IESG Telechat date: N/A
Summary: This document is nearly ready for publication as an information
RFC.
The first of the two comments below is probably primarily the
IESG's concern, although it affects the IETF last call.
The second comment is a more general issue.
Comments:
This document requests assignment of a Diameter Command Code.
As this requires "IETF Consensus" additional care may be needed
to ensure that the Last Call produces clarity on the required consensus.
It would seem appropriate for the last call announcement to have
indicated this requirement. It is difficult to claim "IETF Consensus"
from the typical non-response to IETF last call for informational
documents.
It seems exceedingly unlikely that the protocol exchanges to
support a separate policy processing application introduce no new
security issues compared with the Diameter base protocol in the assumed
Diameter deployment. Obviously, as I am not performing a full review of
the
PEM-1 protocol, I can not assert that there are or are not security
implications, but it would seem that there are likely to be such. I
would be less concerned, but examination of the PEM-1 specification did
not show the existence of a security discussion which could be taken to
serve in lieu of such a section.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf