[16936] in Kerberos_V5_Development
Re: OTP, deployability.
daemon@ATHENA.MIT.EDU (=?ISO-8859-1?Q?Cornelius_K=F6lbel?)
Sat Jun 18 07:14:09 2011
Message-ID: <4DFC8870.5070405@lsexperts.de>
Date: Sat, 18 Jun 2011 13:13:52 +0200
From: =?ISO-8859-1?Q?Cornelius_K=F6lbel?= <cornelius.koelbel@lsexperts.de>
MIME-Version: 1.0
To: krbdev@mit.edu
In-Reply-To: <4DFBBCF7.3030808@redhat.com>
Content-Type: multipart/mixed; boundary="===============0480040191=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0480040191==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig67D90CBE1FAEFCC942AF4587"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig67D90CBE1FAEFCC942AF4587
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Am 17.06.2011 22:45, schrieb Dmitri Pal:
> 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. A=
t
> 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 b=
e
> 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 an=
d
> speed it up - sure!
>
> =20
Hi Dmitri,
<advertisement>
did you ever take a look at LinOTP, which is an opensource otp server,
which has HOTP support, which will have TOTP support in the upcoming
release and will import files according to RFC6030?
It is modular enough to get user information form whatever user store
you wish to.
Well, the token information is stored in "some" sql database.
Plus: It is capable of supporting other kind of tokens.
</advertisement>
I personally still think, that it would be much nicer to make the OTP
server pluggable. Maybe it would be possible to not transfer OTP data to
the KDC but rather pass some KDC tasks to the OTP server?
Kind regards
Corneilus
--------------enig67D90CBE1FAEFCC942AF4587
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk38iHAACgkQGUgIxT8zfHFXoACgpUjV1CFdIaUvM/G/fQL+Eg0h
YakAnRHDB5hCNvp6oJgJVzl3CTmgIjEW
=oLlz
-----END PGP SIGNATURE-----
--------------enig67D90CBE1FAEFCC942AF4587--
--===============0480040191==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============0480040191==--
