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

From: [email-masked]
Date: Mon, 22 Oct 2012 15:50:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Keying and Authentication for Routing Protocols Working Group of the IETF.

	Title           : Database of Long-Lived Symmetric Cryptographic Keys
	Author(s)       : Russell Housley
                          Tim Polk
                          Sam Hartman
                          Dacheng Zhang
	Filename        : draft-ietf-karp-crypto-key-table-04.txt
	Pages           : 12
	Date            : 2012-10-22

Abstract:
   This document specifies the information contained in a conceptual
   database of long-lived cryptographic keys used by many different
   security protocols.  The database is designed to support both manual
   and automated key management.  In addition to describing the schema
   for the database, this document describes the operations that can be
   performed on the database as well as the requirements for the
   security protocols that wish to use the database.  In many typical
   scenarios, the security protocols do not directly use the long-lived
   key, but rather a key derivation function is used to derive a short-
   lived key from a long-lived key.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-karp-crypto-key-table-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-karp-crypto-key-table-04

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 23 Oct 2012 00:08:25 +0000

Dear Authors,

I looked at the latest version of this draft. Most of my comments have been addressed except the
4 fields to represent the key life time (and separate tables for group and pair wise keys).

SendNotBefore, SendNotAfter, RcvNotBefore, RcvNotAfter

We discussed on this and there was a discussion on simplified operations and use 2 key life times too (but no conclusion)
http://www.ietf.org/mail-archive/web/karp/current/msg00934.html

For pair wise keys as rekey is a local decision at both ends (any of the peer can initiate) and KMP doesn't negotiate lifetimes, IMO, we should
have operationally simplified version of the key life time.

Q:
If these are applicable to all protocols, how these 4 life times should translate input user parameters? 
I am not sure this simplifies operations any way and should be defined separately for Group keys and pair-wise keys.

Rest of the document looks good.

-- 
Uma C. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 22, 2012 3:51 PM
To: [email-masked]
Cc: [email-masked]
Subject: [karp] I-D Action: draft-ietf-karp-crypto-key-table-04.txt

Abstract:

_______________________________________________
karp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/karp

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Oct 2012 20:14:25 -0400

Uma:

I'd like to discuss one of your comments.  

> I am not sure this simplifies operations any way and should be defined separately for Group keys and pair-wise keys.

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?

Russ

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 23 Oct 2012 00:46:45 +0000

Hello Russ, 

 >>>>> 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?

-- 
Uma C.

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Oct 2012 18:32:43 -0400

>        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.

Russ

---

From: Brian Weis <[email-masked]>
Date: Thu, 25 Oct 2012 16:24:53 -0700

Hi Russ,

> 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

-- 
Brian Weis
Security Standards and Technology, SRG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 25 Oct 2012 20:23:12 -0400

Should we be clearer somewhere that inapplicable fields may be omitted? 
(it is a conceptual table, I think we can allow conceptually optional 
elements.)
Yours,
Joel

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Oct 2012 15:29:51 -0400

> 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…

One only needs to support the fields needed to accommodate the protocols that draw from the table.  That said, adding additional protocols to a system may lead to support for other fields if they are not included from the beginning.

Russ

---

From: Brian Weis <[email-masked]>
Date: Fri, 26 Oct 2012 14:11:08 -0700

Hi Russ,

> One only needs to support the fields needed to accommodate the protocols that draw from the table.  That said, adding additional protocols to a system may lead to support for other fields if they a…

This sounds reasonable to me. But to Joel's point, I think it would be a good idea to discuss this briefly in the I-D. I believe it would address Uma's concern.

Thanks,
Brian

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Oct 2012 23:52:40 -0400

Can we handle this as a WG Last Call comment?

On Oct 25, 2012, at 8:23 PM, Joel M. Halpern wrote:

> Should we be clearer somewhere that inapplicable fields may be omitted? (it is a conceptual table, I think we can allow conceptually optional elements.)
> Yours,
> Joel
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Sat, 27 Oct 2012 00:12:59 -0400

I can live with that.
Let me make sure I can persuade Uma (whose comment started this) to go 
along.  I expect I can do so Monday.  If so, we can start the WG last 
call then as far as I am concerned.

Yours,
Joel