Subject: Starting the decision on PIC vs. GetCert

From: Sara Bitan <[email-masked]>
Date: Sun, 04 Feb 2001 10:45:25 +0200

Hello all!

We would like to choose one candidate between PIC and GetCert, and to have
progress with the chosen one.
We will have a short (two weeks) discussion on the list, followed by
a straw poll.

Here is a general summary that I hope will help us start the discussion.

These are the general requirements PIC and GetCert were devised to answer:

(From draft-ietf-ipsra-reqmts-03.txt)
  " In general, proposed IPsec remote access mechanisms should meet the
   following goals:
     o should provide direct support for legacy user authentication
       systems such as RADIUS
     o should encourage migration from existing low-entropy
       password-based systems to more secure authentication systems
     o if legacy support cannot be provided without some sort of
       migration, the impact of such migration should be minimized
     o user authentication information must be protected against
       eavesdropping and replay (including the user identity)
     o single sign-on capability should be provided in configurations
       employing load-balancing and/or redundancy
     o n-factor authentication mechanisms should be supported"

Both PIC and GetCert answer the first five requirements. As noted in a recent
discussion on the list, PIC can be modified to answer the last requirement.
Both provide server side authenticated secure transport for the user
authentication data, and for certificate enrollment.
GetCert is using SSL/TLS as a secure transport, while PIC is using ISAKMP as a
secure transport, created by server authenticated DH.
(Hugo in an e-mail to the list, noted that PIC can be extended to create
mutually authenticated transport)
GetCert uses HTTP as the legacy authentication transport, while PIC is using
EAP.
GetCert uses SCEP for certificate enrollment, while PIC is using dedicated
CREDENTIAL-REQUEST and CREDENTIAL payloads.

I urge you all to please read the two drafts, and share your opinion with the
list. Please speak soon, so we can get as much discussion 
as possible before we start the straw poll.

 Thanks, Sara

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 05 Feb 2001 09:48:27 -0500

>CREDENTIAL-REQUEST and CREDENTIAL payloads.

It would be easy for me to change GETCERT to use CMP and CMP Transport over 
HTTP making it fully compliant with PKIX standards, just not following the 
Appendix B ir senario.

It woudl be harder to do it with CMC.  Principle reason is CMC does not 
call out a transport.  If they were to adapt the CMP Transport, I could 
most likely make that work too.

Now due to work requirements I am swamped until Feb 12th.  Any rewrites 
would occur after that.  But give it serious consideration.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 5 Feb 2001 09:17:24 -0800

>HTTP making it fully compliant with PKIX standards, just not following the

Personally, I think this would be a good idea -- especially if EAP support
could be added as well. This would require protection of the EAP
conversation.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 05 Feb 2001 12:36:10 -0500

>could be added as well. This would require protection of the EAP

this is a cert request, and CMP and CMC have the data structures for 
requesting certs.  Does EAP?

Robert Moskowitz
ICSA

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 5 Feb 2001 10:54:48 -0800

>requesting certs.  Does EAP?

No. It's just a multi-round trip authentication "wrapper" (see
RFC 2284 for details). So you can only use EAP for verifying the
identity, but not for the cert request itself. However, since 
EAP doesn't provide a protected negotiation (unlike IKE or 
GSS_API SPNEGO), the EAP conversation should occur over a 
secure channel.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 05 Feb 2001 14:36:28 -0500

>GSS_API SPNEGO), the EAP conversation should occur over a

oh, yes.  remeMber the discussion.  perhaps you will help me with that part 
of GETCERT  :)

Robert Moskowitz
ICSA

---

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 06 Feb 2001 13:24:45 -0800

I haven't come down one way or the other yet, but have made the
following observations: if pic is chosen, the fact that it would be part
of the ipsec subsystem makes the problem of getting the cert into the
ipsec credential db transparent to the user. If getcert is used with a
browser interface, this is not the case (although I know getcert could
be implemented by the ipsec client code as well). Also, getcert may be
susceptible to any associated tls security issues. Comments, anyone?

Scott

---

From: Ari Huttunen <[email-masked]>
Date: Sun, 11 Feb 2001 14:18:31 +0200

> susceptible to any associated tls security issues. Comments, anyone?

If the solution is too tightly bound to the IKE implementation, deployment
of the solution will require that all IKE implementations used by the corporation
be changed. On the other hand, a separate client product pushing a cert to an 
OS cert store and a separate authentication server would be more easily deployable.

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

---

From: Ari Huttunen <[email-masked]>
Date: Sun, 11 Feb 2001 14:07:33 +0200

I like the ability mentioned in PIC to locate the Authentication Server
and the GW in different locations, in an attempt to provide resistance
to DoS attacks against the GW. This capability should also be possible
in Getcert.

As I see DoS resistance useful even when legacy authentication as such
is not the primary issue, I also like the ability to do N-factor authentication.
In such a scenario, the chosen protocol could be deployed to provide DoS
resistance to GW even though all the certs etc. would be available to connect
the client to the GW via standard IKE. 

I don't believe using preshared keying, with a PSK given by the AS to connect
to the GW is such a good idea. There will likely be more management problems
created with this, in particular for the AS<->GW connection, than the benefit
obtained by the reduced amount of work per connection that the GW must do.
Instead of AS giving a PSK to client, this situation should be solved by
creating a more DoS resistant IKE mode (base mode) or by using Kerberos and
the method to be developed by KINK to connect to the GW. Naturally these
issues are not relevant for this WG, but might have some relevance as to which
candidate is chosen.

I would also like to see it possible for the AS to provide the client
a "policy blob". The contents of this "policy blob" would not be defined by
this WG, but possibly by IPSP WG. This would make it possible for the client
to be just configured to contact the AS. The AS would then tell the client
as to what actual GW the client should contact, maybe based on knowledge of
which GWs have least load at that point, achieving load-balancing. (Besides, the
reality will be that this is implemented as vendor specific methods, even
though not specified. So why not specify it from the start?)

I understand that these issues are not at the core of what's needed, but both
candidates seem to provide for the core needs anyway. So, I would like to cast 
my vote on the candidate that has more future potential. When legacy authentication
is being solved satisfactorily at some future point, the chosen candidate would
still have some reason for existance.

Ari

---

From: "Scott G. Kelly" <[email-masked]>
Date: Mon, 12 Feb 2001 08:53:45 -0800

Hi Ari,

Comments below...

> OS cert store and a separate authentication server would be more easily deployable.

The fact that pic uses an ike variant doesn't mean it is tightly bound
to the ike implementation, necessarily. For example, a pic
implementation need not run on the headend, meaning that ike
implementation would not change at all. Where it *would* require
widespread change would be in the remote access clients, but these
systems have to be modified either way.

Scott

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 12 Feb 2001 14:40:53 -0500

>to DoS attacks against the GW. This capability should also be possible

It is an I don't see any reason to call it out.  But if you people want 
pictures, I will make 'em.

I fact there is probably the need to call out that the AS, GW, and RADIUS 
are just one box for the 'small office' senario  :)

>a "policy blob".

two ways to handle that.  as part of the EAP exchange or as part of the CMP ip.

when do you think it should occur (as part of authentication of client to 
AS or as part of receving cert).

Robert Moskowitz
ICSA

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 12 Feb 2001 23:06:15 -0800

>AS or as part of receving cert).

My opinion: as part of receiving the cert. EAP authentication methods such
as SecurID are already specified and thus cannot be changed so as to push
policies. So this needs to be done outside of the EAP authentication
process.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 13 Feb 2001 14:57:09 +0200

> systems have to be modified either way.

I think that in almost all implementations of the PIC are going to be
very tightly bound to the IKE implementation itself (i.e sharing code,
runnig same state machine etc). Of course there will be lots of IKE
implementations which do not include PIC at all, and those will still
be same...

Adding PIC there WILL add complexity of the IKE. I think we have to
just realize that. The added complexity is propably not going to be
too much.

Getcert can be implemented as a part of IKE or as a separate system. I
think quite a lot of the implementations are going to use the second
alternative, i.e build separate piece of code to run the getcert
protocol, thus keeping the complexity out of the core IKE/IPsec
system.
-- 
[email-masked]                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 13 Feb 2001 15:17:41 -0500

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: "Yaron Sheffer" <[email-masked]>
Date: Wed, 14 Feb 2001 10:31:04 +0200

A third alternative is to push policy separately (neither from the legacy AS
nor from the CA). The policy "blob" would be wrapped as another MIME in
getcert, or another ISAKMP payload in PIC.

	Yaron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Bernard Aboba
Sent: Tuesday, February 13, 2001 9:06 AM
To: Robert Moskowitz; Ari Huttunen; Sara Bitan
Cc: IPSRA list; Paul Hoffman
Subject: RE: Starting the decision on PIC vs. GetCert

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 14 Feb 2001 19:32:24 +0200 (IST)

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

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Thu, 15 Feb 2001 18:48:31 -0500

I think the problem (and advantage) of SSL is that you can leverage off of
an existing global PKI.

However, I also feel that IKE will be used in scenarios where administrators
want to have complete administrative control over their PKIs, which negates
this supposed advantage.

I also believe that the decision to use SSL rather than staying within the
realm of ISAKMP was motivated by a belief that SSL is inherently more secure
than IKE. This is something I don't believe to be true.

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.

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

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 16 Feb 2001 15:30:09 -0500

>want to have complete administrative control over their PKIs, which negates

noppers.  at least not in my working on GETCERT.

for argument purposes, you work at a BIG company (like I did for 19 
years).  You buy an Entrust license for the server and you get their RA 
toolkit.

you put the toolkit on a box that also has IIS (remember this is for 
example purposes ONLY :).

you roll your own root cert for your CA and an SSL cert for your IIS.  On 
all of your remote clients you install this root cert (I could get more 
complicated in my example with a whole corporate PKI but why bother for 
this example).

you write a CGI piece that grabs the ir and passes it to the CA with the 
proper cert template.  The CA hands you back an ip that you toss back to 
the remote client.

it works.

now along comes the open source code bunch, and they grab OPENSSL and 
Gutman's open CA stuff and wrap it all with an open RADIUS and Apache  :)

you see here comes the way you can cheat with the open code.  you get your 
'commercial' SSL cert, but you do not use it as your SSL cert, rather you 
use it as your CA's root cert and create all of yoru remote certs off of 
it.  yeah it is a flagrant violation of X.509, but this way you might 
already have the root cert in your clients  :)

just the ramblings at the end of the week.  I will start on the next 
release of GETCERT.  I've a mar 2 publication deadline, but I am going to 
beat that...

>than IKE. This is something I don't believe to be true.

not in my case.  perhaps more understood?  but not even that.  SSL secures 
a TCP data flow, with the nature of the flow open to the 
application.  remote access configuration will change with time.  to lock 
it into a set of ISAKMP payloads may well be limiting.

Robert Moskowitz
ICSA