From owner-rap@ops.ietf.org Thu May 22 20:57:09 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06788 for ; Thu, 22 May 2003 20:57:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19J0px-00081P-00 for rap-data@psg.com; Fri, 23 May 2003 00:55:09 +0000 Received: from fmr02.intel.com ([192.55.52.25] helo=caduceus.fm.intel.com) by psg.com with esmtp (Exim 3.36 #1) id 19J0pR-0007zr-00 for rap@ops.ietf.org; Fri, 23 May 2003 00:54:37 +0000 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h4N0kx101817 for ; Fri, 23 May 2003 00:46:59 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h4N0tOO19733 for ; Fri, 23 May 2003 00:55:24 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003052217543622311 ; Thu, 22 May 2003 17:54:36 -0700 Received: from orsmsx405.amr.corp.intel.com ([192.168.65.46]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 22 May 2003 17:54:36 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Fwd: RE: COPS-over-TLS v05 draft review] Date: Thu, 22 May 2003 17:54:35 -0700 Message-ID: Thread-Topic: [Fwd: RE: COPS-over-TLS v05 draft review] Thread-Index: AcLfjdTr000CDpRrS3O8AOdgBq+uCA/pC7uA From: "Kulkarni, Amol" To: , X-OriginalArrivalTime: 23 May 2003 00:54:36.0267 (UTC) FILETIME=[E1A26BB0:01C320C5] X-Spam-Status: No, hits=-6.6 required=5.0 tests=BAYES_01 version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA06788 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" ...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 From owner-rap@ops.ietf.org Wed May 28 07:48:00 2003 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25827 for ; Wed, 28 May 2003 07:47:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.36 #1) id 19KzNu-000D6y-00 for rap-data@psg.com; Wed, 28 May 2003 11:46:22 +0000 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by psg.com with esmtp (Exim 3.36 #1) id 19KzNr-000D6m-00 for rap@ops.ietf.org; Wed, 28 May 2003 11:46:19 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25684; Wed, 28 May 2003 07:46:17 -0400 (EDT) Message-Id: <200305281146.HAA25684@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rap@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-rap-cops-tls-06.txt Date: Wed, 28 May 2003 07:46:17 -0400 X-Spam-Status: No, hits=1.5 required=5.0 tests=BAYES_30,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-rap@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Resource Allocation Protocol Working Group of the IETF. Title : COPS Over TLS Author(s) : J. Walker, A. Kulkarni Filename : draft-ietf-rap-cops-tls-06.txt Pages : 11 Date : 2003-5-27 This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@ops.ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rap-cops-tls-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rap-cops-tls-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-27145422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rap-cops-tls-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rap-cops-tls-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-27145422.I-D@ietf.org> --OtherAccess-- --NextPart--