Subject: Re: [MSEC] Authentication for OSPFv3

From: [email-masked]
Date: Thu, 02 Oct 2008 13:21:57 -0400

Hi, 

I'd like to suggest that GSAKMP (RFC4535) merits a closer look as a starting 
point of a solution for the OSPF authentication problem. The following 
technical features would contribute towards that solution: 

1) GSAKMP has an autonomous distributed mode of operation that would allow
any authorized OSPF router to act in the role of a subordinate GCKS. This
mode is described in RFC4535 section 4.4.7. This finesses the problem
associated with communicating with a central GCKS when the OSPF routing
tables have yet to be populated. The primary GCKS would seed the group's
shared secret keying material to the one or more OSPF routers adjacent to it 
on the same layer-2 network. These adjacent routers would use a GSAKMP
registration exchange to acquire the group secret from the primary GSKS.
Each of those routers would turn around and act as a subordinate GCKS for
the OSPF routers residing on their other layer-2 networks. This would lead
to an expanding ring of group membership registrations. The OSPF router
group's secret keying material would propagate across the layer-3 network
hop-by-hop. 

2) The three message GSAKMP registration exchange can be multicasted on a
link local scope reserved address, rather than doing a unicast exchange with 
a pre-configured central GCKS. This "expanding ring search " mode of
operation is described in RFC4535 section 4.3. In the context of OSPF, the
exchange would use a reserved layer-2 local scoped multicast address. The
candidate Group Member would multicast a Request-To-Join (RTJ). One or more
layer-2 adjacent OSPF routers acting as a subordinate GCKS would respond to
the RTJ with the Key-DownLoad (KDL) message. The candidate Group Member
would select the KDL from the authenticated and authorized GCKS offering the 
most recent policy token. 

3) The MSEC policy token (RFC4534) is an extensible group security policy
framework. It facilitates near real-time synchronization of the group
security policy across the whole membership. The base definition prescribes
Group Member and GCKS authorizations and many other aspects of group
security policy. For OSPFv3 authentication, there would be extensions
defined that declare the authentication algorithm, key length, and all its
other properties. The OSPFv3 policy extension could also include digital
signature or TESLA authentication properties. 

4) GSAKMP also has an option (RFC4535 appendix A) for the use of Logical Key 
Hierarchy (LKH) for rekeying the group. 

The OSPF authentication/group keying problem has been dangling for at least
three or four years that I'm aware of, and it sounds like it has ripened for 
some movement.  I would be willing to contribute to an Internet Draft that 
profiles GSAKMP usage for OSPF authentication. Unfortunately, I do not
expect to be at the Minneapolis IETF. 

I don't subscribe to the other lists, i.e. sidr, ospf, rpsec, tsvwg, etc. So 
if you think it relevant, please forward this e-mail on my behalf if you
straddle MSEC and one of those other lists. 

tia, 

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

---

From: JW Atwood <[email-masked]>
Date: Sat, 04 Oct 2008 21:19:46 -0400

While I know little about GSAKMP, I have been working (with Salekul 
Islam and Maziar Siami) on the problem of PIM-SM authentication.  (See 
draft-ietf-pim-sm-linklocal-04.txt)  This problem has enough in common 
with the OSPF authentication problem that it may be worthwhile to look 
at a common solution.

The cleanest expression of the PIM-SM authentication problem that we 
have been able to formulate is based on the idea that each speaking 
router is the sender to a group that consists of all its one-hop 
neighbors.  Thus, the key server for that group could be co-located with 
the sender, and would be guaranteed to be reachable in one hop.  We 
recognized that this key server could survive across re-boots (by having 
local stable storage), but would need a "central" key server to permit 
it to learn about (legitimate) new neighbors.

I would be very interested in comments on these ideas (sharing concepts 
between PIM-SM and OSPF, and keyserver per speaking router), either on 
the MSEC list, or face-to-face in Minneapolis.

  Bill Atwood

[email-masked] wrote:
> Hi,
> I'd like to suggest that GSAKMP (RFC4535) merits a closer look as a 
> starting point of a solution for the OSPF authentication problem. The 
> following technical features would contribute towards that solution:
> shared secret keying material to the one or more OSPF routers adjacent 
> to it on the same layer-2 network. These adjacent routers would use a 
> GSAKMP
> link local scope reserved address, rather than doing a unicast 
> exchange with a pre-configured central GCKS. This "expanding ring 
> search " mode of
> would select the KDL from the authenticated and authorized GCKS 
> offering the most recent policy token.
> 4) GSAKMP also has an option (RFC4535 appendix A) for the use of 
> Logical Key Hierarchy (LKH) for rekeying the group.
> three or four years that I'm aware of, and it sounds like it has 
> ripened for some movement.  I would be willing to contribute to an 
> Internet Draft that profiles GSAKMP usage for OSPF authentication. 
> Unfortunately, I do not
> I don't subscribe to the other lists, i.e. sidr, ospf, rpsec, tsvwg, 
> etc. So if you think it relevant, please forward this e-mail on my 
> behalf if you

-- 

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: JW Atwood <[email-masked]>
Date: Sat, 04 Oct 2008 21:19:46 -0400

Bill Atwood

--

---

From: [email-masked]
Date: Wed, 08 Oct 2008 11:28:25 -0400

Hi Bill, 

JW Atwood writes: 

> While I know little about GSAKMP, I have been working (with Salekul Islam 
> and Maziar Siami) on the problem of PIM-SM authentication.  (See 
> with the OSPF authentication problem that it may be worthwhile to look at 
> a common solution.

I agree. Once you have the capability to distribute a shared secret to all 
routers within a security domain, you could use that secret to derive keys 
for multiple uses. 

> 
> The cleanest expression of the PIM-SM authentication problem that we have 
> been able to formulate is based on the idea that each speaking router is 
> the sender to a group that consists of all its one-hop neighbors.  Thus, 
> the key server for that group could be co-located with the sender, and 
> would be guaranteed to be reachable in one hop.  We recognized that this 
> key server could survive across re-boots (by having local stable storage), 
> but would need a "central" key server to permit it to learn about 
> (legitimate) new neighbors.

This synopsis easily maps onto the GSAKMP model wherein the authorized Group 
Members (i.e. in this case, the routers) can also be authorized to be GCKS. 
A Primary GCKS would originate the router group's secret keying material in 
a Re-Key Event (RKE) message. The RKE can also distribute the group policy 
token, which specifies the authorization rules for which systems are allowed 
to participate in what roles. Revisions in that policy are propagated on the 
same hop-by-hop path as the group key. 

> between PIM-SM and OSPF, and keyserver per speaking router), either on the 
> MSEC list, or face-to-face in Minneapolis.

Regretably, I won't be able to attend the Minneapolis meeting. At least for 
now, I would encourage using the MSEC list. 

At first glance, having a common intra-domain group security solution across 
OSPF, PIM, and IS-IS appears to be feasible, though the devil is in the 
details ;o) 

br, 

  George 

>> shared secret keying material to the one or more OSPF routers adjacent to 
>> it on the same layer-2 network. These adjacent routers would use a GSAKMP
>> link local scope reserved address, rather than doing a unicast exchange 
>> with a pre-configured central GCKS. This "expanding ring search " mode of
>> would select the KDL from the authenticated and authorized GCKS offering 
>> the most recent policy token.
>> 4) GSAKMP also has an option (RFC4535 appendix A) for the use of Logical 
>> Key Hierarchy (LKH) for rekeying the group.
>> three or four years that I'm aware of, and it sounds like it has ripened 
>> for some movement.  I would be willing to contribute to an Internet Draft 
>> that profiles GSAKMP usage for OSPF authentication. Unfortunately, I do 
>> not
>> I don't subscribe to the other lists, i.e. sidr, ospf, rpsec, tsvwg, etc. 
>> So if you think it relevant, please forward this e-mail on my behalf if 
>> you

---

From: [email-masked]
Date: Wed, 08 Oct 2008 11:28:25 -0400

Hi Bill, 

br, 

  George