Subject: RE: charter question re IKE changes

From: "Walker, Jesse" <[email-masked]>
Date: Wed, 11 Oct 2000 08:54:31 -0700

Steve:

"Most" is the operative word, because there has also been very extensive
discussion and repeated suggestions and pleas to replace Aggressive Mode
with Base Mode. This certainly sounds like an "add" as well as a "remove" to
me.

Be that as it may, to ellaborate on what I take to be John's point, one of
the spectres against which IPsec is fighting is, unlike the SSL community,
the IPsec community decided that everyone needs mutual authentication all
the time, 100% without exception, regardless of any and all other
considerations. My belief, for what it is worth, is experience now shows
that this was a genuinely bad decision, and the creation of IPSRA to solve
the legacy authentication problem simply confirms this. Real deployments
need strong one way authentication of an infrastructure or community to a
newly enrolling participant in order to bootstrap; requiring strong two way
authentication even during enrollment has created the deployment nightmare
that IPSRA has been chartered to fix. Both of the IPSRA proposals on the
table make use of this realization by essentially relying on one-way
authentication to get around the chicken and egg problem that exists at
deployment time. IPSRA words the problem much differently than I've
charaterized it here, but it is the same problem.

It seems to me that the PIC proposal in particular could easily be
incorporated into the larger IKE framework, obviate the need for this IPSRA
legacy authentication task, and result in a much more widely deployable and
usable IPsec.

Just my two cents.

-- Jesse

-----Original Message-----
From: Steven M. Bellovin [mailto:[email-masked]]
Sent: Wednesday, October 11, 2000 8:08 AM
To: Linn, John
Cc: [email-masked]'; [email-masked]'
Subject: Re: charter question re IKE changes 

In message
<[email-masked]>
, "Linn, John" writes:
>I'd like to ask a charter question which relates to both IPsec and IPSRA
>WGs.  IPSRA, based on IESG inputs, has been operating under the premise
that
>its work should not impact IKE's syntax or semantics if feasibly avoidable,
>with a strong preference to work instead alongside IKE as currently
defined.
>This premise has constrained the design space for candidate IPSRA
proposals.
>Recent discussion on IPsec has suggested significant changes to IKE,
>potentially removing or replacing authentication modes. Question: If IKE's
>definition is to be reopened within IPsec, should IPSRA's admissible design
>space continue to be constrained by RFC-2409?

Yes.

Most of the talk here has been about removing things, not adding more.  
IPSRA would need to add more.

		--Steve Bellovin

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Oct 2000 21:31:14 -0400

Jesse,

SSL was designed to address a fundamentally different set of 
communication security requirements, for a client/server model so it 
is not unreasonable that they made a different decision. However, the 
result is that most users are burdened with the need to remember and 
provide passwords for each public web site they log into via SSL, and 
if these passwords are poorly chosen, the use of encryption does not 
make it harder for an attacker to guess them and masquerade.

IPsec set higher standards for its peer-oriented authentication (not 
client server). the push back we see wrt PKI use in dialup 
environments is a result of many factors, some of which have been 
discussed recently on this list. certainly we know how to generate 
and distribte certs to users who already have entries in a Radius 
database.  but, what products can we buy that allow us to do this? 
so, my view is that the IPsec insistence for high quality, 2-way 
authentication is appropriate, but that implementations have not yet 
provided good enough PKI support to make it easy for folks to 
"embrace" the technology.

Steve

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 11 Oct 2000 20:28:48 -0700

At 9:31 PM -0400 10/11/00, Stephen Kent wrote:
>certainly we know how to generate and distribte certs to users who 
>already have entries in a Radius database.

Of course, if that was all we needed to do, our lives would be 
simpler and freer from suffering. However, it isn't. Implementations 
of PKI in the user environment have found that distributing the 
private keys associated with the public keys in the certs, and doing 
so in such a way that the user can use the certificate easily and 
flexibly, is the difficult problem. Note that "distributing" is even 
difficult when the private-public pair is generated on the user's own 
device because the private key has to be secured and yet be made 
available through applications that would need the user to sign 
things. We know the technology for doing this, but we have so far 
implemented it in very klunky fashions. Passwords that can be 
memorized by a user seem a lot more attractive to people who don't 
understand how utterly insecure they are (and even to some people who 
do).

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Oct 2000 12:51:45 -0400

Paul,

>difficult when the private-public pair is generated on the user's 
>own device because the private key has to be secured and yet be made 
>understand how utterly insecure they are (and even to some people 
>who do).

Your characterization of the problem does not match mine. We're 
working from different models:

	- yes, I would expect the user to generate a key pair on the 
machine in question, to avoid the problem of "distributing" a private 
key. smart cards would be better, and then we incur more costs, but 
folks who argue for use of SecurID cards must address the same sorts 
of costs of hardware acquisition and distribution. so, if we just 
compare passwords to key pairs, it seems quite reasonable to assume 
local generation of key pairs.

	- no, I would not make this key available to other 
applications, and thus would not have to address the second problem 
you cite. a key used to authenticate the user for IPsec need not be 
used for anything else. trying to impose a one-user one-key 
philosophy is asking fro trouble, from a security standpoint, and 
from an implementation perspective as well

Given this perspective, remind me again why knowledgeable folks 
prefer passwords, IF we provide them with good software for the 
initial certificate issuance process, working from an existing 
password database :-)

Steve

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 13 Oct 2000 07:35:20 -0700

>initial certificate issuance process, working from an existing 

Because we don't. I agree with your perspectives about how it *could* 
work, but that's not what is being delivered. Today's users make 
choices based on what is available to them today.

I also think the market disagrees with you about smart cards. Smart 
cards are only useful where there are smart card readers. They become 
an obstacle where there are no readers.

Again, I fully support the use of certs and wish that more users 
agreed with me. But they don't, and designing a protocol around a 
wish that has had plenty of time to come true but hasn't is a good 
way to design yet another protocol that won't get implemented.

--Paul Hoffman, Director
--VPN Consortium

---

From: Derek Atkins <[email-masked]>
Date: 13 Oct 2000 11:19:06 -0400

FWIW, I have been working on a Web-based CA that allows a user to
obtain a certificate based upon an existing username/password.  It's
currently setup for web-client certificates (netscape/msie/lynx) but
it could be extended to others as well.

As Steve said, it's not difficult to create such a beast.  However
Paul is right in that nobody has, as of yet, delivered one.

FWIW, at MIT I've setup an IPSec-based tunnel server that uses
HTTPS+Certificates for secure administration.  A user generates their
RSA key and then submits it via SSL for entry into the IPSec database.
They have to use their certs obtained as above.  There ya go!
Automated "password" sharing of RSA keys based upon existing
username/password entries :)

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
       [email-masked]                        PGP key available

---

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Oct 2000 12:03:48 -0400

Paul,

I think there is confusion about the context in which I made the 
initial statement.  I agree that what is provided today falls short 
of what could/should be done. I call your attention to the two 
sentences at the end of the message that I sent and which 
precipitated this discussion:

>but, what products can we buy that allow us to do this? so, my view 
>is that the IPsec insistence for high quality, 2-way authentication 
>is appropriate, but that implementations have not yet provided good 
>enough PKI support to make it easy for folks to "embrace" the 
>technology.

Steve

---

From: Dan Harkins <[email-masked]>
Date: Fri, 13 Oct 2000 09:35:29 -0700

The lack of people implementing good products should not be a
motivating factor in developing standards. If we all agree on
how it *could* work then let's promote that.

  I think the market will follow a good solution. I used to love
teco until someone showed me vi and that love affair lasted
until someone showed me emacs.

  Dan.

On Fri, 13 Oct 2000 07:35:20 PDT you wrote

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Fri, 13 Oct 2000 14:31:51 -0400

Hey guys,

Do you think we could cut down on the cross-posting. I think everyone on
ipsra is probably on ipsec as well.

Thanks,
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Dan Harkins
> Sent: Friday, October 13, 2000 12:35 PM
> To: Paul Hoffman / VPNC
> Cc: Stephen Kent; [email-masked]; [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 13 Oct 2000 16:35:30 -0400

>until someone showed me emacs.

I am in complete agreement with Dan.

Steve

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 13 Oct 2000 22:38:54 -0700

>Paul is right in that nobody has, as of yet, delivered one.

Actually, we shipped such a thing in Windows 2000. Check out
http://servname/certsvr on a machine running certificate server.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 13 Oct 2000 22:38:38 -0700

>way to design yet another protocol that won't get implemented.

I think that's a bit hyperbolic. We actually have substantial
deployment of *machine* certificates today. Where we are having
trouble is in deployment of user certificates. A data point
worth considering is that most customers I know of looking at
deploying user certs are also looking at deploying public key 
smartcards. It's this linkage which is causing us the problem. 

What has generally kept them from actually rolling
out the deployment is the state of the reader hardware which
is still in its infancy. I think that 18 months ago I made
the prediction that we'd have reliable PCMCIA readers for 
$100 by now. Boy do I have egg on my face for that one. 

The question is whether the linkage between user cert 
deployment and smartcards is just an artifact of the
philosophy of the early adopters or whether this is
something that will quickly give way as more mainstream
institutions (universities?) deploy temporary certs.