Subject: RE: Position statement on IKE development

From: "Horn, Mike" <[email-masked]>
Date: Mon, 6 Aug 2001 18:03:08 -0600

<content snipped for clarity>

> Specifically, we do have permission to go ahead with making interim
> modifications to IKE, which need badly fixing in the short term:
> specifically in the NAT/Firewall traversal and support for SCTP.  But
> all other changes are to be shunted to "son of IKE", and even there
> the focus is on making the protocol work, and be simpler and easier to
> understand/analyze, and not add the kitchen sink in terms of feature.

Can Marcus or Jeff confirm that this is true?  If it is true, would
NAT/Firewall traversal and SCTP support be amended to the existing IKE
framework, or would it be included in a simplified "improvements to IKE"
draft?  It seems the WG has the contradictory requirement to both simplify
and add new features to IKE concurrently.  It would be helpful if the IPSEC
WG produced a timeline and a plan for what the next steps should be.
 
> As far as user authentication and dead peer detection, part of the
> problem with those items is that there has *not* been consensus, and
> in fact there's been a fair amount of controversy, about what's the
> best way to handle these items.  People have sketched out solutions
> for user authentication that don't require changes to IKE, and that
> work is properly scoped to the IPSRA working group (and not "son of
> ike").

One of the reasons various user authentication schemes have not been
considered (CRACK for instance) is the moratorium on changes to IKE.
Unfortunately the IPSRA WG is very dependent on IKE.  If the IKE
specification had a secure, extensible mechanism for adding new features
like user authentication and keepalives, then the IPSRA WG would have
probably made more progress by now.
 
> Dead peer recovery probably will be within in the scope of "son of
> ike", but here again there has been controversy about how is the best
> way of solving the problem.  One advantage about "son of ike" allowing
> protocol changes (but likely requiring that the changes be
> "implementation preserving"), is that there may be more latitude to
> solve this particular proble right, instead of kludging around things.
> I will note that there have been many different proposed solutions to
> solving this particular problem, including polling/heartbeat
> mechanisms, authenticated birth/death certificates, etc.  
> 
> 							- Ted

Perhaps a new requirements draft needs to be started, so that Son of IKE
does not suffer the same fate as IKE.  IMHO, I think trying to make Son of
IKE "implementation preserving" is going to take Son of IKE down a very
familiar and ugly path.  Starting out with a new port assignment, and
building from the ground up might be the only answer.  There are obviously a
lot of lessons that have been learned the hard way which should serve to
greatly improve both the security and reduce the complexity of a next
generation key exchange protocol designed specifically for IPsec.

Mike Horn

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 06 Aug 2001 20:41:01 -0400

> Unfortunately the IPSRA WG is very dependent on IKE.  

The IPSRA WG is not at all dependant on IKE; it's really all about
protocols to turn legacy authentication into certificates..

					- Bill

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Aug 2001 06:37:59 -0700 (PDT)

> protocols to turn legacy authentication into certificates..

Unfortunately, in talking to customers, it is difficult to explain why
this makes sense. Some sample questions:

1. "Doesn't this require me to install root certs on all the clients, just
as if I were moving to PKI?"

2. "Doesn't this require me to install a CA, just as if I were moving to 
PKI?"

3. "Is my certificate infrastructure able to handle certs of such short
duration?"

4. "I've already deployed <insert token card here>. Why should I also need
to deploy certificate infrastructure?"

5. "Doesn't this assume that my IPsec implementation supports user
authentication?"

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 07 Aug 2001 09:23:12 -0700

Hi Bernard,

> as if I were moving to PKI?"

All clients are required to have root certs (or access to some
equivalent verification mechanism) if they are to use anything other
than preshared keys for phase 1 authentication anyway. Since preshared
keys will not securely scale, there really is no way around this, is
there?

> 3. "Is my certificate infrastructure able to handle certs of such short

The requirement, assuming very short-lived certs, is for a simple RA/CA
application which generates the certs, and for the gateway to have
access to a verification cert. In the best (most secure case), this "CA"
will likely be standalone, but in many cases, I'll bet this "CA" will be
transparently added to the security gateway itself. If the certs are
sufficiently short-lived (with a lifetime of, say, less than the width
of your typical CRL window), the sgw only needs to have a verification
cert, i.e. no additional verification infrastructure is needed. This can
be made quite simple from the customer's perspective.

> to deploy certificate infrastructure?"

See above...
 
> 5. "Doesn't this assume that my IPsec implementation supports user

I don't understand what you are asking here - we are providing a user
authentication mechanism for ipsec remote access here, right?

Scott

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Aug 2001 09:58:40 -0700 (PDT)

> keys will not securely scale, there really is no way around this, is

Customers who are not wishing to deploy PKI usually avoid it because of
the associated management issues. So requiring them to do many of the same
things as would have been required for PKI deployment generates
resistance. Most customers I talk to have the expectation that they can
deploy VPN scalably without any cert infrastructure at all, either with
password or token-card based authentication. 

> be made quite simple from the customer's perspective.

Yes, I'd agree that an integrated CA will be much easier for those
customers to live with. However, wouldn't they then need to do a
"forklift" upgrade to transition to full PKI? If so, there wouldn't be
much transition benefit. 

> > to deploy certificate infrastructure?"

In terms of market acceptance, token cards are considerably further along
than certificates. Many customers already have these token cards in place,
and expect to be able to use them without adding another layer of
infrastructure and configuration. 

> authentication mechanism for ipsec remote access here, right?

Presumably, the cert that is being given out is a user certificate -- and
therefore there is the expection that the IPsec implementation will
support user authentication -- which very few existing implementations do. 
Or are we authenticating a user identity -- but actually doing machine
authentication within IPsec?

---

From: Shane Amante <[email-masked]>
Date: Tue, 7 Aug 2001 12:49:05 -0600

On Mon, Aug 06, 2001 at 06:03:08PM -0600, Horn, Mike wrote:
[-- snip --]
> generation key exchange protocol designed specifically for IPsec.

Speaking from an operator's viewpoint, I have to agree with Mike and
other posters in support of jumping over 'son-of-IKE' and, instead,
launching a new initiative for a 'next-generation' IKE that is based
on a clearly defined set of *requirements* from the operator and
implementor community.  In fact, starting with *requirements draft*
BEFORE 'son-of-IKE' would be immensely helpful in gathering consensus
on whether it is even worth it to do 'son-of-IKE' or just jump over it
and start from scratch.  As a good friend and colleague says: "You've
got to define a target before you can aim at it; otherwise, you'll
never hit anything."  Right now, I have a hard time seeing how
painting some broad strokes of: a) simplify IKE; and, b) possibly add
these other arbitrary "enhancements" will lead to anything but
delaying the inevitable opening up the can-of-worms that is re-vamping
IKE from the ground up so it has extensibility and future-proofing.

The bottom-line is the current proposals on the table really only
addresses two thirds of the problems I see in the real-world today.
Specifically, 1) simplification of IKE; and, 2) NAT-traversal.  What
it doesn't address is: 3) remote-access/legacy-authentication issues,
which in all fairness, has been stated "will be worked on later" while
IPSRA is also valiantly attempting to come up with a solution today.
Ultimately, it boils down to the fact that, as an operator, I'd much
rather see a comprehensive solution developed that addresses all three
concerns than have to deploy 'son-of-IKE' and then, some time later,
either 'son-of-IKE++' or 'next-gen-IKE' that finally captures all of
my customer's needs.

Anyway, just my $0.02 ...

-shane

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 07 Aug 2001 14:00:21 -0700

Hi Bernard,

> password or token-card based authentication.

How will they scalably authenticate the headend server if they don't use
certificates?

> "forklift" upgrade to transition to full PKI? If so, there wouldn't be

Why would they need a "forklift"? Since the underlying ipsec
implementation has PKI capability in either case, only two changes would
be required:

1) User certs would be issued based on some other mechanism
2) The verification mechanism for the (new) user certs would require
more stringent management (which could actually be in place from the
start), since the certs presumably would not be so short-lived.

> infrastructure and configuration.

If the infrastructure were deployed in the manner I described in the
previous email, I think the infrastructure would be for the most part
transparent. For those who really can't stomach this, there's always
l2tp, right? And for those who really can't stomach l2tp, well...
there's always PIC :-)

> support user authentication -- which very few existing implementations do.

Any ipsec implementation that supports certificate-based identities has
the ability to authenticate a user, right? In fact, how could such an
implementation (on its own) differentiate between a user and a machine?
Isn't this a function of the larger system of irac, iras, private key
storage mechanism, enrollment mechanism, etc?

> authentication within IPsec?

I guess I don't understand the distinction you are trying to make here.
If I generate a certificate based upon user authentication (passphrase,
token card, what-have-you), and I take some precautions to limit the
exposure of the associated private key, then I think I'm authenticating
the user with private key and cert (to an extent which depends on a
number of factors, as discussed above). Please elaborate on what you
mean by this last sentence. 

Scott

---

From: Henry Spencer <[email-masked]>
Date: Tue, 7 Aug 2001 23:41:20 -0400 (EDT)

On Tue, 7 Aug 2001, Scott G. Kelly wrote:
> than preshared keys for phase 1 authentication anyway...

We haven't found it so.  Of course, we have to explain to people over and
over again that using RSA public keys does not imply using certificates.
(Do certificates scale better than plain public keys?  Yeah, probably...
but either one is so superior to preshared secrets that the difference is
second-order for most users, and public keys are much simpler.)

                                                          Henry Spencer
                                                       [email-masked]