[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MSEC] Authentication for OSPFv3



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 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.

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.
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.

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

Bill Atwood
gmgietf at identaware.com 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: 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
MSEC at ietf.org
https://www.ietf.org/mailman/listinfo/msec

--
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: bill at cse.concordia.ca
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8


_______________________________________________
MSEC mailing list
MSEC at ietf.org
https://www.ietf.org/mailman/listinfo/msec