OTP, deployability.

Cornelius Kölbel cornelius.koelbel at lsexperts.de
Fri Jun 17 16:09:18 EDT 2011


Hi all,
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.
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.
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.

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.

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.

Kind regards
Cornelius


Am 17.06.2011 21:39, schrieb Ken Hornstein:
>> It is not too hard. It is risky.
>> IMO it is a bad security practice to expose the OTPs in an interface.
>> Such interface would definitely become an attack target. Ant it is much
>> easier to attack than the recent attacks against RSA.
> Respectfully ... that is your opinion, and I don't agree.  Fine.
> But it's at least something that _I_ can control and decide what
> the appropriate security measures are.  One admitted weakness of
> Kerberos is that the critical secrets have to exist _somewhere_
> where the KDC can access them.  It's an obvious attack target.
> However, it's a known problem and people have dealt with it.  It's
> not generally considered a problem in practice.  I don't see why
> an OTP server is any different.  And somehow I'm more comfortable
> with a security model that depends on the security of the machines
> I administrate, versus "the machines I administrate plus the machines
> of some large corporation who doesn't really give a rat's ass about
> me after they've made the sale" :-/
>
>> Yes the problem is solvable however someone needs to share the critical
>> credential information. It is either the KDC to the OTP server or OTP
>> server to KDC. You generally can't assume that they are on the same box
>> so there should be a protocol to share the info or better to create an
>> exchange sequence that would allow for information not to leave the
>> authenticating party or at least to leave in a such a form that it can't
>> be used for the authentication. This can be done but that would be a
>> very long shot. It would require standards work.
> My point is that we shouldn't design protocols on the assumption that we
> will never have access to the actual OTP token output.  As we have seen,
> that assumption is false.  Obviously protocols should be designed so that
> things will work in the case where the the token output is not available,
> but if we can do better if the token output IS available then we should.
>
> --Ken
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20110617/89b98215/attachment.bin


More information about the krbdev mailing list