[16534] in Kerberos_V5_Development
Issues with Active Directory <-> MIT x-realm key replacement
daemon@ATHENA.MIT.EDU (Jeffrey Altman)
Wed Dec 8 17:17:24 2010
X-Envelope-From: jaltman@secure-endpoints.com
X-MDaemon-Deliver-To: krbdev@mit.edu
Message-ID: <4D0003E6.5060704@secure-endpoints.com>
Date: Wed, 08 Dec 2010 17:17:10 -0500
From: Jeffrey Altman <jaltman@secure-endpoints.com>
MIME-Version: 1.0
To: "'krbdev@mit.edu'" <krbdev@mit.edu>
Reply-To: jaltman@secure-endpoints.com
Content-Type: multipart/mixed; boundary="===============1287434872=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============1287434872==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig2F766F04F68071E2F204B9CE"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2F766F04F68071E2F204B9CE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I am sure that I am not the first to discover that implementing a key
replacement strategy for Active Directory <-> MIT cross-realm keys is
impossible to do with current code without causing an outage for clients
with cached cross-realm service tickets. This is due to the fact that
Active Directory issues krbtgt/MIT@AD service tickets with the kvno set
to zero. As a result, the MIT KDC when presented with a service ticket
issued before the key replacement will attempt to decrypt it with kvno
"maxkvno" instead of "maxkvno - 1".
The code path of consequence is that krb5_rd_req_decrypt_tkt_part()
calls krb5_kt_get_entry() with kvno =3D=3D 0 which returns the entry for
maxkvno which is then passed to krb5_decrypt_tkt_part() which will
return KRB5KRB_AP_ERR_BAD_INTEGRITY since the key entry will not match
the key used to encrypt req->ticket.
As a side effect clients that have cached krbtgt/MIT@AD service tickets
will either need to have the cache destroyed or wait until the tickets
expire. The default AD GPO policy is for a 10 hour lifetime with 7 day
renewal. There is no mechanism in AD to mitigate this outage by setting
a shorter lifetime (say 10 minutes) for just the krbtgt/MIT@AD service
principal at least max lifetime minutes before the key replacement.
I wrote code to permit the MIT KDC to retry using the "maxkvno - 1" key
when krb5_decrypt_tkt_part() returns KRB5KRB_AP_ERR_BAD_INTEGRITY IFF
the krb5_princ_name(service) =3D=3D "krbtgt", the requested kvno is zero,=
and maxkvno > 1. However, this leaves a security vulnerability in that
it requires the key to be replaced twice at least max lifetime minutes
apart in order to ensure that a compromised or weaker key is no longer
usable.
I can reduce the window of vulnerability if the
krb5_dbe_lookup_last_pwd_change() returned timestamp is compared to the
decrypted req->ticket issue time and only permit the "maxkvno - 1" key
to be acceptable if the ticket was issued during the max lifetime period
prior to the last_pwd_change time. I believe this criteria should be
sufficient to make this an acceptable default behavior for a KDC. Do
other members of the MIT Kerberos development community concur?
Jeffrey Altman
--------------enig2F766F04F68071E2F204B9CE
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.9 (MingW32)
iQEcBAEBAgAGBQJNAAPoAAoJENxm1CNJffh4QRAH/i206vx87kwNcI5U9OdDIUpE
RLhZFlDyWzSSTxC1LlinxOwAsyav/2+B4LfF3gwfs9FdyVlQ2HOJOVhWN+qf4FRB
7DY96RhcnIMfvvhyJAM/0plQfuXh75SMI1c0mx5hDDuNVpxDuZrqlqBKDlnCkEAt
uvjj94KS/nv5IiVzLh+dqF7fOIjPfXJBPWJe2dL9/yRH230ERtWU5Y4baZ5dlACx
CoJAzVS7UGRt3m+ckJ73uTkldjMiOZiXHMZ9kOhLOT1qrsP5JxFTRqHVthAe7qrf
VodyB1p04MRN00uIpp4m6QTw7SCx9UVQeCe3axBxap8qVApAleMAo2uav1Yen84=
=TL8h
-----END PGP SIGNATURE-----
--------------enig2F766F04F68071E2F204B9CE--
--===============1287434872==
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
--===============1287434872==--
