[16929] in Kerberos_V5_Development
Re: OTP, deployability.
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Jun 17 16:24:36 2011
MIME-Version: 1.0
In-Reply-To: <4DFBB46E.2000001@lsexperts.de>
Date: Fri, 17 Jun 2011 15:24:31 -0500
Message-ID: <BANLkTimwsE=UqeonRDV6Ss6fRv5ntM7pyw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: =?UTF-8?Q?Cornelius_K=C3=B6lbel?= <cornelius.koelbel@lsexperts.de>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
2011/6/17 Cornelius Kölbel <cornelius.koelbel@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 thoseOTPs? 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 ourworld 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 withcomplex operating systems and plenty of third party applications,whichmeans they are susceptible to all the local security problems thatdesktops and laptops are susceptible to, beginning with poor physicalsecurity and going through all the way to malware of all typesincluding 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 goelsewhere.
Consider, HOTP is an open standard, and there are both, hard and softtokens for it on the market, which means anyone can implement HOTPdirectly in the KDC itself.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
