[480] in Kerberos-V5-bugs
Re: rd_req_simple should allow null server?
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue May 24 16:55:55 1994
Date: Tue, 24 May 94 16:55:46 EDT
From: tytso@MIT.EDU (Theodore Ts'o)
To: "Jonathan I. Kamens" <jik@security.ov.com>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: "[427] in Kerberos-V5-bugs"
[0427] daemon@ATHENA.MIT.EDU (Jonathan I. Kamens) Kerberos-V5-bugs 03/03/94 12:42 (28 lines)
Date: Thu, 3 Mar 1994 12:42:52 -0500
From: "Jonathan I. Kamens" <jik@security.ov.com>
As it's written right now, the krb5_rd_req_simple function
doesn't allow server to be NULL, because it always dereferences it by
calling krb5_princ_component on it in order to determine the name of
the replay cache.
As it's written right now, the krb5_rd_req_simple function
doesn't allow server to be NULL, because it always dereferences it by
calling krb5_princ_component on it in order to determine the name of
the replay cache.
On the other hand, if the caller is using a private key store
with only one key in it, then it doesn't want to have to worry about
what its principal name is, so it should just be able to specify null
for the server.
This is really bad practice, and I will make sure the API doc
specifically warns against this. On the other hand, if the caller wants
to pass in NULL for the server, and check the returned server principal
itself, it should be free to do that.
I think that rd_req_simple should be modified so that it
checks if server is NULL, and if it is, uses some default replay cache
rather than trying to derive one from the name of the server
principal.
I don't want to use a default replay cache, since that might imply that
there was some sort of replay protection, when in fact there wouldn't
be. Or at least, the replay protection wouldn't be perfect, since a
particular AP_REQ message might be stored in potentially two different
replay caches. So, if server is NULL there should be *no* replay
protection whatsoever. Of course, this will all be documented....
- Ted
