| To: | krb5-bugs@MIT.EDU |
| Subject: | ticket forwarding broken when TGS and app service have different enctypes |
| From: | Ken Raeburn <raeburn@MIT.EDU> |
| Date: | Fri, 09 May 2003 22:58:05 -0400 |
A heuristic added to the ticket-forwarding code to avoid problems
forwarding tickets to hosts without DES3 support has backfired. It
requested a forwarded ticket with the enctype of the session key for
talking to the service. However, if the session key and preferred
service key are, say, AES, but the TGS key is DES3 only, and we
(inappropriately) infer the supported key types from the KDB key
types, we'll decide that we can't get an AES TGT to forward. And
since that one enctype was specified in the list, we won't get any
other TGT either.
A better fix is probably to include the list of all supported
enctypes, but add the session key type and service key type to the
front of the list. (If they're in the client's permitted -- or should
it be supported? -- enctypes list; if not, I think other checks we do
on the client side will return an error, needlessly.) Make the two
enctypes we know the server supports be preferred, but not required.
In fact, the implementation on the server and KDC may support enctypes
the client doesn't know about, but I don't think we have any way to
express a willingness to accept a TGT with such a session key for
forward.
Ken
forwarding tickets to hosts without DES3 support has backfired. It
requested a forwarded ticket with the enctype of the session key for
talking to the service. However, if the session key and preferred
service key are, say, AES, but the TGS key is DES3 only, and we
(inappropriately) infer the supported key types from the KDB key
types, we'll decide that we can't get an AES TGT to forward. And
since that one enctype was specified in the list, we won't get any
other TGT either.
A better fix is probably to include the list of all supported
enctypes, but add the session key type and service key type to the
front of the list. (If they're in the client's permitted -- or should
it be supported? -- enctypes list; if not, I think other checks we do
on the client side will return an error, needlessly.) Make the two
enctypes we know the server supports be preferred, but not required.
In fact, the implementation on the server and KDC may support enctypes
the client doesn't know about, but I don't think we have any way to
express a willingness to accept a TGT with such a session key for
forward.
Ken