[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on "Hybrid Auth. mode for IKE"

Kai Martius wrote:
> 
> Moshe,
> 
> just another opinion to the "hybrid authentication draft".
> 
> First some general thoughts:
> 
> There's no doubt to need good migration paths from "80's technology"
> to new one but I have some concerns doing it the way your I-D
> proposes:

Let's face it, the legacy tokens are not 80's technology, they are 90's
technology. How many such tokens where sold in the 80's? How many where
sold in the first half 98?

> 
> 1. In general, I believe, providing too much of backward
> compatibility would probably delay the implementation of more
> secure authentication mechanisms, especially certificate based auth.
> including a global PKI. IKE could be a good catalyst deploying
> stronger auth. schemes. And it already provides a good migration
> path by its pre-shared key mode (PSK) where NO PKI is needed. So the
> compatibitility to older systems should build on this mode.

pre-shared key for user authentication is very week. Are you saying that
you agree to have a week authentication but that the hybrid is strong
enough to delay the use of PK smart cards? 
I will take it as a compliment :-)

Currently we can give our customers remote access using IPSEC, and we
can give them remote access using their legacy hardware tokens for
authentication. But we can't offer them both. I want to change this.

> (All
> token systems I know are based on symmetric crypto - like PSK mode.
> At least for S/KEY I could imagine it's very easy to use it in a kind
> of "one-time-PSK" mode).

How would you do it with S/KEY? I can't see how it can be done.



> 
> 2. The discussion on more or less databases to manage I don't
> understand - basically there is _one_ importent database which
> assigns certain rights to a USER. With cert-based auth. you have less
> databases, because there is already an authenticated user name - with
> any symmetric token system you need to assign the users to the token
> first.

The more than one data base issue is related to a separate
authentication of machine and user, as in XAUTH.

> 
> 3. A basic IKE-design principle is the 2-phase-approach of
> authenticating the IKE instances in a first phase and in the second
> phase to exchange keys for clients. Comparing XAUTH and hybrid mode,
> XAUTH keeps the 2-phase-separation cleaner, I think.

The IKE designe principle is 2-phase one phase of authentication and one
phase to exchange keys. XAUTH breaks it by providing 3 phases (one to
authenticate the machine, one to authenticate the user and one to
exchange keys). The hybrid keeps it by being a complete mutual
authentication in phase 1.

> 
> In detail to your I-D:
> 
> 3. You propose using Public-Key-based auth. for the edge device,
> which means a certificate must be known to the mobile user or
> transmitted during "hybrid auth mode"-exchange - so you need to
> verify the cert. on the mobile station, and therefore you need a
> basic kind of PKI, at least with a one-level certification hierarchy.
> But within this hierarcy you can certify your clients too... (I
> absolutely agree Steve, that it's not so difficult to build PKIs in
> a limited organizational environment)

I have worked on implementation of full blown PKI, and of a very minimal
PKI of the sort needed for the hybrid (which for small organization may
be only one key). There is a huge difference in the complexity of the
code and of the management effort.

> 
> 4. (last) your comparison to SSL (Sect. 2.2) is not correct, at
> least not understandable: If a server requests client auth. during
> the SSL handshake the client MUST reply with a certificate. With SSL
> you always need a kind of PKI - there is no migration path with
> pre-shared secrets like in IKE. Anything else above SSL mostely can't
> be called client auth. (especially not a credit card number...)- it
> only depends on the application running on SSL. For the Web, real
> client auth. would only be provided by S-HTTP on a per-document
> basis.

Offcourse the comparison was not to a pure SSL but for a combination of
S-HTTP server and application requiring more authentication. Maybe we
should make it clearer.

> 
> Kai
> 
> # Kai Martius                                                           #
> # Dpt. of Medical CS and Biometrics / Dresden University of Technology  #
> # PGP Fingerprint: to be compared after download of my key              #
> # Key and more info see my Homepage                                     #
> # http://www.imib.med.tu-dresden.de/imib/personal/kai.html              #

-- 
-----------------------------------------------------------------------
Moshe Litvin                    Check Point Software Technologies Ltd.

moshe@checkpoint.com            Tel:   +972-3-753-4601 (972-3-753-4555)
                                Fax:   +972-3-575-9256
-----------------------------------------------------------------------
References: