RE: Feedback on draft-ietf-rap-cops-tls-06.txt

Bert,

I AM working on modifying the draft to Uri's satisfaction.

Amol

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Wijnen, Bert (Bert)
Sent: Thursday, November 06, 2003 12:56 PM
To: Hahn, Scott; Mark Stevens (E-mail)
Cc: Rap-wg (E-mail); Uri Blumenthal (E-mail)
Subject: RE: Feedback on draft-ietf-rap-cops-tls-06.txt

I guess that it just alternates between the security advisor=20
and the WG (and/or eduitors/authors)... but now we've been waiting
for close to two weeks without any response from WG.

<ad hat on>
This is not gonna work=20
I hope you understand the implied message here!
</ad hat on>

Thanks,
Bert=20

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]]
> Sent: maandag 27 oktober 2003 12:06
> To: Rap-wg (E-mail)
> Cc: Uri Blumenthal (E-mail)
> Subject: Feedback on draft-ietf-rap-cops-tls-06.txt
>=20
>=20
> Sorry for the long delay, but finally our Security Advisor has=20
> found time to review revision 6.
>=20
> I hope that the authors/editors and the WG can quickly=20
> respond and act, so that we can now get some pressure to
> complete this last RAP-WG document soon.
>=20
> Thanks,
> Bert=20
>=20
> -----Original Message-----
> From: Uri Blumenthal [mailto:[email protected]]
> Sent: donderdag 23 oktober 2003 23:58
> To: Wijnen, Bert
> Cc: Blumenthal, Uri
> Subject: COPS etc.3.2.1. So is at least one protocol=20
> mandatory? And why
> is it valid to make them all optional?
>=20
>=20
> Bert,
>=20
> Sorry for prolonged silence - was sick and then took me
> time to get through the e-mail piles.
>=20
> Here's my review of COPS-06, please forward it to the
> appropriate AD and WG chair(s).
>=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

> cops-06.txt
>=20
> GENERIC COMMENTS.
>=20
> I'd prefer the following important issues described
> somewhere:
> 	- key provisioning (how the initial/first keys
> 	  get in);
> 	- key management/update;
> 	- key requirments. What kind of keys are accepted?
> 	  Public Key in X.509 format only? Anything else?
> 	  Any reason why neither symmetric keys nor
> 	  password-based methods (such as SRP, or what's in
> 	  SSL) are there?
> 	- policy - how it gets there, how it's processed,
> 	  what it looks like, etc. Something comparable to
> 	  VACM of SNMPv3...
>=20
> I found the text on Access Control exceedingly muddy/unclear. I'm
> coming from reasonably good understanding of Access Control, but
> shallow knowledge of COPS. Request rephrasing (and maiing it
> CLEARER).
>=20
> Excessive use of abbreviations (PEP, PDP) without defining them
> in this document doesn't help.
>=20
> Otherwise the document is OK, notwithstanding the following.
>=20
> SPECIFIC COMMENTS.
>=20
> 3.2.1.  So is at least one protocol mandatory? And why is it valid
> to make them all optional?
>=20
> 4.4.  I'm not sure server (in the last case) should be allowed to
> just proceed establishing insecure connection. Perhaps better if
> the client decides how to proceed?
>=20
> PDP implementations MUST NOT require use of access control?!  I'm
> violently against this prohibition.
>=20
> 8. Forcing to choose between insecure and X.509 PKI infrastructure
> is unfair and improper. Recommendation: support Web of trust,
> possibly other...
>=20
> PDP hostname availavle via Access Control mechanism? I don't
> understand - please clarify.
>=20
> 9.1. And the point of backward compatibility with old insecure
> implementations is...?
>=20
> References. RFC2748 is not of January 200 (unless it's a part
> of Gospel?).
>=20