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

I guess that it just alternates between the security advisor 
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 
I hope you understand the implied message here!
</ad hat on>

Thanks,
Bert 

> -----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
> 
> 
> Sorry for the long delay, but finally our Security Advisor has 
> found time to review revision 6.
> 
> I hope that the authors/editors and the WG can quickly 
> respond and act, so that we can now get some pressure to
> complete this last RAP-WG document soon.
> 
> Thanks,
> Bert 
> 
> -----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 
> mandatory? And why
> is it valid to make them all optional?
> 
> 
> Bert,
> 
> Sorry for prolonged silence - was sick and then took me
> time to get through the e-mail piles.
> 
> Here's my review of COPS-06, please forward it to the
> appropriate AD and WG chair(s).
> 
> ==================================================
> cops-06.txt
> 
> GENERIC COMMENTS.
> 
> 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...
> 
> 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).
> 
> Excessive use of abbreviations (PEP, PDP) without defining them
> in this document doesn't help.
> 
> Otherwise the document is OK, notwithstanding the following.
> 
> SPECIFIC COMMENTS.
> 
> 3.2.1.  So is at least one protocol mandatory? And why is it valid
> to make them all optional?
> 
> 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?
> 
> PDP implementations MUST NOT require use of access control?!  I'm
> violently against this prohibition.
> 
> 8. Forcing to choose between insecure and X.509 PKI infrastructure
> is unfair and improper. Recommendation: support Web of trust,
> possibly other...
> 
> PDP hostname availavle via Access Control mechanism? I don't
> understand - please clarify.
> 
> 9.1. And the point of backward compatibility with old insecure
> implementations is...?
> 
> References. RFC2748 is not of January 200 (unless it's a part
> of Gospel?).
>