[15769] in Kerberos_V5_Development
Re: [Ietf-krb-wg] RFC 4121 - Context Deletion Tokens
daemon@ATHENA.MIT.EDU (Douglas E. Engert)
Fri May 7 10:58:45 2010
Message-ID: <4BE42AA4.6010500@anl.gov>
Date: Fri, 07 May 2010 09:58:44 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
MIME-Version: 1.0
To: Srinivas Cheruku <srinivas.cheruku@gmail.com>
In-Reply-To: <4be396be.1437720a.6c51.63ac@mx.google.com>
Cc: ietf-krb-wg@anl.gov, mrex@sap.com, krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Srinivas Cheruku wrote:
>
>> -----Original Message-----
>> From: Martin Rex [mailto:mrex@sap.com]
>>
>> Srinivas Cheruku wrote:
>> >
>> > So, in GSSAPi v2, the delete_sec_context() should be called by peers
>> > independently
>> >
>> > - Maybe this is the reason why RFC 4121 states the same.
>> >
>> > Does this mean that the application should have its own way of
>> ending a
>> > session and no GSS is involved in doing so?
>>
>>
>> Personally, I think so.
>>
>> IIRC, FTP with GSS-API extension is using an empty protected message
>> to "securely" convey the end of the data transfer.
>>
> [Srinivas Cheruku] So, sending empty protected message is not a standard
> according GSSAPI V2 and is still supported by some apps. How does SAP
> software e.g. SAPGui and SAP Sever deal with context deletion tokens e.g.
> how will SAP signal ending the session - using GSS-API token or its own way?
>
>> I argued for deprecating the context deletion token in GSS-API v2,
>> because in a lot of layered software architectures it is somewhat
>> difficult to indicate both, a fatal error and the need to transport
>> a token to the peer. Most software, when encountering a fatal error,
>> will just close the network connection.
>>
>> In layered software, it is much easier to deal with app-level
>> concious termination "handshake" of a communication that is
>> error-free at the transport (protection) layer.
>>
>> It is also very app-specific how to cope with a communication
>> failure (e.g. lost network connectivity) at some point in the
>> middle of a communication, and which stuff to commit/save and
>> which stuff to roll-back.
>>
>
> [Srinivas Cheruku] Sorry, but I still didn't understand the logic behind
> deprecating context deletion token in GSS-API v2. Yes, I understand that
> most of the software when encountering fatal error will just close the
> network connection. But still I think that it would be good to support
> context deletion token so that when all goes well, the peer can signal
> context deletion when required.
> Maybe I am not looking at the big picture?
Could be. In most cases GSSAPI is used to protect existing protocols,
that already have a way to signal termination.
>
>>
>> >
>> > So, why MIT code is still generating context deletion token
>> > with TOK_ID 0x0405?
>>
>> Backwards interop, I assume. That token is likely ignored (and
>> hopefully
>> passed to gss_release_buffer()) by the calling application.
>>
>>
> [Srinivas Cheruku] GSS-API v1 TOK_ID for context deletion token is 0x0102.
> Maybe there are no interoperable applications that are using MIT GSS-API
> code and sending the delete context token to peer to signal end of the
> session.
>
There might be, but it only signals the the peer's GSSAPI that it can close
the GSSAPI context not necessarily the applications session. The application
could continue to run without using wrap/unwrap or even establish a new GSSAPI
context on both ends and go back to using wrap/unwrap.
> 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
