IETF Logo Mail Archive

[SPKM] Re: Comments on draft-zhu-pku2u-01.txt

Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 20 March 2007 13:33 UTC

Return-path: <spkm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeSw-0002RI-TN; Tue, 20 Mar 2007 09:33:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTeSv-0002Ml-4Y for spkm@ietf.org; Tue, 20 Mar 2007 09:33:29 -0400
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTeSc-0001nE-J7 for spkm@ietf.org; Tue, 20 Mar 2007 09:33:29 -0400
Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa16160; 20 Mar 2007 7:32 EDT
Date: Tue, 20 Mar 2007 07:32:39 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
X-X-Sender: <jhutz@minbar.fac.cs.cmu.edu>
To: Martin Rex <martin.rex@sap.com>
In-Reply-To: <200703191629.RAA05702@uw1048.wdf.sap.corp>
Message-ID: <Pine.LNX.4.33L.0703200731170.15335-100000@minbar.fac.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org
Subject: [SPKM] Re: Comments on draft-zhu-pku2u-01.txt
X-BeenThere: spkm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Low Infrastructure Public Key GSS mechanism <spkm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/spkm>
List-Post: <mailto:spkm@ietf.org>
List-Help: <mailto:spkm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/spkm>, <mailto:spkm-request@ietf.org?subject=subscribe>
Errors-To: spkm-bounces@ietf.org

On Mon, 19 Mar 2007, Martin Rex wrote:

> An application that obtains a context token along with a fatal routine
> error from one of the context establishment calls (gss_accept_sec_context
> or gss_init_sec_context) is *NOT* required to send this to the peer.
> It may do so, but it may also shutdown the communication channel.
> I expect that a lot of applications will not actually send such a token
> (ours doesn't).

Well, that depends on the specification of the application - some
application protocols are as you describe, and some dictate one choice or
the other.  But the key point here is that CONTINUE_NEEDED means that a
token is expected from the peer, and should not be returned otherwise.

> Returning CONTINUE_NEEDED status when the mechanism spec does *NOT*
> define a clear method how to continue the context establishment
> handshake to successful completion is broken on my scorecard.

Agree.


_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm

v2.23.0 | Report a Bug | By Email