disallow requests naming principal as a service

[John Brezak]

inline [JBrezak]

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com] 
Sent: Wednesday, March 27, 2002 9:42 AM
To: John Brezak
Cc: Sam Hartman; Moore, Patrick; krbdev at MIT.EDU; John Brezak (E-mail);
Matt Crawford
Subject: Re: disallow requests naming principal as a service


On Wed, Mar 27, 2002 at 09:29:39AM -0800, John Brezak wrote:
> inline [JBrezak]
> 
> So it's not far-fetched to allow negotiation of traditional Kerberos 
> vs. U2U at the KDC exchange. It is generally the case that Kerberos 
> clients fetch service tickets before attempting to connect to the 
> services, after all. That said, negotiation of U2U at the KDC exchange

> looks really rickety - at the very least it would be nice to have 
> authenticated plaintext.
> 
> [JBrezak] Is there a reason that all krb-errors from a TGS-REQ cannot 
> contain a "TD-CHECKSUM" element in the e-data that is a checksum of 
> the krb-error signed with the TGT session key in the corresponding 
> TGS-REQ? It would also need to include the TGS-REQ nonce.

Aside from the fact that some here don't want TypedData used (right? or
do I need to go ingest some caffeine?)... the problem would be that the
TD checksum element would have to contain a checksum for a structure
that contains it itself (and you don't want to leave other TD data
unsigned either). So now we have to specify that to calculate the
checksum you must first marshal a KRB-ERROR with the checksum TD all
nulled out, then replace those nulls with the checksum. Ick.

[JBrezak] But this is commonly done for other checksummed data.

The authenticated plaintext stuff in extensions is better.
[JBrezak] at least for any error resulting from a TGS-REQ as long as the
PA-AP-REQ is valid so that the TGT session key can be used for signing.

Besides, should we be extending Green? Or clarifying it?

[JBrezak] This can be a separate I-D - how to authenticate krb-errors
resulting from TGS requests. Sometimes issues like these can be better
explored in an I-D before they get lost in a longer document.

> I'd rather that the app know a priori. If it can't know then I don't 
> mind it negotiating U2U vs. traditional AP exchange at the TGS 
> exchange. Like so:
> 
>  - get service ticket
>     - if success, connect to service and go from there
>     - if failure, connect to service anyways and see if it will do
U2U,
>       if so, then get a U2U service ticket and come back to the 
> service [JBrezak]
> 	- if failure, from KDC because it won't do u2u for that
principal

Ah, yes. A TGS spoofer or MITM can make you waste exchanges. You really
need extensions :)

> [JBrezak] So you wind up with a wasted C->S exchange and a wasted 
> TGS-REQ. If the KDC told you at the beginning that it is willing to do

> u2u, that is avoided.

Is it? Not unless the TGS KRB-ERROR response is signed Otherwise it can
always be spoofed.

Cheers,

Nico
-- 
-DISCLAIMER: an automatically appended disclaimer may follow. By
posting- -to a public e-mail mailing list I hereby grant permission to
distribute- -and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.