OTP, deployability.

[Dmitri Pal]

On 06/17/2011 04:06 PM, Roland C. Dowdeswell wrote:
> On Fri, Jun 17, 2011 at 02:49:30PM -0400, Dmitri Pal wrote:
>> It is not too hard. It is risky.
>> IMO it is a bad security practice to expose the OTPs in an interface.
> I disagree.  I do not think that it is bad security practice to
> allow the KDC to read user's current and potentially future OTPs.

KDC sure, the challenge is to enforce that it is KDC only.
It can be done, but it is hard to drive vendors into it without the well
thought through standards.

> After all, the KDC can mint tickets for the user without bothering
> to check with the OTP server at all.  It is perfectly reasonable
> to consider the OTP system to be a subcomponent of the KDC
> infrastructure and allow information to flow in the correct direction:
> that is from lower risk systems (the OTP servers) to higher risk
> systems (the KDCs).  Whether the components of the KDC infrastructure
> physically reside on the same machine is something that is best
> left up to the customers to decide because they are likely to have
> a little more knowledge of their environment and requirements than
> the vendor.

I would agree with you in general but we live in the world where there
is no open source OTP server yet that can be capable of what you ask. At
least I could not find one ready enough.
There are a lot of proprietary vendors though. We can't ask or force
them to do what they do not have incentives to do.

So what are our options?

1) Create a standard for the exchange so that vendors can implement the
interface. Paves a way but does not add a lot of incentive.
2) Develop and OTP server using open standards (HOTP/TOTP) that would be
integrated with KDC.

Both options go to the same goal and IMO can be executed in parallel. I
suspect the first one would take more time than the second.
I am all for the second one though. We plan to invest into it when we
are done with the framework covered in Authentication Hub project.
We looked at the following code base as something to start with
http://code.google.com/p/otpd/
But even with the existing code base it is a many man/month project.

Would be nice to be able to work out the architecture of such server if
it is embedded into KDC and uses same data store to store tokens.
The scope of work would be:
0) Work out the high level architecture
1) Define the data model
2) Implement the library to read the token XML file (RFC6030)
3) Define interface to manipulate token data (import; read during auth;
save things like last used interval or count, drift/offset, number of
failures etc.)
4) Think about replication issues and especially attacks that try to
play same code against different KDCs. Might require some sort of fast
replication/locking mechanism between servers.
5) Implement the OTP processing as plugin to the KDC (assumes that the
plugin framework is ready becuase you really want to have async
processing in place first)

May be more... I have not dived into a lot of details of such
evaluation, just did a rough assessment. But if anyone wants to help and
speed it up - sure!

 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/