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

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

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:

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. (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).

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. 

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.

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)

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. 

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              #
Follow-Ups: