Re: [secdir] secdir review of draft-ietf-opsec-igp-crypto-requirements

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Sun, 19 September 2010 17:42 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0003A67F1; Sun, 19 Sep 2010 10:42:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.244
X-Spam-Level:
X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OddEoOlN-J5l; Sun, 19 Sep 2010 10:42:19 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 031383A672F; Sun, 19 Sep 2010 10:41:43 -0700 (PDT)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o8JHg4u0000967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 19 Sep 2010 12:42:06 -0500 (CDT)
Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o8JHg1lF010717 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 19 Sep 2010 23:12:03 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sun, 19 Sep 2010 23:12:01 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Samuel Weiler <weiler@watson.org>
Date: Sun, 19 Sep 2010 23:12:01 +0530
Thread-Topic: secdir review of draft-ietf-opsec-igp-crypto-requirements
Thread-Index: ActYBxHLvIX1HJ+IQY6vf1PisXqvFgAGqdxg
Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3BD6026@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <alpine.BSF.2.00.1009151357390.4814@fledge.watson.org> <7C362EEF9C7896468B36C9B79200D8350CF3916707@INBANSXCHMBSA1.in.alcatel-lucent.com> <alpine.BSF.2.00.1009191023430.57378@fledge.watson.org>
In-Reply-To: <alpine.BSF.2.00.1009191023430.57378@fledge.watson.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31
X-Mailman-Approved-At: Tue, 21 Sep 2010 06:35:20 -0700
Cc: "draft-ietf-opsec-igp-crypto-requirements.all@tools.ietf.org" <draft-ietf-opsec-igp-crypto-requirements.all@tools.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-opsec-igp-crypto-requirements
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Sep 2010 17:42:21 -0000

> >
> > I am not sure I understand whats being meant by in-band negotiation 
> > here?
> 
> Many protocols negotiate which crypto algorithm (or even more generic 
> security mechanism) to use.  Those negotiations, if done poorly, can 
> be subject to downgrade attacks.
> 
> Given how common security negotiation is, it's worthwhile to 
> point out 
> whether or not each of these protocols do it or whether they depend 
> entirely on static configuration of each endpoint.

All the protocols covered in this document provide the Key ID that's carried in the protocol packets that's used by the receiving end to authenticate the packet. So there is no exchange of crypto algorithms, etc that's done. We can mention this in the next revision.

Cheers, Manav

> 
> -- Sam
>