Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.txt

Brian Weis <bew@cisco.com> Thu, 25 October 2012 23:24 UTC

Return-Path: <bew@cisco.com>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983D421F8522 for <karp@ietfa.amsl.com>; Thu, 25 Oct 2012 16:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzAp7DU2Jv56 for <karp@ietfa.amsl.com>; Thu, 25 Oct 2012 16:24:54 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0094821F84F2 for <karp@ietf.org>; Thu, 25 Oct 2012 16:24:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2267; q=dns/txt; s=iport; t=1351207493; x=1352417093; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oaGNQ44aYEvU2YJWIULT/sJ86GT7TN5DbY8VGOwdfQA=; b=Lx2BbRqtAghVrBXCsjJcmUQrhSgCa74azaKCNARRZWy9Y3I7FquSTsp5 U6fU8S0156jCV7cICfpH5gSpCl9/UDDrQ5UUFAXpadjtSL4izi2slKzDV XHVE6O6TfuvsBn1b6xJi/4lI6v2tkYOTPa1TA4eHvH2OKnH09Q2pzoF5T g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EANjIiVCrRDoI/2dsb2JhbABBA8I5gQiCHgEBAQMBAQEBDwEnNAsFCwtGJzAGExkJh1wFDJ1soBoEi2GDRIJIYQOIXI0ajlKBa4MPgUQX
X-IronPort-AV: E=Sophos;i="4.80,650,1344211200"; d="scan'208";a="59197343"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 25 Oct 2012 23:24:53 +0000
Received: from stealth-10-32-244-214.cisco.com (stealth-10-32-244-214.cisco.com [10.32.244.214]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9PNOrk9032338; Thu, 25 Oct 2012 23:24:53 GMT
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Brian Weis <bew@cisco.com>
In-Reply-To: <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com>
Date: Thu, 25 Oct 2012 16:24:53 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <380B8A70-0910-43B6-980A-8CCAD8731DDC@cisco.com>
References: <20121022225043.25241.45532.idtracker@ietfa.amsl.com> <1B502206DFA0C544B7A6046915200863011C81@EUSAAMB105.ericsson.se> <4C84D429-416F-4A63-9C83-DA16EF243026@vigilsec.com> <1B502206DFA0C544B7A6046915200863011CD1@EUSAAMB105.ericsson.se> <0A63E924-E20D-4C94-89C2-508724EC975A@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.1283)
Cc: "karp@ietf.org" <karp@ietf.org>
Subject: Re: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.txt
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2012 23:24:54 -0000

Hi Russ,

On Oct 23, 2012, at 3:32 PM, Russ Housley wrote:

> Uma:
> 
>>>>>>> I have worked through the use of pairwise keys (used in just one direction or both directions)
>>>>>>> as well as multicast keys.  The current table supports all of these cases. I do not understand
>>>>>>> why you want two separate tables.  Clearly, you are thinking about this differently than I am.  
>>>>>>> Can you explain how two tables will make implementation easier?
>> 
>> [Uma]:  Let's focus on only from the key life time perspective. Some IGPs do require life times in the 
>>       specified format to make key transition easier.  But, I don't see how to fit these 4 parameters
>>       for pair wise keys. For e.g. for TCP based pair-wise keys, when new master key is negotiated by 
>>       KMP, TCP-AO makes coordinated key transition with the peer. Not at all based on the key table 
>>       time entries specified. In that sense the entries defined today useful and enable protocols 
>>       e.g., group-key RPs, who don't have a defined way of key transition and more over do security 
>>       by themselves (make sense there).
>> 
>>       Now, I stepped back to think on how to use for pair-wise protocols and not able to connect the 
>>       dots here. Do you see these are operator inputs or KMP negotiated and how one would use these entries?
> 
> You will note that earlier drafts only had notBefore and notAfter.  The additional one were added because some IGPs need them.
> 
> I see no way to move forward and address both comments.

The draft appears to be silent as to whether fields in the key table are required, but my belief is that not all fields are required to be used for all keys. As such, if a KMP for TCP-AO adds a row to the key table, and some fields in that row are not required, then it simply does not need to specify their use. Is that not correct?

Thanks,
Brian

> Russ
> _______________________________________________
> karp mailing list
> karp@ietf.org
> https://www.ietf.org/mailman/listinfo/karp


-- 
Brian Weis
Security Standards and Technology, SRG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com