OTP, deployability.

Nico Williams nico at cryptonector.com
Fri Jun 17 16:24:31 EDT 2011


2011/6/17 Cornelius Kölbel <cornelius.koelbel at lsexperts.de>:
> I look at it very pragmatic. I do not feel comfortable with exposing OTP
> values to another server (the KDC), but the KDC is the trust anchor in
> all may login environment.

If you depend so much on the KDC, why not give it access to those
OTPs?  What's to lose?

> I rather would not give the possibility to tell the KDC the next some
> OTP values, but this is a risk that needs to be measured. And I am much
> more comfortable with giving the next some OTP values than exposing the
> OTP secret - since it would be easy for me to invalidate these next OTP
> values.

Exactly.

> In an ideal world all these compromises would not be necessary, but in
> an ideal world, every client and every application would be capable of
> having all necessary protocols implemented.

In an ideal world we wouldn't need key management, or crypto.  But our
world is far from ideal.

> This offline scenario is another example. In fact it is not possible to
> secure the OTP values on a mobile client - as long as you don't have a
> full disk encryption with strong authentication. An attacker will always
> be able to find the encryption key, that protects the OTP values. Or
> these OTP values are encrypted based on my password, but then this is no
> real two factor authentication, since everything depends on my password.
> Yes, it is a compromise and a commodity feature.

Worse than that: mobiles are getting to be large computers with
complex operating systems and plenty of third party applications,which
means they are susceptible to all the local security problems that
desktops and laptops are susceptible to, beginning with poor physical
security and going through all the way to malware of all types
including rootkits.

> Why don't leave it to the user or the customer? After some decent
> consulting he could decide if he wants the common security standard now
> and "payable" or if he needs high security but later and expensive.
> To me this is not untrustworthy.

Right.  Let the customer choose.  If you say "no" the customer will go
elsewhere.

Consider, HOTP is an open standard, and there are both, hard and soft
tokens for it on the market, which means anyone can implement HOTP
directly in the KDC itself.

Nico
--




More information about the krbdev mailing list