Subject: [karp] Proposed text for design guide

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2011 01:10:49 -0500

KARP will focus on an abstraction for keying information that describes
the interface between routing protocols, operators and automated key
management. Conceptually when routing protocols send or recieve packets
they will look up the key to use in this abstract key
table. Conceptually, there will be an interface for a routing protocol
to make requests of automated key management when it is being used; when
keys become available they will be made available in the key
table. There is no requirement that this abstraction be used for
implementation; the abstraction serves the needs of standardization an
and management. Specifically as part of the KARP work plan:

1) KARP will design the key table abstraction and the interface between
key management protocols and routing protocols.

2) For each routing protocol, we will define the mapping between how the
protocol represents key material and the protocol independent key table
abstraction. When routing protocols share a common mechanism for
authentication, such as the TCP Authentication Option, the same mapping
is likely to be reused between protocols. An implementation may be able
to move much of the keying logic into code related to this shared
authentication primitive rather than code specific to routing protocols.

3) When designing automated key management for both symmetric keys and
group keys, we will only use the abstractions designed in point 1 above
to communicate between automated key management and routing protocols.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Nov 2011 01:19:44 -0500

Thank you Sam.

WG, this text attempts to capture an apparent agreement in the 
face-to-face meeting on how to resolve Russ Housley's discuss of the 
design guidelines document.

Do members of the WG find this acceptable?

Thank you,
Joel & Brian

On 11/16/2011 1:10 AM, Sam Hartman wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Nov 2011 01:53:16 -0500

Joel asked me to flag that as various people have talked about AKM
proposals, they have all needed to have some interface for the routing
protocol or TCP-AO or whatever to request keys from the AKM.  I've
talked about that abstraction as well in my text, not just the existing
key tables abstraction.

---

From: Russ White <[email-masked]>
Date: Wed, 16 Nov 2011 20:42:54 -0500

This looks good to me...

:-)

Russ

---

From: Joe Touch <[email-masked]>
Date: Wed, 16 Nov 2011 18:33:52 -0800

On 11/15/2011 10:10 PM, Sam Hartman wrote:
> table.

I don't think KARP should specify things in terms of packets - those 
abstractions exist at other layers of the stack (transport = segment, 
network = packet, link = frame).

IMO, this should refer to *messages*, and say:

  Conceptually when routing protocols send or receive messages they are 
associated with a key in this abstract key table.

I.e., "associated" could mean (and this might be useful to explain):

	- used by the routing protocol to protect a message
	- associated with a session at a lower protocol layer
	to protect transfers at that layer

> ...Conceptually, there will be an interface for a routing protocol

And (possibly) security protocols at other layers.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 16 Nov 2011 23:44:01 -0500

Hi Joel, 
While this may be the ultimate positioning of the key table draft, I think it is premature to elevate it to this status. 

I have the following comments on the -02 version:
 
  1. LocalKeyID - Don't overload whether it is a pairwise or group key in the high order bit of the ID. Since there are already over 15 key fields in conceptual database, I don't see advantage of overloading the ID space. Let's not forget that if this draft becomes an RFC, administrators may actually have to configure these IDs. 
  2. Peers - How are peers identified? 
  3. Interfaces - How are interfaces and virtual interfaces identified? Is it protocol dependent?
  4. Use KeyStartAccept, KeyStopAccept, KeyStartGenerate, and KeyStopGenerate as field names in the conceptual database rather than RcvNotBefore, RcvNotAfter, SendNotBefore, and SendNotAfter. 
       This will be consistent with RFC 2238 and RFC 5709.

The answer to #3 will be useful in determining whether or not the keys for OSPF virtual links can easily mapped to the database. I had previously raised this issue but hadn't received a response. 

Thanks,
Acee 

On Nov 16, 2011, at 1:19 AM, Joel M. Halpern wrote:

> Thank you Sam.
> 
> WG, this text attempts to capture an apparent agreement in the face-to-face meeting on how to resolve Russ Housley's discuss of the design guidelines document.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Nov 2011 00:20:11 -0500

These appear to be useful questions that we need to answer before we 
send keytables for publication.
I look forward to comments from the authors.

However, since the proposed reference to keytables in the 
design-guidelines is to the concept, not a normative reference to the 
specific document, I am not sure I understand why those detail issues 
are an objection to the conceptual reference in the design guidelines 
document.
Can you clarify?

Yours,
Joel

On 11/16/2011 11:44 PM, Acee Lindem wrote:
>> Joel&  Brian

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 17 Nov 2011 10:58:32 +0530

In addition to this the LocalKeyID and PeerKeyID defined in karp-crypto-table are 15 bit values (the MSB is reserved). This cant even accommodate the key size specified in RFC 5310 and several other routing security drafts. So the least that needs to be done is to increase this to 17 bits.

When doing draft-ietf-ospf-auth-trailer-ospfv3 there was some discussion on the key size and we had reached a consensus on keeping the key size (equivalent of LocalKeyID and PeerKeyID) as 32 bits. It would thus make sense to increase the LocalKeyID and PeerKeyID sizes in the karp-crypto-table to at least 32 or 33 bits.

Cheers, Manav

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Acee Lindem
> Sent: Thursday, November 17, 2011 10:14 AM
> To: Joel M. Halpern
> Cc: Sam Hartman; [email-masked]
> Subject: Re: [karp] Proposed text for design guide
> 
> Hi Joel,
> While this may be the ultimate positioning of the key table 
> draft, I think it is premature to elevate it to this status. 
> 
>   1. LocalKeyID - Don't overload whether it is a pairwise or 
> group key in the high order bit of the ID. Since there are 
> already over 15 key fields in conceptual database, I don't 
> see advantage of overloading the ID space. Let's not forget 
> that if this draft becomes an RFC, administrators may 
> actually have to configure these IDs. 
>   4. Use KeyStartAccept, KeyStopAccept, KeyStartGenerate, and 
> KeyStopGenerate as field names in the conceptual database 
> rather than RcvNotBefore, RcvNotAfter, SendNotBefore, and 
> SendNotAfter. 
> The answer to #3 will be useful in determining whether or not 
> the keys for OSPF virtual links can easily mapped to the 
> database. I had previously raised this issue but hadn't 
> received a response. 
> 
> Thanks,
> Acee 
> 
> > WG, this text attempts to capture an apparent agreement in 
> the face-to-face meeting on how to resolve Russ Housley's 
> discuss of the design guidelines document.
> > 
> >> KARP will focus on an abstraction for keying information that 
> >> describes the interface between routing protocols, operators and 
> >> automated key management. Conceptually when routing 
> protocols send or 
> >> recieve packets they will look up the key to use in this 
> abstract key 
> >> table. Conceptually, there will be an interface for a routing 
> >> protocol to make requests of automated key management when it is 
> >> being used; when keys become available they will be made 
> available in 
> >> the key table. There is no requirement that this 
> abstraction be used 
> >> for implementation; the abstraction serves the needs of 
> >> standardization an and management. Specifically as part of 
> the KARP work plan:
> >> 
> >> 1) KARP will design the key table abstraction and the interface 
> >> between key management protocols and routing protocols.
> >> 
> >> 2) For each routing protocol, we will define the mapping 
> between how 
> >> the protocol represents key material and the protocol 
> independent key 
> >> table abstraction. When routing protocols share a common mechanism 
> >> for authentication, such as the TCP Authentication Option, 
> the same 
> >> mapping is likely to be reused between protocols. An 
> implementation 
> >> may be able to move much of the keying logic into code related to 
> >> this shared authentication primitive rather than code 
> specific to routing protocols.
> >> 
> >> 3) When designing automated key management for both symmetric keys 
> >> and group keys, we will only use the abstractions designed 
> in point 1 
> >> above to communicate between automated key management and 
> routing protocols.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 17 Nov 2011 05:28:47 -0500

On Nov 17, 2011, at 12:20 AM, Joel M. Halpern wrote:

> These appear to be useful questions that we need to answer before we send keytables for publication.
> However, since the proposed reference to keytables in the design-guidelines is to the concept, not a normative reference to the specific document, I am not sure I understand why those detail issues are an objection to the conceptual reference in the design guidelines document.
> Can you clarify?

As there are open issues on the draft, how can we be sure that this draft will become an RFC and ultimately be published? Would this be a normative or informative reference in the KARP design guide? 

Thanks,
Acee

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Nov 2011 17:59:02 -0800

Hi, all,

Following up on my view about the keytable issue, based on a lengthy 
discussion I had this AM with Ron Bonica on this:

There are three basic components in automatic keying:

	- a key negotiation/exchange protocol
		here, IKEv2

	- something that uses keys to protect messages
		here at the transport layer, TCP-AO
		and at other layers various message-signing mechanisms

	- something that manages key use
		THIS is the missing part, AFAICT

Gatekeeper is a KMS - it is the key manager system. More specifically, 
it manages the meta-information about keys - lifetime, key exchange 
tags, etc. It need not ever contain key values.

This is true across all KARP solutions - the "keytable" describes a 
place where keys are stored, but that is an artifact of an 
implementation. In TCP-AO, these are inside AO. In IPsec, they're inside 
IPsec. But that's not the component we need to describe - all keying 
mechanisms have a place they store the keys they use.

What we need to describe (if at all) is the KMS as distinct from the 
keying protocol and the key-use mechanism.

Joe