otpasswd-talk
[Top][All Lists]
Advanced

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

Re: [Otpasswd-talk] Using OTP to kind of fix MITM.


From: Hannes Beinert
Subject: Re: [Otpasswd-talk] Using OTP to kind of fix MITM.
Date: Tue, 22 Dec 2009 09:45:00 -0600

On Tue, Dec 22, 2009 at 09:10, Hannes Beinert <address@hidden> wrote:
>
> For example, the server could issue a challenge of the form 2C4:XXXX,
> where 2C4 is a standard passcode identifier and XXXX is the result of
> an encryption function on that passcode, ie, XXXX = E(PSK,PC(2C4)).
> Since the user has the passcode sequence, s/he could decrypt this
> PC(2C4) = D(PSK,XXXX) and thereby authenticate the host.  Then, the
> user could send a response of YYYY = E(PSK,PC(3C4)), ie, the
> encryption of the next passcode in the sequence.  An alternative
> scheme might be to respond with YYYY = E(PC(2C4),PC(3C4)), where the
> passcode used in the challenge is used to encrypt the response.

Argh.  This was utter nonsense.  This is why I should never write
anything before I've had coffee and my brain starts working.

First, in the case of an unencrypted channel, the response token YYYY
would easily be transferred as an opaque token from the user, through
the MITM, to the server.  Nothing would be gained.

And second, the typical use-case for PPP is to protect an *SSH* login
session over an encrypted tunnel, rather than a plaintext login
session.  Given this, to preclude a MITM we merely must authenticate
the SSH server.  Following standard SSH protocol and verifying the
host key will adequately ensure we're connected to the correct host.
As Luke points out, printing the server host key on the passcard would
probably be more than adequate.

Now, if we start discussing the use of PPP for plaintext sessions,
then that's Something Completely Different(tm).  And certainly nothing
I dare speculate about without first urgently making some coffee.

Hannes.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]