Subject: Re: Securing Neighbor Discovery BOF

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 09 Jun 2002 10:11:17 -0400

In message <003601c20f81$2be0b620$1e6015ac@T23KEMPF>, "James Kempf" writes:
>> IP Security, for one. The current IPsec can be used, though
>> it's pretty cumbersome due to (a) large number of similar SAs
>> needed for manual keying due to destination address being a
>> part of SA lookup and (b) chicken-and-egg problem for IKE.
>> The problem (a) could be solved, and the result would be a
>> more easily usable IPsec for securing large private networks.
>> For public networks manual keying does not scale, however.
>> Perhaps something can be done for (b). For instance, one
>> possible, even if ugly, solution is to provide an ND-level
>> message to carry IKE-like traffic between the ND
>> peers until an IPsec SA can be established. Contributions
>> on this space are sought -- feel free to jump in here ;-)
>>
>
>Key distribution could be done via Layer 2 AAA or using the roaming
>consortia idea we had in the ABK draft. However, I think that might
>require some change in IPsec policy, because I believe the policy only
>allows IKE or manual keying for key distribution.

That's not correct.  In fact, there's another working group, KINK, 
whose goal is Kerberos key management for IPsec.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Jun 2002 11:51:43 -0700

Hi Steve,

> whose goal is Kerberos key management for IPsec.

Thanx for the correction.

So is it the case then that there would be no change in IPsec policy
required for doing AAA-based or roaming consortia-based key management?
Is so, then perhaps this problem is fairly straightforward to solve.

            jak

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Jun 2002 19:36:35 -0700 (PDT)

> Is so, then perhaps this problem is fairly straightforward to solve.

   Which working group has this in their charter?

		 Mike

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Jun 2002 09:05:49 -0700

None that I know of. I didn't mean to suggest that this should be a
chartered item, that is for the BOF to decide. Any solution to IPsec key
distribution that does not involve IKE (due to chicken and egg problem)
or manual keying (due to inconvenience for large scale public access
networks) should be on the table at this point, in addition to other
techniques, such as CGAs.

            jak

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Steven M. Bellovin" <[email-masked]>; "Jari Arkko"
<[email-masked]>; "Pekka Savola" <[email-masked]>;
<[email-masked]>
Sent: Monday, June 10, 2002 7:36 PM
Subject: Re: Securing Neighbor Discovery BOF

---

From: "James Kempf" <[email-masked]>
Date: Mon, 10 Jun 2002 11:51:43 -0700

Hi Steve,

            jak

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 13 Jun 2002 13:46:17 -0400

> required for doing AAA-based or roaming consortia-based key

"policy" could mean a lot of things.  

the overall architecture does not require change.  the idea that there
can be more than one way to manage keys is part of it; it's also part
of many implementations.

The policy model will likely need to be extended to add new selectors
(for icmpv6 type/code) because ND "hides" inside icmpv6, but that's an
obvious and (based on previous times when it's been brought up in the
ipsec working group) apparently noncontroversial extension akin to the
existing port-based selectors.

						- Bill