Subject: [RPSEC] 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] 

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

---

From: David Ward <[email-masked]>
Date: Tue, 30 Sep 2008 10:44:39 -0500

Reducing the list a bit ... You now need to ask the WG chairs if  
there was consensus to accept the doc.

-DWard

On Sep 30, 2008, at 10:42 AM, Vishwas Manral wrote:

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

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 1 Oct 2008 06:49:24 +0530

Hi Sandy,

The idea is that I am trying to state is the use of authentication at
2 levels (in BTNS they skip the authentication at the IKE exchange
altogather - and do it at a different layer if possible). At the first
level we use GTSM as the first filter for IKE itself and once the
system adjacencies are up we actually can use the full authentication/
any other form of authentication (so that reachability information is
there).

By doing this we may trust a peer entity but only for sometime, when
the adjacencies come up we have the option of doing a full
authentication. Regarding the issues with the way things work
currently (which will be mitigated) you can always look at the draft I
have written.

Thanks,
Vishwas

On 9/30/08, Sandy Murphy <[email-masked]> wrote:
>>I agree to what you say and the general sense of the room in the KMART BOF.
> 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
>