Subject: OTP pre-auth requirements

From: Nicolas Williams <[email-masked]>
Date: Thu, 14 Sep 2006 13:15:12 -0500

It might be useful to gather a set of requirements for OTP pre-auth
work.

A start:

 - Any OTP pre-auth methods have meet the requirements of Kerberos V
   pre-auth mechanisms in general.

   (It would be nice to know what existing, deployed systems are of
   which type.  But it should not be a requirement that an I-D
   specifying an OTP pre-auth method actually list these systems.)

 - State which, if not both, of KG and non-KG OTPs are supported.

    - Define "KG" and "non-KG."

 - The KDC must not be required to be the OTP server or collocated with
   the OTP server.  As far as the AAA infrastructure goes the KDC
   must be just another client and there's nothing special to it.

    - Corollary: The OTP server must not be required to have access to
      any secrets normally shared only between the KDC and the
      principals it serves.

 - OTPs MUST NOT go on the wire in the clear.

 - Any proposed solutions must be deployable.

 - Stateless clients must be supported (i.e., shared secret
   bootstrapping alone is insufficient).

 - Challenge/response and OTP token systems BOTH must be supported.

 - Synchronization of OTPs must be supported.

    - This might include localized help messages in replies if
      variations on synchronization cannot be generalized easily enough.

 - Reply key strength -- must be at least as good as what we get from
   normal passwords, preferably a lot better.

    - Where KG tokens generate keys that are too short the
      pre-authentication (at least the reply key function) must be
      strengthened in some other way or the token must not be allowed.

      I say "at least the reply key function" because a six-letters-and-
      digits one-time password is plenty good enough for protecting the
      AS-REQ in real-time, but perhaps too weak to protect the reply, or
      perhaps only just as strong as high-quality memorable passwords.

      MITMs in the AS exchange have to be able to break pre-auth in
      real-time, but eavesdroppers can spend much more time doing brute
      force keyspace searches offline, and eavesdroppers care a lot
      about the reply.

      Note that a scheme that uses channel binding to TLS/PKINIT might
      reduce the scope for attack on weak one time keys to MITM attacks,
      which means that OTKs must be strong enough to at least detect
      attacks in real-time, but not necessarily much stronger.  This may
      not work well for OTP schemes not based on clock synchronization,
      but it should work well for challenge/response and time-based KG
      OTP schemes.

 - Use EAP and/or related AAA technology or explain why they aren't
   used.

I'm not an expert on AAA.  Are there AAA protocols for KG tokens?  A
protocol where the client and the OTP server derive a one-time key from
an OTP and where the client can encrypt something in that one-time key
that can then be made available, by the OTP server, to the AAA client
(the KDC).  I don't see anything like this in the base DIAMETER spec,
for example.

Any other requirements?  I'm sure I've missed some.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Fri, 29 Sep 2006 16:06:38 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas>  - OTPs MUST NOT go on the wire in the clear.

Is this true of existing Kerberos secure ID deployments?
If not, why is it now a requirement?

    Nicolas>  - Use EAP and/or related AAA technology or explain why
    Nicolas> they aren't used.

    Nicolas> I'm not an expert on AAA.  Are there AAA protocols for KG
    Nicolas> tokens?  A protocol where the client and the OTP server
    Nicolas> derive a one-time key from an OTP and where the client
    Nicolas> can encrypt something in that one-time key that can then
    Nicolas> be made available, by the OTP server, to the AAA client
    Nicolas> (the KDC).  I don't see anything like this in the base
    Nicolas> DIAMETER spec, for example.

    Nicolas> Any other requirements?  I'm sure I've missed some.

    Nicolas> Nico --

You must not use EAP: Kerberos is not network access.

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 29 Sep 2006 16:35:29 -0400

>Is this true of existing Kerberos secure ID deployments?

If you're talking about the ones today that use SecurID as a preauth
mechanism, then the answer is "yes" (they're encrypted with the user's
long-term key).

--Ken