User-level Authentication Mechanisms for IPsec

[Tamir Zegman <zegman@xxxxxxxxxxxxxx>]

Hi Scott.
Some remarks on draft-kelly-ipsra-userauth-00.txt:

The Known Plaintext issue:

<trimmed>
Known Plaintext

     There is a significant amount of known plaintext in the exchanges
     described in [XAUTH].
<trimmed>
     Without question, there is a significant amount of known plaintext
     here. An adversary could passively collect any number of these
     exchanges, and then analyse them at leisure. Note that it is not
     necessary to break the session in real time in order to compromise
     a password and subsequently gain access to the remote network.
     However, real time attacks are a possibility in sufficiently long-
     lived sessions.
<trimmed>


The same argument can be applied to standard ISAKMP/IKE messages and to
IPSec to that matter.
Both have significant amount of plaintext(e.g. Reserved fields in ISAKMP
and TCP/IP headers in IPSec).
A good symmetric cypher should withstand these kind of attacks.
You need not forgot that in your proposal the client uses IPSec to
connect to the authentication proxy.
A large amount of the plaintext of these IPSec protected messages is
known to the attacker.
Is this a red herring?

As for the remarks on Hybrid:
<trimmed>
 The hybrid authentication method [HYBRID] uses [XAUTH] as a framework
   upon which to build. Hence, it suffers from many of the deficiencies
   of [XAUTH], namely excessive key exchange protocol complexity,
   dependency on [ISACFG], and substantial known plaintext in the
   exchanges.
<trimmed>
I've already made my remarks on the plain text issue.
XAUTh and ISACFG do not seem to be overly complicated.
I know of many vendors who have implemented both protocols.


The transition to PKI issue:
<trimmed>
   By only requiring a server certificate, Hybrid authentication
   provides more transition benefits than [XAUTH], which can only be
   safely deployed with both server and client machine certificates.
   However, as noted earlier, once full server certificate support is
   put in place, there may not be that much extra work involved in
   supporting client machine certificates. Thus the hybrid approach may
   provide only limited transition benefits above what is already
   supported in IKE.
<trimmed>

I beg to differ.
There's a big difference between deploying a small scale PKI among
security gateways and
deploying a wide one among users.
I know of many customers who have implemented the former but have yet to
implement the latter.
Note that the only certificate support you need on the client is the
ability to store the server's certificate and to be able to validate it.

This means you only need to store public keys.
The client need not posses a private key of his own.

Remarks on the ULA protocol:

<trimmed>
     o the client establishes a securely authenticated IKE
       SA followed by an IPsec SA with selectors which indicate
       the authentication proxy application on the gateway.
<trimmed>

How is this IKE SA authenticated?
Since you do not encourage the use of pre-shared keys(I don't either), I
assume you authenticate the IKE SA using certificates (or some other
strong method of authentication based on GSS API).
If this is the case, you are very close to being able to deploy user
certificates.
In which case, in my opinion, you do not need to support legacy
authentication systems.


Tamir.