Subject: [karp] Using dynamically derived Traffic Keys for Routing Protocols

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 14 Apr 2011 05:17:50 +0530

Hi,

Instead of using the pre shared key (PSK) in manual keying for all packets the routing protocols could use a traffic key that's derived from the PSK using some key derivation function. Each side could announce a random number (a nonce) and the KDF could mix this with the PSK to derive the traffic key per session. Benefits of this approach:

o Key rollover becomes very easy as it's a local decision now requiring now co-ordination with our peers. Each side can generate a new nonce and all others recompute the traffic key based on the new nonce value. Attackers cant inject packets with spurious nonces as this packet will be protected using the traffic key based on the nonce that others have sent.

o Avoids inter-session replay attacks without involving non volatile memory as each router will use a different nonce upon booting up.

In OSPF the nonce could be carried in the HELLO packets. There could be bit carried in the HELLOs which would indicate that the Hello is currently using the long lived key (or the PSK). The receiver upon receiving this would authenticate the packet using the PSK and would use the KDF to derive the traffic key. The KDF would mix the nonce with the PSK in some deterministic fashion. The receiver uses the derived traffic key for signing all subsequent OSPF packets and would indicate this by setting some bit (which says using traffic key). It will also include its own nonce. The original sender now uses the nonce that it receives and starts using the traffic key derived from this nonce for all subsequent packets. For a key rollover, the senders just have to choose a new nonce value. This can be done as frequently as desired and requires no manual intervention. 

Does this sound as going in the right direction?

Cheers, Manav

--
Manav Bhatia,
Service Router Product Group (SRPG)
Alcatel-Lucent, India

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Thu, 14 Apr 2011 03:50:53 +0000

Hi, Manav:

I just handled my report and read your email. It seems that you are trying to implement some functions (generating session keys at run time) of an automatic of kmp into routing protocols instead of generating a generic KMP solution for different routing protocols?  My concern is whether it is conflict with the objective of karp?

Cheers
Dacheng

>> -----邮件原件-----
>> 发件人: [email-masked] [mailto:[email-masked]] 代表 Bhatia,
>> Manav (Manav)
>> 发送时间: 2011年4月14日 7:48
>> 收件人: [email-masked]
>> 主题: [karp] Using dynamically derived Traffic Keys for Routing Protocols
>> 
>> Hi,
>> 
>> Instead of using the pre shared key (PSK) in manual keying for all packets the
>> routing protocols could use a traffic key that's derived from the PSK using
>> some key derivation function. Each side could announce a random number (a
>> nonce) and the KDF could mix this with the PSK to derive the traffic key per
>> session. Benefits of this approach:
>> 
>> o Key rollover becomes very easy as it's a local decision now requiring now
>> co-ordination with our peers. Each side can generate a new nonce and all
>> others recompute the traffic key based on the new nonce value. Attackers
>> cant inject packets with spurious nonces as this packet will be protected using
>> the traffic key based on the nonce that others have sent.
>> 
>> o Avoids inter-session replay attacks without involving non volatile memory as
>> each router will use a different nonce upon booting up.
>> 
>> In OSPF the nonce could be carried in the HELLO packets. There could be bit
>> carried in the HELLOs which would indicate that the Hello is currently using
>> the long lived key (or the PSK). The receiver upon receiving this would
>> authenticate the packet using the PSK and would use the KDF to derive the
>> traffic key. The KDF would mix the nonce with the PSK in some deterministic
>> fashion. The receiver uses the derived traffic key for signing all subsequent
>> OSPF packets and would indicate this by setting some bit (which says using
>> traffic key). It will also include its own nonce. The original sender now uses the
>> nonce that it receives and starts using the traffic key derived from this nonce
>> for all subsequent packets. For a key rollover, the senders just have to choose
>> a new nonce value. This can be done as frequently as desired and requires no
>> manual intervention.
>> 
>> _______________________________________________
>> karp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/karp

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 14 Apr 2011 09:40:22 +0530

Hi Dacheng,

This mechanism will provide a seamless way to do a key rollover when
using manual keying which i believe is one of the main things that KARP
has been commissioned to work on. In fact, i believe that this will
integrate very nicely with draft-ietf-karp-crypto-key-table-00 which can
be extended to explain how the traffic keys should be used instead of
the long lived PSKs. Please note that this is NOT an alternative to the
KARP boot count approach as the latter is only meant for protecting
against inter-session replays. This mechanism helps in implementing key
rollover and as a by-product helps preventing inter-session replay
attacks.  This is not contending with a generic KMP that the KARP has to
work on and is providing key rollovers when using manual keying.

Cheers, Manav

On 4/14/2011 9:20 AM, Dacheng Zhang(Dacheng) wrote:
> Hi, Manav:
> 
> I just handled my report and read your email. It seems that you are trying to implement some functions (generating session keys at run time) of an automatic of kmp into routing 

protocols instead of generating a generic KMP solution for different
routing protocols?  My concern is whether it is conflict with the
objective of karp?

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Apr 2011 00:14:12 -0400

In message <[email-masked]>
"Bhatia, Manav (Manav)" writes:
>  
> Hi,
>  
> Instead of using the pre shared key (PSK) in manual keying for all
> packets the routing protocols could use a traffic key that's derived
> from the PSK using some key derivation function. Each side could
> announce a random number (a nonce) and the KDF could mix this with the
> PSK to derive the traffic key per session. Benefits of this approach:
>  
> o Key rollover becomes very easy as it's a local decision now
> requiring now co-ordination with our peers. Each side can generate a
> new nonce and all others recompute the traffic key based on the new
> nonce value. Attackers cant inject packets with spurious nonces as
> this packet will be protected using the traffic key based on the nonce
> that others have sent.
>  
> o Avoids inter-session replay attacks without involving non volatile
> memory as each router will use a different nonce upon booting up.
>  
> In OSPF the nonce could be carried in the HELLO packets. There could
> be bit carried in the HELLOs which would indicate that the Hello is
> currently using the long lived key (or the PSK). The receiver upon
> receiving this would authenticate the packet using the PSK and would
> use the KDF to derive the traffic key. The KDF would mix the nonce
> with the PSK in some deterministic fashion. The receiver uses the
> derived traffic key for signing all subsequent OSPF packets and would
> indicate this by setting some bit (which says using traffic key). It
> will also include its own nonce. The original sender now uses the
> nonce that it receives and starts using the traffic key derived from
> this nonce for all subsequent packets. For a key rollover, the senders
> just have to choose a new nonce value. This can be done as frequently
> as desired and requires no manual intervention.
>  

Manav,

It seems like a good direction for any routing protocol, with the
application to OSPF done in the HELLO.

A shorter session key and more simple authentication method could be
used with a strong persistent shared key and method for any protocol
for which the authentication burden on each packet was considered too
great a computational load to be practical with a long key and
stronger algorithm.

Another thing to consider in KARP is using two methods, a weak one
with short key and a stronger one.  The purpose of the weak one would
be to toss out denial-of-service attack packets at the highest rate
possible and the stronger method would only be used after the weaker
passed.  If packets start to arrive with the cheap authentication
passing and the expensive one failing, then time to pick new keys.

One of the reasons that vendors and providers don't like strong
authentication and long keys is that it make a denial of service
attack much more effective.  This would eliminate that objections.

Of course, line rate filtering as a first protection is still needed
for high speed interfaces, particularly with boxes with lots of 10
Gb/s or 100 Gb/s interfaces.  [Do they make 40G interfaces? :) ]

Curtis

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 13 Apr 2011 22:04:15 -0700

Hi Manav,

Interesting. Isn't this what the Key tables draft already states?

I guess what you are stating is how to use the Key Tables for OSPF right?

Thanks,
Vishwas
On Wed, Apr 13, 2011 at 4:47 PM, Bhatia, Manav (Manav) <
[email-masked]> wrote:

> Hi,
>
> Instead of using the pre shared key (PSK) in manual keying for all packets
> the routing protocols could use a traffic key that's derived from the PSK
> using some key derivation function. Each side could announce a random number
> (a nonce) and the KDF could mix this with the PSK to derive the traffic key
> per session. Benefits of this approach:
>
> cant inject packets with spurious nonces as this packet will be protected
> using the traffic key based on the nonce that others have sent.
>
> o Avoids inter-session replay attacks without involving non volatile memory
> as each router will use a different nonce upon booting up.
>
> fashion. The receiver uses the derived traffic key for signing all
> subsequent OSPF packets and would indicate this by setting some bit (which
> says using traffic key). It will also include its own nonce. The original
> sender now uses the nonce that it receives and starts using the traffic key
> derived from this nonce for all subsequent packets. For a key rollover, the
> senders just have to choose a new nonce value. This can be done as
> frequently as desired and requires no manual intervention.
>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Apr 2011 01:22:05 -0400

In message <[email-masked]>
"Dacheng Zhang(Dacheng)" writes:
>  
> Hi, Manav:
>  
> I just handled my report and read your email. It seems that you are
> trying to implement some functions (generating session keys at run
> time) of an automatic of kmp into routing protocols instead of
> generating a generic KMP solution for different routing protocols?  My
> concern is whether it is conflict with the objective of karp?
>  
> Cheers
> Dacheng

Dacheng,

If a goal of KARP is to produce something secure *and deployable*,
then a strong persistent key and a computationally more easy session
key is a good idea.  If the goals of KARP are limited to producing
things that seem neat to security guys, then maybe not.

Right now providers don't want to deploy strong authentication because
is makes denial-of-service attacks more effective and DDOS attacks are
considered a more real threat than any other for most providers.  I
think KARP is the right place to address that problem (with a usable
solution, not with more complaints about strong authentication not
being used).

Curtis

> >> -----�ʼ�ԭ��-----
> >> ������: [email-masked] [mailto:[email-masked]] ���� Bhatia,
> >> Manav (Manav)
> >> ����ʱ��: 2011��4��14�� 7:48
> >> �ռ���: [email-masked]
> >> ����: [karp] Using dynamically derived Traffic Keys for Routing Protocols
> >> 
> >> Hi,
> >>

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 14 Apr 2011 10:57:57 +0530

No Vishwas, the key tables draft is not discussing this. Its different 
and is dealing with what the database should look like. It is also not 
(and it needn't) going into the details of how the short-lived key is 
derived from the long-lived keys.

You can look at 
http://tools.ietf.org/html/draft-bhatia-karp-ospf-ip-layer-protection-03#page-17

to see how OSPF can use the Key Tables described in that draft.

Cheers, Manav

On 4/14/2011 10:34 AM, Vishwas Manral wrote:
> On Wed, Apr 13, 2011 at 4:47 PM, Bhatia, Manav (Manav)
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     announce a random number (a nonce) and the KDF could mix this with
>     the PSK to derive the traffic key per session. Benefits of this
>     approach:
>
>     this packet will be protected using the traffic key based on the
>     nonce that others have sent.
>
>     derived traffic key for signing all subsequent OSPF packets and
>     would indicate this by setting some bit (which says using traffic
>     key). It will also include its own nonce. The original sender now
>     uses the nonce that it receives and starts using the traffic key
>     derived from this nonce for all subsequent packets. For a key
>     rollover, the senders just have to choose a new nonce value. This
>     can be done as frequently as desired and requires no manual
>     intervention.
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Thu, 14 Apr 2011 06:40:53 +0000

For a key rollover, the senders just have to choose
>> a new nonce value. This can be done as frequently as desired and requires no
[Dacheng Zhang] 
A very tiny comment here. Since OSPF provides Key ID, it may be possible to use nonce values and psk to generate a list of keys in one turn. So, two routers does not have to exchange nonce to update session keys.

---

From: Acee Lindem <[email-masked]>
Date: Thu, 14 Apr 2011 05:36:44 -0400

Hi Dacheng,
I agree with Manav that the KMP protocol should provide the master keys and the traffic or session keys should be derived by the individual routing protocols. 
Thanks,
Acee

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Thu, 14 Apr 2011 10:05:25 +0000

Hi, 
I have sent Manav a private email several hours ago,  in which I agreed that this solution is good in security. I just don't know whether people will like the complexity introduced by integrating session key management into the implementations of routing protocols. If people don't care about this problem, this solution is ok with me too. ^_^
Cheers

Dacheng 

>> -----邮件原件-----
>> 发件人: Acee Lindem [mailto:[email-masked]]
>> 发送时间: 2011年4月14日 17:37
>> 收件人: Dacheng Zhang(Dacheng)
>> 抄送: Bhatia, Manav (Manav); [email-masked]
>> 主题: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols
>> 
>> Hi Dacheng,
>> I agree with Manav that the KMP protocol should provide the master keys and
>> the traffic or session keys should be derived by the individual routing
>> protocols.
>> Thanks,
>> Acee
>> > I just handled my report and read your email. It seems that you are trying to
>> implement some functions (generating session keys at run time) of an
>> automatic of kmp into routing protocols instead of generating a generic KMP
>> solution for different routing protocols?  My concern is whether it is conflict
>> with the objective of karp?
>> >
>> > Cheers
>> > Dacheng
>> >
>> >>> -----邮件原件-----
>> the
>> using
>> memory as
>> subsequent

---

From: Venkatesh Sriram <[email-masked]>
Date: Thu, 14 Apr 2011 21:21:06 +0530

It would be great if someone can draft this idea (in Manav's original
email) so that it becomes easier to track and follow. I believe this
will work for IS-IS as well where this additional information needs to
be passed in TLV 10. I like the idea of a KMP providing a long-lived
key (or a shared secret when using manual keying) and the routing
protocols deriving the short-term keys and using it internally
themselves. This imo is completely within the charter of KARP. I also
agree with what Curtis said earlier about this mechanism being
applicable for regular key rollover - something that operators have
been looking for since a long time now.

Sriram

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 15 Apr 2011 20:57:59 -0400

In message <[email-masked]>
"Dacheng Zhang(Dacheng)" writes:
> A very tiny comment here. Since OSPF provides Key ID, it may be
> possible to use nonce values and psk to generate a list of keys in one
> turn. So, two routers does not have to exchange nonce to update
> session keys.

That gives an attacker plenty of time to crack a session key since the
exchange without a nonce can be replayed at any time and the old
session key reused.

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 17 Apr 2011 06:12:58 +0530

Hi,

I have written the proposal in the draft format and its available here:
http://www.ietf.org/id/draft-bhatia-karp-short-lived-keys-00.txt

Would be great if folks can review and provide feedback on this. The proposal in the draft is currently quite raw and I believe it requires quite a few iterations before it becomes something that can be seriously considered as a direction that KARP should take wrt using short-lived keys for the routing protocols (RPs). I am hoping that this will trigger some discussion which will provide more clarity on how RPs can make use of such keys.

Cheers, Manav

> -----Original Message-----
> From: Venkatesh Sriram [mailto:[email-masked]] 
> Sent: Thursday, April 14, 2011 9.21 PM
> To: Bhatia, Manav (Manav); Acee Lindem
> Cc: [email-masked]
> Subject: Re: [karp] Using dynamically derived Traffic Keys 
> for Routing Protocols
>

---

From: mark Brown <[email-masked]>
Date: Mon, 18 Apr 2011 07:23:19 +0530

Hi Manav,

The idea proposed in the short-lived-keys draft appears to be tenable.
However, this draft is suggesting something very significant for the
KARP almost under the hood -  do we want the individual routing
protocols to drive the key exchange or should it be left for a new
automated key management protocol to do that? I understand that you
assume that an AKM will do the long-lived key exchange and that you
are only driving the traffic keys, however, just wanted to bring this
up so that we have a consensus on this.

I am not suggesting that i have an issue with your approach; am just
trying to make it very explicit so that folks appreciate the design
and the proposal before this is taken forward.

My teeny-weeny nit with this idea is that it will require each routing
protocol to individually do the traffic (or the short-lived key, as
you put it) key exchange. I would rather see this offloaded to a new
protocol that does just this. Ideally, the new protocol should
exchange or negotiate a new session key that should be used by all
routing and signaling protocols.

BR,
Mark

---

From: "Dacheng Zhang(Dacheng)" <[email-masked]>
Date: Mon, 18 Apr 2011 03:15:55 +0000

>> routing and signaling protocols.
[Dacheng Zhang] 
In my previous emails, I showed a similar opinion with you. That is, it may be worthwhile for people to discuss which solution is more preferred: Designing a generic traffic key generating protocol or implement the correspondent functionality within different routing protocols respectively. We also need to decide is that whether the automatic key management system going to be proposed by Karp should deal with the traffic key generating issue or just leave it to routing protocols.

Cheers

Dacheng

>> > Would be great if folks can review and provide feedback on this. The proposal
>> in the draft is currently quite raw and I believe it requires quite a few
>> iterations before it becomes something that can be seriously considered as a
>> direction that KARP should take wrt using short-lived keys for the routing
>> protocols (RPs). I am hoping that this will trigger some discussion which will
>> provide more clarity on how RPs can make use of such keys.
>> >
>> > Cheers, Manav
>> >

---

From: Uma Chunduri <[email-masked]>
Date: Sun, 17 Apr 2011 23:40:01 -0400

I fundamentally oppose this idea of deriving traffic keys with individual RPs. 
I have to say this is not conceived well.

Why?
  - All key derivation long/short should be function of AKMs and RP must not do this
    to keep clean separation for all security aspects while generating keys
  - One immediate thing comes to my mind is PFS (perfect forward secrecy)
  - think of extensibility  (it's lost)

I am not sure if this is part of KARP design guidelines, if not this should be included.
RP's should just focus on using keys (get these manually or through AKM).

Regards,
-Uma

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of mark Brown
Sent: Sunday, April 17, 2011 6:53 PM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols

Hi Manav,

The idea proposed in the short-lived-keys draft appears to be tenable.
However, this draft is suggesting something very significant for the KARP almost under the hood -  do we want the individual routing protocols to drive the key exchange or should it be left for a new automated key management protocol to do that? I understand that you assume that an AKM will do the long-lived key exchange and that you are only driving the traffic keys, however, just wanted to bring this up so that we have a consensus on this.

I am not suggesting that i have an issue with your approach; am just trying to make it very explicit so that folks appreciate the design and the proposal before this is taken forward.

My teeny-weeny nit with this idea is that it will require each routing protocol to individually do the traffic (or the short-lived key, as you put it) key exchange. I would rather see this offloaded to a new protocol that does just this. Ideally, the new protocol should exchange or negotiate a new session key that should be used by all routing and signaling protocols.

BR,
Mark

On Sun, Apr 17, 2011 at 6:12 AM, Bhatia, Manav (Manav) <[email-masked]> wrote:
>> Subject: Re: [karp] Using dynamically derived Traffic Keys for 
>> Routing Protocols
>>
>> will work for IS-IS as well where this additional information needs 
>> to be passed in TLV 10. I like the idea of a KMP providing a 
>> long-lived key (or a shared secret when using manual keying) and the 
>> routing protocols deriving the short-term keys and using it 
>> internally themselves. This imo is completely within the charter of 
>> KARP. I also agree with what Curtis said earlier about this mechanism 
>> being applicable for regular key rollover - something that operators 
>> have been looking for since a long time now.
>>
>> Sriram
>>

---

From: Uma Chunduri <[email-masked]>
Date: Sun, 17 Apr 2011 23:47:01 -0400

[Dacheng Zhang]
In my previous emails, I showed a similar opinion with you. That is, it may be worthwhile for people to discuss which solution is more preferred: Designing a generic traffic key generating protocol or implement the correspondent functionality within different routing protocols respectively. 
We also need to decide is that whether the automatic key management system going to be proposed by Karp should deal with the traffic key generating issue or just leave it to routing protocols.

[Uma] I strongly feel, AKM should also deal with traffic key generation and RPs should not be involved.

Regards,
-Uma

---

From: Venkatesh Sriram <[email-masked]>
Date: Mon, 18 Apr 2011 18:59:01 +0530

>   - All key derivation long/short should be function of AKMs

I am not sure I understand why you want the AKMs to exchange both the
long-lived and the short-lived keys? Cant they just exchange the
former and let a "KARP" module sitting on each router derive the
short-lived keys? Alternately, if the AKM can exchange short-lived
keys, why does it need to bother with exchanging the long-lived keys?

> and RP must not do this

I think we had envisaged this "KARP" module that would sit in each
router that the routing protocols would interact with to derive the
session keys.

>   - One immediate thing comes to my mind is PFS (perfect

Isnt this true whenever you have a session key being derived from a
long-lived key?

>   - think of extensibility  (it's lost)

Mind elaborating.

> RP's should just focus on using keys (get these manually or

But pray, why?

Sriram

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Apr 2011 13:57:16 -0400

>>>>> "Uma" == Uma Chunduri <[email-masked]> writes:

    Uma> I fundamentally oppose this idea of deriving traffic keys with
    Uma> individual RPs.  I have to say this is not conceived well.

    Uma> Why?  - All key derivation long/short should be function of
    Uma> AKMs and RP must not do this to keep clean separation for all
    Uma> security aspects while generating keys - One immediate thing
    Uma> comes to my mind is PFS (perfect forward secrecy) - think of
    Uma> extensibility (it's lost)

I'm sorry.
I do agree that we need to think through the proposal of using a KDF to
generate short-lived session keys more.
At least some of the claims made about it don't make sense to me.
However, it seems useful as good security design and as protection from
related key attacks.
Also, in cases where it works out, it may help with replay protection.

The approach of using a key derivation function has been discussed at
several meetings, as well as in section 4.1 of
draft-ietf-karp-ops-model, Tim Polk's draft on how to use the crypto
tables, and the crypto tables draft themselves.
I believe that TCP AO assumes a key derivation function similar to what
Manav proposes.

so, while I agree we need to work through the ideas, I'm having trouble
coming up with a justification for a response like "fundamentally
broken."
Can you help us all by working through your concerns in more detail?

I'd like to take two concerns you have.
First, the idea of PFS.
PFS implies secrecy. Confidentiality is explicitly out of scope for
KARP. So, I don't understand how PFS is valuable to us.
There's something related to PFS that is valuable: known good key
material absent an active attack.
That argues for an AKM protocl and some sort of DH exchange in that
protocol.
However, that doesn't mean key derivation cannot be used.

You argue that for design cleanlyness, key derivation should not be part
of the integrity protocol.
However, I think we have numerous examples of security protocols that
seem to have reasonably clean separation and that perform this sort of
key derivation.
I'll put forward TCP AO, and the cryptographic primitives defined in RFC
3961 for Kerberos as specific examples. (I'm not proposing using RFC
3961 in KARP, simply arguing that we have lots of cases in the IETF
where we've done this before.)

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Apr 2011 17:12:48 -0400

so, while I agree we need to work through the ideas, I'm having trouble coming up with a justification for a response like "fundamentally broken."
Can you help us all by working through your concerns in more detail?

I'd like to take two concerns you have.
First, the idea of PFS.
PFS implies secrecy. Confidentiality is explicitly out of scope for KARP. So, I don't understand how PFS is valuable to us.

[Uma] No, PFS doesn't imply confidentiality. All It all imply, if it required is - one should not use not only long term keys derived from some 
      form of DH exchange but also should not use any keying material associated with it.
           
There's something related to PFS that is valuable: known good key material absent an active attack.
That argues for an AKM protocl and some sort of DH exchange in that protocol.
However, that doesn't mean key derivation cannot be used.

[Uma] I am not saying key derivation cannot be used. If PFS is required, now RPs should do DH exchange and this won't stop there.
      I definitely see this as a slippery-slope and PFS is only one example.

You argue that for design cleanlyness, key derivation should not be part of the integrity protocol.

[Uma] integrity protocol?? You mean Routing protocol?
      The last thing a routing protocol implementation has to worry about is randomness of pseudo-random numbers generated to 
      derive keys and if it is FIPS complaint/pass security audits. Well all this can be done
      my question is why to develop this redundancy? why not to use the AKM that is being used to get long-term keys to start with and use key-tables effectively 
      to select the traffic keys rather than building part of AKM job in all routing protocols.

---

From: Venkatesh Sriram <[email-masked]>
Date: Tue, 19 Apr 2011 03:09:33 +0530

> [Uma] No, PFS doesn't imply confidentiality. All It all
> imply, if it required is - one should not use not only long
> term keys derived from some

Are you suggesting that we should not use short-lived keys from a
long-lived key?

>       The last thing a routing protocol implementation has to
> worry about is randomness of pseudo-random numbers generated to
>       derive keys and if it is FIPS complaint/pass security

RPs can speak to the "KARP module" and get all that information - they
dont need to do this themselves. This module can be written and owned
by the security experts. There btw are already proposals for extending
RPs to generate Nonces - You can look at
draft-bhatia-karp-ospf-ip-layer-protection-03 for more details.

> audits. Well all this can be done
>       my question is why to develop this redundancy? why not
> to use the AKM that is being used to get long-term keys to
> start with and use key-tables effectively

The key tables draft mostly talks about associating a life time with
keys so that a rollover can be implemented. I dont think it mentions
anything about *how* the session keys can be derived.

I think the essence of Manav's proposal is that we use a session key
instead of a long-lived key to secure the routing protocols. Lets us
first start by discussing whether we agree to this proposal or not. If
we do agree, then we can look at how the session keys may be derived.
However, if it turns out that people dont agree with using the session
keys, then the whole discussion is moot.

My vote is to use the session keys derived from the long-lived keys,
simply because we shouldnt be using the long-lived key a lot. I would
rather that peers exchange one long-lived key and then let different
protocols derive different session keys and use that for their
exchange instead of having every protocol use the same long-lived key.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Apr 2011 17:42:28 -0400

>>>>> "Uma" == Uma Chunduri <[email-masked]> writes:

There are two reasons I think we need KDFs.

1) deal with related key attacks

2) Several issues that come up in deployments where there is no AKM.

    Uma> [Uma] I am not saying key derivation cannot be used. If PFS is
    Uma> required, now RPs should do DH exchange and this won't stop
    Uma> there.  I definitely see this as a slippery-slope and PFS is
    Uma> only one example.

I'm sorry, I'm not seeing the slope.
I need to ask you to enumerate all the examples or at least enough of
them to see a slope.

Later, you talk about the quality of random numbers  for a KDF.
In this sort of case I'd expect the only input to the KDF that needs to
be random is  the key.
Yes, we'll care about the cryptographic quality of the KDF, but that's
not too hard to deal with.

---

From: Glen Kent <[email-masked]>
Date: Tue, 19 Apr 2011 03:26:40 +0530

Hi Sriram,

> keys, then the whole discussion is moot.

I think this is briefly discussed in Section 2 and 3 of
draft-bhatia-karp-short-lived-keys-00.txt and i would tend to agree
with Manav there.

> exchange instead of having every protocol use the same long-lived key.

+1

Glen

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Apr 2011 19:16:10 -0400

Ok let me ask a simple question -

Why this session key is required and why not use the long lived key itself?

If these session keys are completely relied and derived from  the Master key (and some NONCE, which is being exchanged *plain* through http://www.ietf.org/id/draft-bhatia-karp-short-lived-keys-00.txt) why bother deriving this.

If Master key is compromised (if it's manual it's possible and the one of the reasons for this work)  
    - I don't see the value of these secondary keys, here keying material is being exchanged plain from RPs

With AKM almost eliminate as you would get those *securely* through *authenticated* party/peer  and re-key of master key itself is possible
    - again, why any body wants to use these secondary keys, where keying material is being exchanged plain from RPs; use rather long-lived.

Still, RPs only need to derive these keys
    - these should be capable of PRF (new DH exchange)
    - NONCE should be random enough (RFC 4086: http://www.ietf.org/rfc/rfc4086.txt)
    - Should use better KDF functions (consider AES and CMAC too)
    - above all any keying material exchanged should be protected the same way as master key generation

Regards,
-Uma

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Monday, April 18, 2011 2:42 PM
To: Uma Chunduri
Cc: Sam Hartman; mark Brown; Bhatia, Manav (Manav); [email-masked]
Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing Protocols

I'm sorry, I'm not seeing the slope.
I need to ask you to enumerate all the examples or at least enough of them to see a slope.

Later, you talk about the quality of random numbers  for a KDF.
In this sort of case I'd expect the only input to the KDF that needs to be random is  the key.
Yes, we'll care about the cryptographic quality of the KDF, but that's not too hard to deal with.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Apr 2011 19:36:23 -0400

>>>>> "Venkatesh" == Venkatesh Sriram <[email-masked]> writes:

    Venkatesh> The key tables draft mostly talks about associating a
    Venkatesh> life time with keys so that a rollover can be
    Venkatesh> implemented. I dont think it mentions anything about
    Venkatesh> *how* the session keys can be derived.

It does.
The KDF is one of the parameters of an entry.

    Venkatesh> I think the essence of Manav's proposal is that we use a
    Venkatesh> session key instead of a long-lived key to secure the
    Venkatesh> routing protocols. Lets us first start by discussing
    Venkatesh> whether we agree to this proposal or not. If we do agree,
    Venkatesh> then we can look at how the session keys may be derived.

I don't like your ordering much, because I think whether the session
keys have value depends entirely on how they are derived and what that
derivation brings us.

so I don't think the issues are seperable.

I don't think we need to decide on the specific cryptographic function,
but I do think we need to decide what parameters are inputs to the
derivation.  I'd certainly support proposals that did things like
guarantee different routing protocols have different keys; guarantee
different interfaces have different keys.

    Venkatesh> However, if it turns out that people dont agree with
    Venkatesh> using the session keys, then the whole discussion is
    Venkatesh> moot.

    Venkatesh> My vote is to use the session keys derived from the
    Venkatesh> long-lived keys, simply because we shouldnt be using the
    Venkatesh> long-lived key a lot. 

It has been claimed that we should not use a long-lived key a lot.
Eric Rescorla argued against most rationales for why you would care
about how many operations a key in a modern integrity protection
protocol was used.
I don't think there's a lot behind an argument that you should not use a
key for a large number of operations from a security standpoint with our
current understanding of cryptanalysis.
Other than increased complexity, it probably cannot hurt.

However, while my reasoning is different than yours, I do come to the
conclusion that there are inputs to the derivation that would make a
derivation very valuable.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Apr 2011 19:59:49 -0400

I don't like your ordering much, because I think whether the session keys have value depends entirely on how they are derived and what that derivation brings us.

I don't think we need to decide on the specific cryptographic function, but I do think we need to decide what parameters are inputs to the derivation.  I'd certainly support proposals that did things like guarantee different routing protocols have different keys; guarantee different interfaces have different keys.

[Uma] I agree here, not only different routing protocols also say different interfaces/links or areas may use different keys. 

It has been claimed that we should not use a long-lived key a lot.
Eric Rescorla argued against most rationales for why you would care about how many operations a key in a modern integrity protection protocol was used.
I don't think there's a lot behind an argument that you should not use a key for a large number of operations from a security standpoint with our current understanding of cryptanalysis.
Other than increased complexity, it probably cannot hurt.

However, while my reasoning is different than yours, I do come to the conclusion that there are inputs to the derivation that would make a derivation very valuable.

[Uma] ..and these inputs should be passed to AKMs as opaque information, get the keys exchanged securely in some repository and use the same (or) let all RPs do the same/similar.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 18 Apr 2011 23:45:26 -0700 (PDT)

Hi,

On Wed, April 13, 2011 4:47 pm, Bhatia, Manav (Manav) wrote:
> using some key derivation function. Each side could announce a random
> number (a nonce) and the KDF could mix this with the PSK to derive the
> traffic key per session. Benefits of this approach:
>
> o Key rollover becomes very easy as it's a local decision now requiring
> now co-ordination with our peers. Each side can generate a new nonce and
> all others recompute the traffic key based on the new nonce value.
> Attackers cant inject packets with spurious nonces as this packet will be
> protected using the traffic key based on the nonce that others have sent.
>

Detriments to that approach:

  o Msuses KDF since "key" is not uniformly random.

  o Susceptible to passive (!) dictionary attack.

  o No PFS.

Instead, it would be better to use the PSK as a CREDENTIAL for
authentication of a strong, uniformly random key in a manner that is
resistant to dictionary attack and that provides PFS. Like so:

  PSK
   |
   V
  KMP
   |
   V
 strong, uniformly random key
   |
   V
 keytable (w/KDF)
  | | | | | | |
  V V V V V V V
  session keys

  regards,

  Dan.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 16:23:36 -0400

In message <[email-masked]>
"Bhatia, Manav (Manav)" writes:
> Would be great if folks can review and provide feedback on this. The
> proposal in the draft is currently quite raw and I believe it requires
> quite a few iterations before it becomes something that can be
> seriously considered as a direction that KARP should take wrt using
> short-lived keys for the routing protocols (RPs). I am hoping that
> this will trigger some discussion which will provide more clarity on
> how RPs can make use of such keys. 
>  
> Cheers, Manav

Manav,

Router A must always use a key that is based on information provided
by router B.  If not, then a third party can replay a nonce exchange
that was captured.  Therefore section 4.2  has a security weakness.
Section 4.1 is fine.

To bootstrap, router A may have no information from router B.
Therefore a request for a nonce from A can come without key
information based in a nonce from B.  B should rate limit the replies
to avoid DOS.  Remebering the set of bootstrap nonce provided in the
recent past and rejecting those will also help.

Nice work.

Curtis

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 20 Apr 2011 06:21:36 +0530

Hi Curtis,
 
> that was captured.  

This cannot happen as the third patry will not be aware of the long-lived key. Or are you suggesting that someone could do this *if* they are aware of the long-lived key?

> Therefore section 4.2  has a security weakness.
> Section 4.1 is fine.

Multicast is an issue with Section 4.1

If I am on a LAN and I am speaking to 2 routers A and B, then which nonce should I use when sending out a multicast Hello? Should I use nonceA or nonceB? 

> recent past and rejecting those will also help.

Thanks! 

Cheers, Manav

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 19 Apr 2011 22:50:10 -0400

> [Uma] No, PFS doesn't imply confidentiality. All It all imply, if it 
> required is - one should not use not only long term keys derived from 
> some

Are you suggesting that we should not use short-lived keys from a long-lived key?

[Uma] I am not suggesting this. But RPs should not involve in exchanging keying material (NONCE) as proposed in here
      http://www.ietf.org/id/draft-bhatia-karp-short-lived-keys-00.txt.

     It can simply weakens the master key (which is cryptographically sound) by not being random enough. 
     Any key/key material exchange should be left to AKMs and maintain clean separation.
     This way you also will be guaranteed to get securely exchanged and properly
     authenticated keys (original or re-keying with PFS). 

>       The last thing a routing protocol implementation has to worry 
> about is randomness of pseudo-random numbers generated to

RPs can speak to the "KARP module" and get all that information - they dont need to do this themselves.
[Uma] What information?

 This module can be written and owned by the security experts. There btw are already proposals for extending RPs to generate Nonces - You can look at
draft-bhatia-karp-ospf-ip-layer-protection-03 for more details.

[Uma] Again, being RP, let's not exchange in keying material, until  
    - you have the  capability to for PFS (new DH exchange)
    - you can generate crypto quality NONCE 
    - above all any keying material exchanged should be protected the same way as master key generation

But, using KDFs with master key and other protocol/peer/area/interface specific parameters should be fine. 

Still, if manual keying is used and master key itself gets compromised (out of band usage etc..) 
         - these session keys can't bring any value
If, AKM is used of course, all these session keys should be *invalidated* when master key change 
         - if peer session closes or re-key happens (PFS could be in-built there and let AKMs deal with it).

Regards,
-Uma

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 20 Apr 2011 08:30:47 +0530

Hi Uma,

>      It can simply weakens the master key (which is 
> cryptographically sound) by not being random enough. 

I am afraid I don't understand how the mechanism described in this draft "weakens the master key".

You have a master key. Now, you put this through a KDF and you derive a key. How can this derived key be any less secure than the master key is something that I am unable to comprehend.

> maintain clean separation.

[clipped]
 
>     - you can generate crypto quality NONCE 

What makes you think that the security module running in a router can generate a crypto quality nonce and an RP running on that same router cant. Finally its some source code that would generate that. Why cant an RP access that same code via some interfacing module (a la the KARP module)

I agree that if the long-lived key is compromised then the session keys as proposed in this draft wouldn't help.

Cheers, Manav

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 19 Apr 2011 23:12:42 -0400

Hi Manav,

In-line -
-----Original Message-----
From: Bhatia, Manav (Manav) [mailto:[email-masked]] 
Sent: Tuesday, April 19, 2011 8:01 PM
To: Uma Chunduri
Cc: [email-masked]
Subject: RE: [karp] Using dynamically derived Traffic Keys for Routing Protocols

Hi Uma,

[Uma]  It can, if exchanged NONCE is not appropriate enough

[Uma] draft suggests RPs exchanged NONCE..
      Leave this keying material and proceed with KDF with master key alone  + other params

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 19 Apr 2011 23:54:01 -0400

In message <[email-masked]>
"Bhatia, Manav (Manav)" writes:
> This cannot happen as the third patry will not be aware of the
> long-lived key. Or are you suggesting that someone could do this *if*
> they are aware of the long-lived key?

If there is a way to say "I will use this nonce and key" then a third
party can capture such a packet and play it back later.

> Multicast is an issue with Section 4.1

Good point but what you have in 4.1 isn't replay proof.

> If I am on a LAN and I am speaking to 2 routers A and B, then which
> nonce should I use when sending out a multicast Hello? Should I
> use nonceA or nonceB? 

In that case the DR has to be trusted, but there needs to be an
exchange with the DR to validate that the key being used is fresh.

This amounts to a "I heard your suggestion to use key K, now please
validate the liveness of the key selection with this random value".
This one exchange would be needed for each router talking to the DR.

Do real networks use anything but point to point links?  :-)

Curtis

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 20 Apr 2011 11:10:55 +0530

> party can capture such a packet and play it back later.

Yes, it can and this is precisely why sec 4.2 requires implementations to support the challenge/response mechanism described in draft-bhatia-karp-ospf-ip-layer-protection.

With this the third party will not be able to replay old packets as the reciever will change its current nonce and would expect the third party to send a packet reflecting the updated nonce. Since it wouldn't be able to do that, the attack would thus not be successful.

> exchange with the DR to validate that the key being used is fresh.

.. and I do discuss this as well in sec 4.1. I think it brings in too much of complexity which can be completely avoided if we go by approach described in sec 4.2

> Do real networks use anything but point to point links?  :-)

In service provider networks, Yes. However a solution that precludes the possibility of supporting LANs may not be acceptable.

BTW, I have been told that we can expect multiple routers on a LAN in the data center environments.

Cheers, Manav

---

From: Bill Atwood <[email-masked]>
Date: Wed, 20 Apr 2011 10:00:24 -0400

On 4/19/2011 11:54 PM, Curtis Villamizar wrote:
> --snip--

Or something, not necessarily the DR.  The key used by a speaker can be 
common to the routers seen through an interface, or to all of the 
routers that are "neighbors" of the speaking router (which fits best 
with the way the "Hello" packet is defined, at least in PIM), or (if 
lesser security is acceptable) to a whole administrative region.

> Do real networks use anything but point to point links?  :-)

Yes :-)  In particular, multicast routing protocols multicast their 
hello messages on the LANs that they are connected to.  Therefore, since 
the SPI (to use the IPsec name) _cannot_ be determined by the incoming 
router (as it normally would be for a unicast IPsec SA), the various 
SPIs used by the routers in an "administrative region" must be 
coordinated by a "group owner" for that administrative region.  This is 
one reason why multicast protocols are classified separately in the karp 
documentation.  My own working assumption is that control over "who is 
my neighbor" will also reside with this "group owner", i.e., a router's 
willingness to exchange hello messages with its neighbor(s) will be 
determined by someone with larger scope than one LAN.  (Of course, this 
"permitted adjacency" information has to be retained over re-boots, so 
that the "group owner" need not be consulted at the time of the re-boot, 
to avoid an avalanche of requests at start-up time.)

   Bill

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
    and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Apr 2011 06:38:12 -0400

I agree with Manav that I see no way to weaken the master key with a
well defined KDF and with inputs independent of the master key.

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 28 Apr 2011 13:28:36 +0530

Hi Shraddha,

> In the design consideration section
> It is mentioned that "if an attacker is aware of long-lived keys, guessing
> the short-lived traffic key that will be generated next should not be
> possible."

While the nonce is being sent in clear, the attacker cannot "guess" what 
the Nonce will be since thats really a random number so cannot "guess" 
the short-lived key that will be used next.

>
> Since the short term keys are derived based on nonce which is carried in
> plain in OSPF messages, attacker who is aware of long-lived keys can easily
> Derive the short-term keys and mount man-in-the-middle attacks.

Only once the routers have moved to a shorted lived key. The attacker 
cannot know this in advance.

CHeers, Manav

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 28 Apr 2011 14:46:48 +0530

Hi Shraddha,

The document does not even claim to provide protection when your 
long-lived key is *compromised*. Its meant to derive different session 
keys (for different routing protocols) using the same long-lived key. It 
also helps where you dont use the same key over and over again which 
increases the possibility of inter-session replay attacks. If you keep 
changing the keys then you can prevent that from happening.

Cheers, Manav

On 4/28/2011 2:42 PM, shraddha wrote:
> ---Only once the routers have moved to a shorted lived key. The attacker
> ---cannot know this in advance.
>
> Yes. The attacker cannot know in advance about the short lived-key. But once
> Short lived key is derived, same key will be used till the nonce changes.
> This period is good enough for an attacker having long-lived key to mount
> man-in-the-middle.
>
> The point I am making here is that the short lived key derivation method
> described in the draft cannot provide protection against the compromised
> long-lived keys.
>
> Such a protection is possible only mechanisms such as DH algorithm is used
> for the key derivation.
>
> Rgds
> Shraddha
>
> ****************************************************************************
> ***********
> This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it!
>
>
> From: Manav Bhatia [mailto:[email-masked]]
> Sent: Thursday, April 28, 2011 1:29 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: shraddha <[email-masked]>
Date: Thu, 28 Apr 2011 12:40:20 +0530

Hi Manav,

I have one comment on the draft.

I am not able o understand the significance of "not being able to guess next
short lived-key" when attacker (having access to long lived key) can easily
play around with present short lived-key.
  
The advantage of the short term key could be that it gives less time for the
brute force algorithm to run and hence is more secure. I feel this should be
the design consideration rather than protection against the compromised
long-lived keys.

Rgds
Shraddha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bhatia, Manav (Manav)
Sent: Wednesday, April 20, 2011 11:11 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing
Protocols

> party can capture such a packet and play it back later.

Yes, it can and this is precisely why sec 4.2 requires implementations to
support the challenge/response mechanism described in
draft-bhatia-karp-ospf-ip-layer-protection.

With this the third party will not be able to replay old packets as the
reciever will change its current nonce and would expect the third party to
send a packet reflecting the updated nonce. Since it wouldn't be able to do
that, the attack would thus not be successful.

> exchange with the DR to validate that the key being used is fresh.

.. and I do discuss this as well in sec 4.1. I think it brings in too much
of complexity which can be completely avoided if we go by approach described
in sec 4.2

> Do real networks use anything but point to point links?  :-)

In service provider networks, Yes. However a solution that precludes the
possibility of supporting LANs may not be acceptable.

BTW, I have been told that we can expect multiple routers on a LAN in the
data center environments.

Cheers, Manav

---

From: shraddha <[email-masked]>
Date: Thu, 28 Apr 2011 14:42:44 +0530

Rgds
Shraddha

-----Original Message-----
From: Manav Bhatia [mailto:[email-masked]] 
Sent: Thursday, April 28, 2011 1:29 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [karp] Using dynamically derived Traffic Keys for Routing
Protocols

Hi Shraddha,

CHeers, Manav

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Apr 2011 09:08:37 -0400

At least some of the discussion on the list was that folks saw 
significant advantage in providing better resiliency in the face of the 
compromise of long-lived keys.

As I understand it, if we use an AKM for the session key derivation, 
there are ways to get such protection.  And then we can use keytables to 
let the routing protocol know what the session key is.
Which means that we don't have to modify the routing protocols, which is 
a significant benefit.

Yours,
Joel

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2011 10:01:35 -0700

Hi, all,

I'm wondering whether the KARP docs talk about the assumptions behind 
short-term keys, notably that any long-term session is either restarted 
or can support rekeying.

This isn't an issue for TCP-AO, but there are other protocols (legacy 
TCP MD5, and SSH which is being advocated for use for route caches in 
the new SIDR docs) that may not be as friendly to short-lived keys.

FWIW.

Joe