Re: [RPSEC] [sidr] Authentication for OSPFv3

Hi Sandy,

Thanks for refering to my draft in your mail. The same was presented
by Dave (Ward) in the last IETF. Regarding the state of the draft,
because the RPSEC is closing down, we have been trying to find a home
for the draft.

We can also solve the problem similarly by something like
BTNS(ofcourse Multicast part needs to be thought further) which does
not necessarily require any certificate verification - so we may have
unauthenticated IKE SA's but then all keys for the CHILD_SA from there
are automatically generated.

Thanks,
Vishwas

On 9/30/08, Sandy Murphy <sandy@tislabs.com> wrote:
>>What (if any) current initiatives are there that would support automated
>>key exchange for OSFPv3 authentication?
>
> You have msec on the list of recipients, which is where I (not an active
> participant, mind you) think the answer lies.  Both GDOI (RFC 3547) and
> GSAKMP (RFC 4535) are group key management protocols, which is what
> OSPFv3 needs.  Unfortunately, both assume the existence of a group
> controller that plays an important role in distributing keys.  In other
> words, the very democratic all-are-equal many-to-many model of OSPF might
> find it
> difficult to map to the envisioned group security architecture.  I
> suppose it might be possible to consider the Designated Router as the
> group controller, but as the DR is elected, that might be a difficult fit.
>
> Even if you solve the group key management problem for OSPFv3, you still
> have the difficulty to doing anti-replay in a multicast environment.
> Manral presented a draft some years ago to the rpsec working group about
> the crypto vulnerabilities of routing protocols, and concentrated for
> OSPFv3 on replay vulnerabilities.  Unfortunately, that did not go anywhere.
>
> Just for fun, I'm adding the routing area ADs and the secdir on this list.
> This is one of those cross-disciplinary concerns that has the right people
> in several different wgs and areas.  The more the merrier, right?
>
> The one quibble I have is that the tsvwg probably has little to do with this
> problem - the transport for OSPFv3 is IP, not TCP, and IP is not the level
> of stuff their charter looks at.
>
> (And sorry for the late reply to your messages, I've been mulling the
> options.)
>
> --Sandy
>
> ---------  In reply to ------------------------
>
> Date: Tue, 23 Sep 2008 17:52:07 -0400
> From: Ed Jankiewicz <edward.jankiewicz@sri.com>
> To: ospf@ietf.org, rpsec@ietf.org, sidr@ietf.org, msec@ietf.org,
> tsvwg@ietf.org
> Subject: [RPSEC] Authentication for OSPFv3
>
> I am not an active follower of these lists but have a question.  Please
> reply off-list directly to ed.jankiewicz@sri.com or copy me if this
> triggers relevant discussion on your list.
>
> What (if any) current initiatives are there that would support automated
> key exchange for OSFPv3 authentication?  RFC 4552 relies upon pre-shared
> secret keys for generating message digest, but some of my constituents
> have issues with manual generation, distribution and configuration of
> keys in their IPv6 network deployment.  Is any of the current work on
> IKE revisions applicable, any work being done in your working group, or
> do you know of any OSPF-specific solution being developed somewhere?
>
> Thanks.
>
> --
> Ed Jankiewicz - SRI International
> Fort Monmouth Branch Office - IPv6 Research
> Supporting DISA Standards Engineering Branch
> 732-389-1003 or  ed.jankiewicz@sri.com
>
> _______________________________________________
> RPSEC mailing list
> RPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/rpsec
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/rpsec