[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Fwd: RE: COPS-over-TLS v05 draft review]
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.
From: Uri Blumenthal [mailto:email@example.com]
Sent: Friday, February 28, 2003 1:01 PM
Subject: [Fwd: RE: COPS-over-TLS v05 draft review]
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. (:-)
-------- Original Message --------
From: "Hahn, Scott" <firstname.lastname@example.org>
...I think this should be posted to the list for discussion.
> From: Uri Blumenthal [mailto:email@example.com]
> Here are the issues I see with the draft
> 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
> 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?