OTP, deployability.

[Roland C. Dowdeswell]

I have been reading some of the recent discussions on the list
about implmenting new pre-auth mechanisms to deal with OTP with
some interest.  Also, the recent thread about storing passwds in
memory revived my interest as OTP mechanisms are the obvious way
to stop this from posing a security risk as they would simply store
a string that was no longer directly useful.

I considered deploying OTP via Kerberos at a previous employers a
number of years ago and have a number of observations from a large
scale existing Kerberos shop that might be of interest.

If one has a large deployed Kerberos infrastructure, it would be
much easier to deploy it if it did not involve the addition of
pre-authentication mechanisms but rather was able to work with
PA-ENC-TIMESTAMP using a single password prompt.  This is certainly
not possible for all OTP mechanisms, e.g. if there is a challenge
response, well, obviously you must deliver the challenge in some
fashion.  But for event-based or time-based OTP systems where there
is no challenge, it should be possible to deploy them by simply
modifying the KDC and user behaviour but not the client libraries.

The reasons that you might like to be able to do this are many but
the most important ones that spring to mind are:

	1.  A large existing Kerberos shop will likely have a rather
	    heterogenous environment with many OSes floating about
	    all of which are required to continue working.  You
	    are unlikely to be able to affect change to, e.g.  the
	    older unsupported Windows machines but large organisations
	    will generally have software which does not work on
	    newer OS builds.  It sometimes takes many many years
	    to work the older OSes out of the environment.

	2.  Upgrading PAM stacks even on existing OSes can prove to
	    be difficult due to ABI issues, etc.  Applications that
	    both use Kerberos ticket-based authentication and PAM
	    have to have either PAM stacks that are built with the
	    same version of the Kerberos libraries or a PAM stack
	    that plays a few games to get to use its version of
	    the krb5 libs (perhaps simply linking the krb5 libs
	    into the PAM stack statically).

	3.  A lot of PAM applications assume user+pass and cannot
	    deal with a proper conversation.  Especially on older
	    OS versons: I'm pretty sure that I've seen issues with
	    gdm, xlock and xscreensaver in the last five or so years.
	    (But my memory could be a bit hazy.)

	4.  Large Kerberos shops rarely use Kerberos only for authentication
	    but frequently have legacy applications that provide username
	    and passwd.  Many of these might of been written prior to
	    Kerberos being installed or perhaps just cargo-culted from
	    older software.  This software is unlikely to understand
	    the conversation in krb5_get_init_creds() because, well,
	    let's just be honest: the developers noted that it would
	    be harder to do it properly and so they didn't under the
	    assumption that the world would never change.

	5.  3rd party vendor code frequently expects to do a PLAIN
	    auth against LDAP to validate user passwds.  Maybe some
	    internally developed software simply queries LDAP.

	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.

These sorts of issues could take years to resolve at a large company.

None of what I am saying should be interpreted to mean that I think
that new preauth mechanisms shouldn't be developed, but rather, I
think that it would be quite useful to a number of environments if
there were an option or two to deploy OTP without changing the
current AS_REQ exchanges---especially in the short term---because
rolling out new pre-auth mechanisms might take many years at many
established institutions.

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/