RE: [Fwd: RE: COPS-over-TLS v05 draft review]

["Kulkarni, Amol" <amol.kulkarni@intel.com>]

Hi Uri,

Thanks for reviewing the draft and providing feedback.

I'm updating the draft based on your comments (finally :) ). Before I
send out the draft, I'd like to address the comments here. Please see
below for my responses.

Thanks,
Amol

-----Original Message-----
From: Uri Blumenthal [mailto:uri@bell-labs.com] 
Sent: Friday, February 28, 2003 1:01 PM
To: rap@ops.ietf.org
Subject: [Fwd: RE: COPS-over-TLS v05 draft review]

Folks,

This is from your friendly Security Advisor. (:-)

And since I'm not the member of this mailing list,
please kindly copy me on the relevant e-mails that
might occur in response to this posting. (:-)

Regards,
Uri.

-------- Original Message --------
From: "Hahn, Scott" <scott.hahn@intel.com>

...I think this should be posted to the list for discussion.
	-Scott

 > From: Uri Blumenthal [mailto:uri@bell-labs.com]
 >
 > Here are the issues I see with the draft
 > "draft-ietf-rap-cops-tls-05.txt".
 >
 > First, overall I want to see how it ensures that when both client and
 > server can do security, it will be enabled. For example, a
 > man-in-the-middle can modify the traffic to convince one party that
 > the other one doesn't support security ("bid-down") and thus force
 > them to establish an insecure connection even though they both are
 > capable of secure communications. I would like to see a capability
 > to enforce secure mode.
---------------
Amol> Uri, COPS messages need to attach an 'integrity' object at the end
in order to verify the integrity of the message. The integrity object
has a unique sequence number which is incremented for each new message.
It also contains an identifier identifying a shared key. Finally, the
integrity object has a digest of the entire message computed with the
identified key. This mechanism should help in avoiding tampering of
messages on the wire.

 >
 > Also, I would like to see scenarios based not [only] on whether
 > client/server SUPPORTS security - but also on whether its POLICY
 > REQUIRES secure connection to a given peer. If it was meant so,
 > it isn't clear from the document.
--------------------
Amol> I'll clarify this in the document.

 >
 >
 > Details by sections:
 >
 > 4.2. So what should the client do after receiving the error?
------------------
Amol> If the Client's policies dictate that security is mandatory, and
the server's policies prohibit the client from connecting securely, the
connection cannot be established.

 >
 > 4.3. So the server MAY send a ClientClose... Anything else
 >       it "may" do? Nothing it "should" do in this case...?
 >       What should an implementor do here?
------------------
Amol> This point should be expanded to say that if the server's policy
allows the client to connect, the server should redirect the client to
the COPS/TLS port. Else it should send an error and close the
connection.

 >
 > 4.4. Same as above.
 >
 > 4.7. Why is this subsection here? I'd say - remove it.
 >
 > 8. It is good to require PKI - what happens if CA isn't
 >     available, isn't accessible, whatever?
 >     Reverts to insecure?
-----------
Amol> Yes.
 >
 >
 >
 >
 > Thanks!
 >
 > Regards,
 > Uri