[7104] in Kerberos
Gss-api security context idea.
daemon@ATHENA.MIT.EDU (Alain Lavoie)
Tue Apr 16 17:03:32 1996
To: kerberos@MIT.EDU
Date: Tue, 16 Apr 1996 19:48:04 GMT
From: Alain Lavoie <allavoie@qc.bell.ca>
Sam Hartman wrote:
>
> This naturally came up when the telnet environment hole was
> discovered last September. The solution at that point was to invent
> an idea called a secure context,
...
Which makes me bring up some ideas from our developpement. Managing more
than one client at a time for one server brought us to creat a Gss-api
security context object for each of them. All relative information is kept
and the server create-manage-delete each client session separately.
Proposition
-----------
A client can require to refresh its connection to avoid time
expiration from the credentiel by reexecuting a gss_init_sec_context()
after a proper kinit. The server detect the context token received and
reestablish the security context for that client. Therefore, the KDC admin
remains in control for deleviring and granting permissions to each client
while our implementation allow continuity of a connection even after
ticket or credentiel expiration.
I was hoping to find in (the almost unused function) gss_process_context_token()
the functionnality handling such behavior. However, I read that this
function is marked for "depreciation" by the IETF and that it will be
removed from the GSS-API lib.
Does some of you handle this design issue in another way ?
Alain.
--
============================================================================
Alain Lavoie allavoie@qc.bell.ca
Consultant (514) 870-6493 VOICE
Bell Sygma Telecom Solutions (514) 870-3004 FAX
25N1-700 de la Gauchetiere ouest
Montreal(Que.) H3B 4L1
Canada
============================================================================
