[14586] in Kerberos
RE: Kerberos and Two-Factor Authentication
daemon@ATHENA.MIT.EDU (Mayers, Philip J)
Mon Jun 25 10:04:14 2001
Message-ID: <A0F836836670D41183A800508BAF190B35E77F@icex1.cc.ic.ac.uk>
From: "Mayers, Philip J" <p.mayers@ic.ac.uk>
To: "'Jad S. Boutros'" <jad@stanfordalumni.org>, kerberos@mit.edu
Date: Mon, 25 Jun 2001 14:58:57 +0100
MIME-Version: 1.0
Content-Type: text/plain
You'd be looking at some kind of preauth data field. There are currently
some defined ones:
PADATA-TYPE ::= INTEGER {
KRB5-PADATA-NONE(0),
KRB5-PADATA-TGS-REQ(1),
KRB5-PADATA-AP-REQ(1),
KRB5-PADATA-ENC-TIMESTAMP(2),
KRB5-PADATA-PW-SALT(3),
KRB5-PADATA-ENC-UNIX-TIME(5),
KRB5-PADATA-SANDIA-SECUREID(6),
KRB5-PADATA-SESAME(7),
KRB5-PADATA-OSF-DCE(8),
KRB5-PADATA-CYBERSAFE-SECUREID(9),
KRB5-PADATA-AFS3-SALT(10),
KRB5-PADATA-ETYPE-INFO(11),
KRB5-PADATA-SAM-CHALLENGE(12), -- (sam/otp)
KRB5-PADATA-SAM-RESPONSE(13), -- (sam/otp)
KRB5-PADATA-PK-AS-REQ(14), -- (PKINIT)
KRB5-PADATA-PK-AS-REP(15), -- (PKINIT)
KRB5-PADATA-PK-AS-SIGN(16), -- (PKINIT)
KRB5-PADATA-PK-KEY-REQ(17), -- (PKINIT)
KRB5-PADATA-PK-KEY-REP(18), -- (PKINIT)
KRB5-PADATA-USE-SPECIFIED-KVNO(20),
KRB5-PADATA-SAM-REDIRECT(21), -- (sam/otp)
KRB5-PADATA-GET-FROM-TYPED-DATA(22),
KRB5-PADATA-SAM-ETYPE-INFO(23)
}
There are some one-time-password ones there, as well as a SecureID, which is
"real" two factor. The PKINIT with smartcard solution can be considered 2 or
1.5 factor, depending on who you ask. I don't know what RFCs these are
specified in, but they must be around somewhere...
Regards,
Phil
+----------------------------------+
| Phil Mayers, Network Support |
| Centre for Computing Services |
| Imperial College |
+----------------------------------+
-----Original Message-----
From: Jad S. Boutros [mailto:jad@stanfordalumni.org]
Sent: 23 June 2001 01:58
To: kerberos@MIT.EDU
Subject: Kerberos and Two-Factor Authentication
I would like some info regarding how we can integrate a two-factor
authentication solution with Kerberos.
During the initial login, the user will need to provide his password and
some kind of one time token (say using SecurID). After that, I assume that
everything else should remain the same given that the TGT is used instead
of the credentials [well, the kerberos password change for example may or
may not require a one-time token but that's not too important].
I guess there is no simple way in the protocol for the login client to
forward the one-time token to the KDC and have the KDC validate it with
the (two-factor) authentication server. This probably means that the login
client will have to communicate with the auth. server directly during the
login "handshake".
Are there any such implementations available? Any info appreciated.
Thanks. jad.
