Ticket History #17: kadmind and context expiration

From bjaspan@MIT.EDU Tue Sep 24 16:28:41 1996
Received: from dragons-lair.MIT.EDU (DRAGONS-LAIR.MIT.EDU [18.177.1.200]) by avalanche-breakdown.MIT.EDU (8.7.5/8.7.3) with SMTP id QAA19987 for <bugs@AVALANCHE-BREAKDOWN.MIT.EDU>; Tue, 24 Sep 1996 16:28:41 -0400
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by dragons-lair.MIT.EDU (8.6.13/8.6.9) with SMTP id QAA12982 for <krb5-bugs@dragons-lair.mit.edu>; Tue, 24 Sep 1996 16:28:40 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA17998; Tue, 24 Sep 96 16:28:33 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA01339; Tue, 24 Sep 1996 16:28:27 -0400
Message-Id: <9609242028.AA01339@DUN-DUN-NOODLES.MIT.EDU>
Date: Tue, 24 Sep 1996 16:28:27 -0400
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: kadmind and context expiration
X-Send-Pr-Version: 3.99

mit

System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc



kadmind apparently does not deal with context expiration very
gracefully. At least, when users accidentally had max_life of zero on
all principals, kadmind was failing with a non-helpful error message.
I suspected at the time that the problem was that accept_sec_context
was not returing expired errors, thus leaving that for gss_seal which
was failing on the sequence number (or something like that).




Responsible-Changed-From-To: hartmans->bjaspan
Responsible-Changed-By: bjaspan
Responsible-Changed-When: Tue Sep 24 16:43:37 1996
Responsible-Changed-Why:


From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/17: kadmind and context expiration
Date: Fri, 27 Sep 1996 16:01:25 -0400

My previous suspicion was almost correct. accept_sec_context can
return a krb5 expired message (because it uses krb5_rd_req), but it is
still possible for a context to expire after that returns but before
the following gss_seal is called (to sign the RPC's initial sequence
number). Presently, svc_auth_gssapi.c handles that situation by (a)
not logging the GSS-API error strings explicitly and (b) returning an
AUTH_BADVERF error to the client. This causes the client to try again
with a lower version number, which is why multiple error messages (and
a warning about an old version) are generated.

This problem only occurs when the context expires between
gss_accept_sec_context and the following gss_seal. If the credentials
expire before gss_accept_sec_context is called, or the context expires
after it is established in in the rpc layer, the right thing happens
(where "right thing" can be improved, but that is another pr).

I could change the code to return an AUTH_OK status but with the
actual GSS-API error codes, like I do when accept_sec_context fails;
that way, at least the client would know to give up (and could print
the error strings if it wanted). I could also call the log_badauth
callback in the server, so kadmind's log file would contain useful
information. But this is a sufficiently rare condition that I do not
think it is really worth the effort.

From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/17: kadmind and context expiration
Date: Wed, 16 Oct 1996 15:22:03 -0400

Ooops. The problem is in fact that accept_sec_context does *not*
return CREDENTIALS_EXPIRED when they have, thus gss_seal was catching
the error. Marc is fixing the bug in accept.

State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Wed Oct 16 16:17:08 1996
State-Changed-Why:

Fixed. Files:

lib/rpc/ChangeLog
lib/rpc/unit-test/ChangeLog