Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols

Curtis Villamizar <curtis@occnc.com> Fri, 15 April 2011 20:39 UTC

Return-Path: <curtis@occnc.com>
X-Original-To: ospf@ietfc.amsl.com
Delivered-To: ospf@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3234AE0682 for <ospf@ietfc.amsl.com>; Fri, 15 Apr 2011 13:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.374
X-Spam-Level:
X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFAh8-3BktYS for <ospf@ietfc.amsl.com>; Fri, 15 Apr 2011 13:39:15 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfc.amsl.com (Postfix) with ESMTP id 4F423E067F for <ospf@ietf.org>; Fri, 15 Apr 2011 13:39:15 -0700 (PDT)
Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p3FKd8U9075368; Fri, 15 Apr 2011 16:39:08 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com)
Message-Id: <201104152039.p3FKd8U9075368@harbor.orleans.occnc.com>
To: Manav Bhatia <manav.bhatia@alcatel-lucent.com>
From: Curtis Villamizar <curtis@occnc.com>
In-reply-to: Your message of "Thu, 14 Apr 2011 10:40:26 +0530." <4DA681C2.5070108@alcatel-lucent.com>
Date: Fri, 15 Apr 2011 16:39:08 -0400
Sender: curtis@occnc.com
Cc: "ospf@ietf.org" <ospf@ietf.org>
Subject: Re: [OSPF] FW: Using dynamically derived Traffic Keys for Routing Protocols
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@occnc.com
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 20:39:16 -0000

In message <4DA681C2.5070108@alcatel-lucent.com>
Manav Bhatia writes:
>  
> Hi Curtis,
>  
> >
> > You might want to say "for doing *session* key rollovers".  The
> > persistant key rollover would need a different mechanism.
> >
>  
> I had actually meant a persistant key rollover. Why would this mechanism 
> not work there?
>  
> Assume A and B are speaking to each other and A now wants to move to a 
> different key. All it needs to do is to generate a new Nonce that will 
> be fed into the KDF that B will use to generate the new traffic key.
>  
> Also note that the keys used in this proposal will not be symmetrical.
>  
> Cheers, Manav


The common practice as I understand it is to maintain at least two
keys, one is used to build authentication headers and one or either of
the two can be used to check authentication headers.  During a
cutover, there is an interim period during which one end is more up to
date than the other.  First the second key is added as an alternate
key to check authentication headers.  Then when the provider (or
software) has verified that this key is available where it needs to
be, the new key is used to build authentication headers.  Finally the
old key is disabled and the process can be repeated later.

The same applies to assymmetrical key pairs.  The new public key needs
to be on the recieve side before the sender starts using the new
private key (assuming that sort of key pair).  There should be no
requirement for the persistant key to be symmetrical and it is
perfectly valid to have different shared session keys for each
direction, though perhaps there is very if any little benefit.

The session keys would be unique to a pair of routers, would be
transient in nature, and there is no need for the NOC (network
operation center) to know what session keys are in use at any given
time.  Only the persistant keys would be maintained by the NOC and
held in non-volitile memory so as to remain persistant over reboots.

Curtis