Re: User-level Authentication Mechanisms for IPsec

["Scott G. Kelly" <skelly@xxxxxxxxxxxx>]

Hi Tamir,

Thanks for your comments. Responses interspersed below.

Tamir Zegman wrote:
> 
> 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?

I'll work backwards on this. First, no, it's not red herring. I will
admit that on its own, it's not overwhelming motivation to kill xauth,
but taken together with the many other issues, it adds fuel to the fire.
Compare some of the plaintext in xauth to to that of IKE:

     IPSec Host                       Edge Device
     --------------                -----------------
                         <-- REQUEST(TYPE=GENERIC NAME=""
                                     PASSWORD="")

     REPLY(TYPE=GENERIC NAME="joe"
               PASSWORD="foobar") -->

                         <-- REQUEST(TYPE=GENERIC
                                     MESSAGE="Enter your password
                                     followed by your pin number"
                                     NAME="" PASSWORD="")

     REPLY(TYPE=GENERIC NAME="joe"
           PASSWORD="foobar0985124") -->

                         <-- SET(STATUS=OK)


Look at all the ASCII TEXT here. As you know, this is all included in
the exchange, and in a very predictable location within the packet. This
is ripe for offline attack, given the appropriate resources. Granted,
not just anyone can marshall these resources, but that does not mean
this should be ignored.

Regarding standard IKE messages, I agree that the IKE header presents
some known plaintext, but I think the amount is relatively small
compared to the above. As for the IKE message body, the requirement that
implementations support receiving the payloads in any order provides an
avenue for mitigating the risk posed by any known plaintext in this
section.

Regarding IPsec protocol SA messages, proper identity protection will
conceal whether the session is TCP, UDP, or whatever, at least to some
extent, right? And if some sort of ULA protocol is running over the
protocol SA, how does the attacker know this? On the other hand, we know
that traffic analysis techniques will allow us to make probabilistic
predictions in this regard, but the risk is reduced here, given the much
smaller amount of predictable data available to the attacker. This risk
is further mitigated by the use of randomly ordered TLV payloads instead
of ascii text.

In closing, I'll reiterate that I don't want to blow this known
plaintext thing out of proportion. It is relatively minor compared to
the other issues raised.

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

ISACFG may not seem very complicated yet, but take a look at dhcp, ppp,
pptp, l2tp. Provisioning of remote clients is not simple. I have argued
for some time that isacfg and xauth should separated, since they each
raise a very different set of concerns. The draft simply points out that
as it currently stands, isacfg and xauth are a package, further
complicating the task of analyzing the security implications of
implementing them.

The draft doesn't say they are necessarily complicated to implement,
though isacfg will certainly become more complex as people come to
understand the requirments of remote access client configuration.
Rather, it says they add unecessary complexity to the key exchange. We
all agree that key exchange is critical with respect to the resultant
session security. The draft suggests that it is imprudent to needlessly
add complexity to this step.

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

This is why the draft recognizes and discusses the need for a
transition.

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

That's about 80% of a PKI implementation, right? The only thing saved
here is client enrollment and client key storage. I want to emphasize
that the draft does not say there is no need for hybrid - it simply
places it within a transition framework.

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

I don't encourage the use of preshared keys, but I recognize that there
are organizations which may require their use, so I won't rule them out
completely. You are correct in that I typically do not recommend them. 
During the transition process, I think a hybrid technique (like CRACK)
may be appropriate for authenticating the IKE SA, as well as stronger
methods.

The draft discusses the notion that even if there were a ubiquitous PKI,
passwords would probably still be required. I don't think they'll ever
go away completely.

Scott