disallow requests naming principal as a service
jbrezak at windows.microsoft.com
Wed Mar 27 12:34:00 EST 2002
From: Nicolas Williams [mailto:Nicolas.Williams at ubsw.com]
Sent: Wednesday, March 27, 2002 4:59 AM
To: Sam Hartman
Cc: Moore, Patrick; John Brezak; krbdev at MIT.EDU; John Brezak (E-mail);
Subject: Re: disallow requests naming principal as a service
It's all about trade-offs. Kerberos represents a number of trade-offs.
For example, by using out-of-band clock synchronization and replay
caching AP exchanges can be 1/2 to 1 round-trips. In extentions the KDC
will have a role in negotiating a service's green vs. purple support
with the client. And the MS and DCE PACs have a network optimization
role (besides also facilitating very granular read-access control of
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
[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.
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.
- 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
- if failure, from KDC because it won't do u2u for that
[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.
This way the error from the TGS is irrelevant.
-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.
More information about the krbdev