Subject: [Tsvwg] Authentication for OSPFv3

From: Ed Jankiewicz <[email-masked]>
Date: Tue, 23 Sep 2008 17:52:07 -0400

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]

---

From: [email-masked] (Sandy Murphy)
Date: Mon, 29 Sep 2008 16:02:31 -0400 (EDT)

>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 <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [RPSEC] Authentication for OSPFv3

Thanks.

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

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 30 Sep 2008 07:23:24 +0530

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 <[email-masked]> wrote:
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

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?

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 30 Sep 2008 17:08:08 +0530

Hi Sam,

Thanks for the queries. First off the draft is located at

http://tools.ietf.org/html/draft-manral-rpsec-existing-crypto-05 and
details issues in security even after the current set of security
mechanisms are in place. Some issues are well known in the security
community like trying to discourage the use of MD5 and instead use
HMAC-SHA1 and HMAC-MD5. We have already got drafts for the same to
support them in OSPF and ISIS.

The issue we have here is the requirement in IPsec of the deployment
of authentication identities and credentials and having a
authenticating infrastructure (trusted third-party) reachable even
before any of the routes are learned.

What I was proposing was to instead start off using IPsec in BTNS mode
(with say a GTSM check for IKE packets as the authentication mechanism
for IKE packets - and no 3rd aprty authentication) and learn routes.
Once this happens an optional second level of stronger authentication
can be done as all routes are now available (if it is so desired).

So we get the complete IPsec security - except for the fact that we
rely on TTL mechanisms for the IKE at the beginning.

Do let me know what you think about the idea?

Thanks,
Vishwas

On 9/30/08, Sam Hartman <[email-masked]> wrote:
> protocols is a way to turn them into higher-infrastructure protocols when
> the infrastructure is available.  Can I do that with your approach?  How?
>
>

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 30 Sep 2008 21:12:18 +0530

Hi Acee,

I agree to what you say and the general sense of the room in the KMART BOF.
That is the reason I proposed a BTNS based solution. Which uses GTSM
in the IKe to do the first level security.

Also as IGP run within an administrative domain we can actually do
without third party verification.

Hi Dave,

Thanks for your help and shepherding as always.

The issue about adopting the draft was raised in the OPSEC WG by the
chair Joel, however we only had a handful of mails saying the draft
was within the scope (though none were opposed to it).

Thanks,
Vishwas

On 9/30/08, Acee Lindem <[email-masked]> wrote:
> One thing to take into consideration is that the outcome of our KMART
> BOF was that nobody deploying networks wanted routing infra-structure
> based on a third-part verified certificates.
> Thanks,
> Acee
> On Sep 30, 2008, at 10:57 AM, David Ward wrote:
>
>> 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,
>>>
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>
>

---

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:

> participant, mind you) think the answer lies.

I agree with Sandy.

> Both GDOI (RFC 3547) and

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

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

---

From: [email-masked] (Sandy Murphy)
Date: Tue, 30 Sep 2008 12:28:23 -0400 (EDT)

>in the IKe to do the first level security.

I am not quite sure I understand the use of GTSM here.  The need for
authentication for OSPF is that you don't trust that everyone on the
local broadcast link is OK.  GTSM tells you that the sender came from
one-hop away, i.e., on the local broadcast link.  Since you already know
that you don't trust everyone one-hop away, how does the use of GTSM
help?

--Sandy

---

From: [email-masked] (Sandy Murphy)
Date: Tue, 30 Sep 2008 12:36:04 -0400 (EDT)

By the way, to everyone who sees this message, the mail chain is really
broken.  Ed's message did not get to all the wg lists on his message,
and I got several "too many recipients" errors on my reply.  If you look
at the mail archives for the various wg, not any of them have caught all
the messages that have been send.

I think the secdir archive got most of the messages (except the one that
Dave Ward cut down to just the rpsec list :-)), but it is not a public
list.

I'm not even sure that Ed, who originally posed the question, is seeing
the exchange.  (Ed's message was attached to my reply, if you saw that.)

I was able to push out the messages that got trapped for the sidr list,
but if any other wg chairs could do their bit, maybe the conversation
will be less fractured.

Or maybe we should just all choose one list to do the conversation.

--Sandy

---

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

-DWard

---

From: Acee Lindem <[email-masked]>
Date: Tue, 30 Sep 2008 11:08:15 -0400