Subject: RE: Starting the decision on PIC vs. GetCert

From: "Kavsan, Bronislav" <[email-masked]>
Date: Wed, 14 Feb 2001 13:03:23 -0500

I wouldn't limit the scope of either of those proposals to pre-IKE only
(name PIC is somewhat unfortunate), but rather look at it as more general
mechanism for secure distribution of mobile credentials to users, where IKE
is only one possible use.

-----Original Message-----
From: Hugo Krawczyk [mailto:[email-masked]]
Sent: Wednesday, February 14, 2001 12:32 PM
To: Bill Sommerfeld
Cc: IPSRA list
Subject: Re: Starting the decision on PIC vs. GetCert 

I do not see why an SSL-based solution is more modular.
What SSL gives you is (assuming you have SSL running in your 
authentication server) a somewhat faster-to-deploy solution.

I'd say that if one thinks of the problem at hand as something 
that will go away in a year or two at most then a fast SSL-based
solution is best.

If one thinks this functionality (certiifcate retrieval using passwords
and legacy systems) is here to stay for long then PIC is a better
solution from the point of view of security architecture.
It stays in the realm of IKE (to which it serves by definition); and
you can control its implementation, management and level of security
(rather than SSL that will be used "as is" and its "is" is not that good
these days).

From an architectural point of view what getcert does in comparison
to PIC is to replace the first two message of PIC with a whole SSL
hanshake.

Also, an IKE-like solution could in the future (when IKE gets stabilized
and deployed) be added, if so desired, as a direct-authentication IKE
mode.

Hugo

On Tue, 13 Feb 2001, Bill Sommerfeld wrote:

> getcert looks like the right approach from a modularity standpoint.
> 
> It also *potentially* fits in better than PIC with the way my employer
> currently does remote access.  (I'd guess that this applies to other
> organizations as well).
> 
> 					- Bill
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 14 Feb 2001 10:20:15 -0800

Hi Slava,

> is only one possible use.

I think "mobile credentials" are out of scope, and fall within the
purvey of the sacred wg. I think what we are trying to do here is
provide a mechanism for the use of legacy authentication for ipsec
remote access in a more secure manner than those previously proposed
would.

Scott

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Wed, 14 Feb 2001 16:37:16 -0500

<flamebait>

Andrew
-------------------------------------------
Upon closer inspection, I saw that the line 
dividing black from white was in fact a shade
of grey. As I drew nearer still, the grey area
grew larger. And then I was enlightened.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Scott G. Kelly
> Sent: Wednesday, February 14, 2001 1:20 PM
> To: Kavsan, Bronislav
> Cc: 'Hugo Krawczyk'; Bill Sommerfeld; IPSRA list

---

From: Ari Huttunen <[email-masked]>
Date: Thu, 15 Feb 2001 17:27:53 +0200

> remote access in a more secure manner than those previously proposed

I visited the sacred BOF, and I seem to remember that their methods depend on
there existing long term credentials for the client, which the client
could somehow verify after obtaining from the server. This in turn created
better two-way authentication properties than could be employed by IPSRA that
needs to create the client credentials on-the-fly. (Like, they don't depend 
on the user verifying the server certificate as with SSL.)

Someone who knows sacred better could shed more light on this. But in any case
there does seem to be enough reasons for both methods to exist. And no, the IPSRA
method doesn't have to be IKE-only, although it likely will be.

Ari

-- 
Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security