Subject: Re: [Ipsec] FW: I-D ACTION:draft-friedman-ike-short-term-certs-00.txt

From: Nicolas Williams <[email-masked]>
Date: Sun, 3 Dec 2006 23:13:07 -0600

On Wed, Nov 29, 2006 at 07:16:29PM +0200, Arik Friedman wrote:
>    This document describes an extension to IKEv2 that allows an endpoint
>    to prove to a security gateway that it was already authenticated by
>    another trusted security gateway, thereby allowing the authentication
>    of the endpoint without user intervention.  This is accomplished
>    using a Short Term Credential that the endpoint requests from the
>    authenticating security gateway.  This credential is a certificate
>    issued by the authenticating gateway for a short period of time, and
>    it can be used to authenticate the user with IKE signature based
>    authentication.

Sounds like a ticketing system.

Sounds like Kerberos V (with PKINIT).

Sounds fairly unrelated to IKEv2 and rather specific to PKIX.

Nico
-- 

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Ariel Shaqed (Scolnicov)" <[email-masked]>
Date: Mon, 4 Dec 2006 12:17:10 +0200

I see our introduction needs more work!

> Sounds like a ticketing system.

True.

However, more VPN gateways and clients are PKI-capable than are
Kerberos-capable.  We aim to use PKI capabilities of the client,
without requiring the administrator to deploy PKI to clients.

> Sounds like Kerberos V (with PKINIT).

We are after a lighter weight solution than Kerberos.  (RFC 4556 uses
client certs to produce Kerberos authentication, we use IKE EAP
authentication to produce a client cert).

Obviously Kerberos authentication (or PKI authentication) for clients
could solve re-authentication issues.  So-called "legacy"
authentication is a fact of life.  Kerberos (and PKI deployment for
client certs) are less so.

> Sounds fairly unrelated to IKEv2 and rather specific to PKIX.

PKIX specifies certificate infrastructures which we use -- we do not
rewrite RFC 3280, we use it.

Our draft defines an IKEv2 exchange allowing a client to request
short-term credentials, and specifies behaviour for such an exchange.
It provides a re-authentication mechanism that requires fewer new
entities than would using Kerberos (or yet another EAP method).

We have to make these points clearer in -01.

Thanks,
-- 
Ariel.