[16909] in Kerberos_V5_Development
Re: OTP, deployability.
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jun 16 16:13:22 2011
MIME-Version: 1.0
In-Reply-To: <87fwn9wte6.fsf@windlord.stanford.edu>
Date: Thu, 16 Jun 2011 15:06:18 -0500
Message-ID: <BANLkTikR1M-xVMH4xW8HSO_3_ckNZ1P=Qw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Russ Allbery <rra@stanford.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, Jun 16, 2011 at 12:58 PM, Russ Allbery <rra@stanford.edu> wrote:> "Roland C. Dowdeswell" <elric@imrryr.org> writes:>> 6. web browsers on iPhones, iPads, blackberries, etc. can't>> do Kerberos and likely connect to one or more systems that>> are likely to have the assumption that user+pass is the>> structure of authentication.>> Client-side certificates tied to a principal that isn't the user's basic> principal but instead is a principal scoped to that device that can be> separately revoked seem to be the way to go here. The user really wants> to just authenticate their phone, not themselves using their phone, for> most things the user does (even if they don't realize that).>> That still leaves open the problem that, as you say, applications expect a> username-password, but I wonder if you couldn't use the certificate on the> phone and another app to generate the password that the application can> use and then cut and paste it into the application.
Force the user to use VPN (most smartphones support VPN) if they wantto access internal services. Use the phone's cert to authenticate thephone at the edge. Use password+OTP to authenticate the user,possibly also at the edge, as well as at sensitive internal services.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
