IETF Logo Mail Archive

Re: Comments on CRACK

Ari Huttunen <Ari.Huttunen@datafellows.com> Wed, 27 October 1999 12:54 UTC

X-Persona: <a phoffman VPNC>
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA03228 for <paul.hoffman@vpnc.org>; Wed, 27 Oct 1999 05:54:00 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA03557 Wed, 27 Oct 1999 07:12:10 -0400 (EDT)
Message-ID: <3816DEC3.66115155@DataFellows.com>
Date: Wed, 27 Oct 1999 14:15:15 +0300
From: Ari Huttunen <Ari.Huttunen@datafellows.com>
Organization: Data Fellows Oyj
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vipul Gupta <Vipul.Gupta@Eng.Sun.Com>
CC: ipsec@lists.tislabs.com, ietf-ipsra@vpnc.org
Subject: Re: Comments on CRACK
References: <199910262024.NAA16410@ha1mpk-mail.eng.sun.com>
Content-Type: multipart/alternative; boundary="------------C22FAC014D7033AF2E54CACF"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
X-UIDL: 3fa766f1db41ed972f7e720c4614e29f

<x-html>
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Vipul Gupta wrote:
<blockquote TYPE=CITE>> In message &lt;3815F49E.BFABF7C9@cisco.com>, Roy
Pereira writes:
<br>>
<br>> >
<br>> > Let me ask everyone who is interested;&nbsp; How do we support
existing
<br>> > legacy user authentication within IKE without using a PKI ?
<br>>
<br>> With a protocol that lets the customer download an encrypted private
key/
<br>> certificate pair from a server, followed by ordinary IKE.
<br>>
<br>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
--Steve Bellovin
<br>>
<p>&nbsp; A perfect lead-in for what I've been thinking about for some
time
<br>&nbsp; now :-)
<p>&nbsp; How about using an HTML forms based interaction over HTTPS between
<br>&nbsp; a webserver and a user to accomplish what you state.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Intranet
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--> Legacy Auth
server
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SSL/TLS
protected&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
/
<br>&nbsp;&nbsp;&nbsp;&nbsp; user =================== HTTPS &lt;---+
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
server
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<p>&nbsp;&nbsp; This interaction can easily accomodate legacy user auth
mechanisms
<br>&nbsp;&nbsp; like SecureID, DES Gold, OTP, CHAP because the HTTPS server
has access
<br>&nbsp;&nbsp; to authentication tokens in the clear. Even multiple rounds
don't
<br>&nbsp;&nbsp; pose a problem. After the Auth server responds with "OK",
the
<br>&nbsp;&nbsp; HTTP server can squirt out a special MIME datatype and
the browser
<br>&nbsp;&nbsp; could be set up to automatically invoke the IKE daemon
(or companion
<br>&nbsp;&nbsp; software) to handle that MIME type. The HTTPS may need
to coordinate
<br>&nbsp;&nbsp; with the IPSec gateway on the Intranet side.
<p>&nbsp;&nbsp; This could be a reasonable solution for the road warrior
VPN scenario.
<br>&nbsp;&nbsp; I've heard Paul Hoffman use the term "user authentication
in Phase 0.5"
<br>&nbsp;&nbsp; for an approach like this (in contrast to Hybrid's Phase
1.5).
<p>&nbsp;&nbsp; (Maybe now's a good time to go look for that fire extingusher
:-)).
<p>&nbsp;&nbsp; vipul</blockquote>
That's not a bad idea in itself, although I'd rather not have the requirement
<br>to implement HTTPS just to be able to implement legacy authentication
<br>support in IKE!
<p>However, let me quote an earlier email that I sent:
<blockquote TYPE=CITE>
<pre>There's another architectural thing you should consider. What about modifying
the protocol so that when the server starts believing in the authenticity of the
client, the server issues the client's public key a certificate? This certificate
would have a very limited life-time, just enough for the purpose at hand.
It would be transported to the client in the 'last' message, whatever that is.

Although this creates more public key operations, the legacy authentication
functionality could be located on a different physical box than the actual
security gateway.. This achieves a very similar function to the Kerberos ticket
granting server, and the certificate is similar to Kerberos tickets. You'd of
course have to set up the trust relations appropriately.

There could also exist "one time certificates" that can be used only once
during their life-time to gain access, similar to one time passwords. Some
way or another they would be revoked the moment they are used.</pre>
</blockquote>

<p><br>If you wanted, you could transport such a certificate through HTTPS
to the client.
<br>Although, as said, I'd rather not have HTTPS in the picture.
<p>--
<br>Ari Huttunen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
phone: +358 9 859 900
<br>Senior Software Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fax&nbsp;
: +358 9 8599 0452
<p>Data Fellows Corporation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A HREF="http://www.DataFellows.com">http://www.DataFellows.com</A>
<p>F-Secure products: Integrated Solutions for Enterprise Security
<br>&nbsp;</html>

</x-html>
From ???@??? Wed Oct 27 07:36:25 1999
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA01081
	for <phoffman@IMC.ORG>; Wed, 27 Oct 1999 04:24:20 -0700 (PDT)
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA12786
	for ietf-123-outbound.10@ietf.org; Wed, 27 Oct 1999 07:25:02 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA12699
	for <all-ietf@loki.ietf.org>; Wed, 27 Oct 1999 07:15:50 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05225;
	Wed, 27 Oct 1999 07:15:51 -0400 (EDT)
Message-Id: <199910271115.HAA05225@ietf.org>
To: IETF-Announce: ;
Cc: ipsec@lists.tislabs.com
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: The Use of HMAC-RIPEMD-160-96 within ESP and AH to
         Proposed Standard
Reply-to: iesg@ietf.org
Date: Wed, 27 Oct 1999 07:15:51 -0400
Sender: scoya@cnri.reston.va.us
X-UIDL: f4af6fb3b817759323e6b2f27eb70a3b


The IESG has received a request from the IP Security Protocol Working
Group to consider The Use of HMAC-RIPEMD-160-96 within ESP and AH
<draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt> as a Proposed
Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by November 16, 1999.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-ripemd-160-96-04.txt

v2.23.0 | Report a Bug | By Email