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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 6 Nov 2003 21:56:30 +0100

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-masked]]
> 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-masked]]
> 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?).
>

---

From: "Kulkarni, Amol" <[email-masked]>
Date: Thu, 6 Nov 2003 13:49:51 -0800

Bert,

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

Amol

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

<ad hat on>
This is not gonna work 

Thanks,
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 6 Nov 2003 23:00:40 +0100

OK, that is good to hear.
But was I supposed to just assume that based on the silence?

Thanks,
Bert 

> From: Kulkarni, Amol [mailto:[email-masked]]
> Sent: donderdag 6 november 2003 22:50
> To: Wijnen, Bert (Bert); Hahn, Scott; Mark Stevens (E-mail)

---

From: "Kulkarni, Amol" <[email-masked]>
Date: Thu, 13 Nov 2003 13:40:30 -0800

Hi Uri,

Thanks for reviewing the draft. I've made most of the changes you've
asked for. However, I have some comments below...

Thanks,
Amol

-----Original Message-----
From: Uri Blumenthal [mailto:[email-masked]]
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

Bert,

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?
-------------
Amol> I assume the above points refer to the authentication keys used by
the client and the 'insecure' COPS server. There is some description of
the keys and how to use them in the original COPS RFC. However, the key
provisioning and management has been left out as an implementation
issue. 
I'm not sure if I should use this draft to modify or clarify something
that's essentially a COPS/TCP RFC issue.

	- policy - how it gets there, how it's processed,
	  what it looks like, etc. Something comparable to
	  VACM of SNMPv3...
----------
Amol> Again, I believe that policy specification is not within the scope
of this draft. Maybe I should explicitly mention that?

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).
------------
Amol> Are you referring to Section 5 or section 8? I've updated text in
both sections, but I'd still like to know.

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?
----------
Amol> I don't think so. The client, by indicating that a secure
connection is optional, should be OK with the insecure connection being
established.