Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by krbdev.mit.edu (8.9.3) with ESMTP id WAA25672; Fri, 9 May 2003 22:58:07 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h4A2w6l4000580 for ; Fri, 9 May 2003 22:58:06 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h4A2w6qa014060; Fri, 9 May 2003 22:58:06 -0400 (EDT) Received: from all-in-one.mit.edu (ALL-IN-ONE.MIT.EDU [18.18.1.71]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h4A2w6U8005181; Fri, 9 May 2003 22:58:06 -0400 (EDT) Received: (from raeburn@localhost) by all-in-one.mit.edu (8.9.3p2) id WAA25814; Fri, 9 May 2003 22:58:06 -0400 To: krb5-bugs@MIT.EDU Subject: ticket forwarding broken when TGS and app service have different enctypes From: Ken Raeburn Date: Fri, 09 May 2003 22:58:05 -0400 Message-Id: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-RT-Original-Encoding: us-ascii Content-Length: 1178 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