[15767] in Kerberos_V5_Development
Re: RFC 4121 - Context Deletion Tokens
daemon@ATHENA.MIT.EDU (Douglas E. Engert)
Fri May 7 10:48:29 2010
Message-ID: <4BE42838.30300@anl.gov>
Date: Fri, 07 May 2010 09:48:24 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
MIME-Version: 1.0
To: Srinivas Cheruku <srinivas.cheruku@gmail.com>
In-Reply-To: <4be39078.0207e30a.3996.7052@mx.google.com>
Cc: ietf-krb-wg@anl.gov, krbdev@mit.edu,
"'Nicolas Williams'" <nicolas.williams@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Srinivas Cheruku wrote:
>> and no GSS is involved in doing so?
>
> Well, you'd want to protect the application "delete context" message
> with a MIC or a wrap.
>
> [Srinivas Cheruku] Do you mean that we can generate a MIC token with message
> as NULL for delete context and can be sent to the peer and this is an
> interoperable approach? Is there any interoperable way of signalling delete
> context to the peer?
All the gssapi applications I have ever seen, delete the context based
either because of a network failure, or the client and server have agreed
using some non-GSSAPI message to close the connection.
In every case the applications need to call gss_delete_sec_context on
both ends.
So is there some special reason you need to use the GSSAPI delete context
message?
gss_delete_sec_context will return a token, and this can be sent if the transport
connection is working but is not strictly required.
>
> Thanks,
> Srini
>
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
