diff options
author | Andrew Boardman <amb@mit.edu> | 2006-08-25 22:31:35 +0000 |
---|---|---|
committer | Andrew Boardman <amb@mit.edu> | 2006-08-25 22:31:35 +0000 |
commit | f56b403565ac2e59f020dd12ae57d56e39f35cf3 (patch) | |
tree | adca73a661c36e5fdb069185bd0b781d3e17506f | |
parent | ab42ce934966a0fada06d81f29bcfaf9f7d84284 (diff) | |
download | krb5-f56b403565ac2e59f020dd12ae57d56e39f35cf3.zip krb5-f56b403565ac2e59f020dd12ae57d56e39f35cf3.tar.gz krb5-f56b403565ac2e59f020dd12ae57d56e39f35cf3.tar.bz2 |
More blather about mixed-fallback cases after today's meeting with Ken
git-svn-id: svn://anonsvn.mit.edu/krb5/users/amb/referrals@18544 dc483132-0cff-0310-8789-dd5450dbe970
-rw-r--r-- | implementation.notes | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/implementation.notes b/implementation.notes index 36bedf4..7cdf9ad 100644 --- a/implementation.notes +++ b/implementation.notes @@ -21,6 +21,11 @@ problems with this: also get a referral you need to make sense of it. EXCEPT that if you start with a non-local realm it came from a domain_realm mapping (which we always trust), so start with that instead. + problem: how do you tell if it's from a domain_realm mapping or + something user-constructed? the answer seems to be that if + there's a non-local service realm name given for the initial + credential that it should always be used no matter what. + this might be broken behaviour, though. notes: - if referred, it comes with a cross-realm TGT for the new realm, @@ -204,3 +209,16 @@ from 21 aug 2006 meeting, notable screw cases and notes on same: - it's more important to minimize KDC round-trips and perform to minimally functional spec than to make all possible (and probably futile) fallbacks + +from 25 august 2006 meeting, thoughts on fallbacks: +================================================== +Part of the current plan is to move configuration information from the +client to the server. This, however, leaves us vulnerable in cases where +the home KDC ("A") knows that the service principal exists in C but that +the trust path traverses B, which is not referral capable. Our +conclusion is that the server should not be configured to offer referrals +to C at all, but should of course continue to return a cross-realm TGT to +B if asked, and that the client fallback to the standard +non-referral-based traversal is the only functional path here. + +But is that really the right thing? |