Subject: Re: [MSEC] [secdir] [sidr] [RPSEC] Authentication for OSPFv3

From: Sam Hartman <[email-masked]>
Date: Tue, 30 Sep 2008 07:00:27 -0400

>>>>> "Vishwas" == Vishwas Manral <[email-masked]> writes:

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

Let me see if I understand this approach correctly.  I want to
interact with OSPF.  Somehow there is a group key that is in use on my
link.  In order to obtain this key, I exchange in an unauthenticated
BTNS-style exchange with someone, and as a result of that exchange,
obtain the key?

First, who do I perform this exchange with?  Anyone who currently holds the key?

Second, what threats does this protect against?

Finally, one of the things we typically desire from BTNS-style
protocols is a way to turn them into higher-infrastructure protocols when the infrastructure is available.  Can I do that with your approach?  How?

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 30 Sep 2008 07:00:27 -0400

---

From: David Ward <[email-masked]>
Date: Tue, 30 Sep 2008 09:57:58 -0500

Directions are to send your draft to opsec WG. To get it on their  
charter, you have to request the doc to become a WG item and then  
discussion will follow

-DWard

On Sep 29, 2008, at 8:53 PM, Vishwas Manral wrote:

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

rmat="flowed"; DelSp="yes"
Sender: [email-masked]
Errors-To: [email-masked]

Directions are to send your draft to opsec WG. To get it on their  
charter, you have to request the doc to become a WG item and then  
discussion will follow

-DWard

On Sep 29, 2008, at 8:53 PM, Vishwas Manral wrote:

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

---

From: Brian Weis <[email-masked]>
Date: Tue, 30 Sep 2008 09:14:41 -0700

On Sep 29, 2008, at 1:02 PM, Sandy Murphy 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.

I agree with Sandy.

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

There is an expired individual I-D that explores several options  
along these lines: <http://tools.ietf.org/html/draft-liu-ospfv3- 
automated-keying-req-01>. However, there isn't (in my opinion) an  
obvious way forward. We can allocate some time on the Minneapolis  
MSEC WG agenda on this topic if there's sufficient interest.

Brian

> 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 <[email-masked]>
> To: [email-masked], [email-masked], [email-masked], [email-masked],  
> [email-masked]
> Subject: [RPSEC] Authentication for OSPFv3
>
> I am not an active follower of these lists but have a question.   
> Please
> reply off-list directly to [email-masked] 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  [email-masked]
>
> RPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rpsec
>

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Brian Weis <[email-masked]>
Date: Tue, 30 Sep 2008 09:14:41 -0700

I agree with Sandy.

Brian