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