IETF Logo Mail Archive

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

Martin Rex <martin.rex@sap.com> Mon, 19 March 2007 17:11 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 1HTLOb-0002Hk-2p; Mon, 19 Mar 2007 13:11:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLOZ-0002Gh-1o; Mon, 19 Mar 2007 13:11:43 -0400
Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLO6-0004hP-4U; Mon, 19 Mar 2007 13:11:43 -0400
Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA09477; Mon, 19 Mar 2007 19:11:05 +0200 (MESZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200703191710.SAA06804@uw1048.wdf.sap.corp>
To: jhutz@cmu.edu
Date: Mon, 19 Mar 2007 18:10:54 +0100
In-Reply-To: <Pine.LNX.4.33L.0703181912540.1982-100000@minbar.fac.cs.cmu.edu> from "Jeffrey Hutzelman" at Mar 18, 7 07:23:50 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
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
Reply-To: martin.rex@sap.com
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

Jeffrey Hutzelman wrote:
> 
> More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly
> those cases where the peer is expected to send another token, and no
> others.

I fully agree.

Engineering-wise it is a pretty bad idea to cause (server) applications
to keep unnecessary state around (a proto security context that will
never get established) and remain tied up in the security context
establishment loop of the GSS-API security context establishment
exchange unless there is a real possibility that the handshake
on this security context will be continued and lead to a successful
completion.

-Martin

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

v2.23.0 | Report a Bug | By Email