[27] in GSSAPI Development
Re: Towards a compromise on addresses in channel bindings
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Tue Apr 30 22:40:28 1991
Date: Tue, 30 Apr 91 18:05:16 -0400
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: "John Wray, Secure Systems Development, DTN 226-6106 30-Apr-1991
Cc: gssapi-dev@ATHENA.MIT.EDU
In-Reply-To: John Wray, Secure Systems Development, DTN 226-6106 30-Apr-1991 1658's message of Tue, 30 Apr 91 14:09:28 PDT,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Tue, 30 Apr 91 14:09:28 PDT
I guess we need a convention to mean "indefinite". How about
returning -1 in this case?
Well, time_rec is specified as OM_uint32, which means that it's an
unsigned integer of at least 32 bits. So how about (2**32-1) meaning
"indefinite"?
Really, though, no context should be considered valid after the credentials
with which it is established have expired. This should put an upper
limit on the context lifetime. The system/security manager may also
be able to configure the mechanism to impose a lower lifetime on
contexts. Finally, the time_req input parameter allows the
application to request a shorter period.
This only really makes sense if the authentication mechanism enforces
the lifetime (by refusing to perform sign/seal operations on an
expired context). If a given mechanism doesn't support this, then I
guess it should return "indefinite" for the time_rec parameter.
This is the heart of the matter. Is the GSS API layer required to keep
track of how many seconds are remaining before a context expires and
refuse to pass a request down to the mechanism layer? As far as
Kerberos is concerned, once a context has been established, all
krb5_{mk,rd}_safe care about is the session key; they don't even look at
the credentials information. It is the application may want to
terminate a connection after the credentials have expired, although no
Kerberos application which I am aware of does so. (I can imagine an
rlogin session closing with no saving throw, just because 8 hours have
passed and your tickets have expired, so you get to lose all of your
work. No thanks! I'd call that a bug, not a feature!) My
understanding is that SPX does not implement anything like this either.
Is this correct?
If we say that time_rec can return "indefinite", it means that the GSS
API layer is not responsible for inforcing a timeout period for the
context, even if one is requested using time_req. This to me seems to
be the right answer. Are we all agreed on this?
- Ted
