IETF Logo Mail Archive

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

Martin Rex <martin.rex@sap.com> Mon, 19 March 2007 15:41 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 1HTJzQ-0005A7-A8; Mon, 19 Mar 2007 11:41:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJzP-00059y-77; Mon, 19 Mar 2007 11:41:39 -0400
Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJz4-0006H4-Tt; Mon, 19 Mar 2007 11:41:39 -0400
Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA16274; Mon, 19 Mar 2007 17:38:31 +0200 (MESZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200703191538.QAA04559@uw1048.wdf.sap.corp>
To: lzhu@windows.microsoft.com
Date: Mon, 19 Mar 2007 16:38:04 +0100
In-Reply-To: <CAAAEFE273EAD341A4B02AAA9CA6F733051CA960@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> from "Liqiang" at Mar 16, 7 07:01:09 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-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: kitten@lists.ietf.org, andros@citi.umich.edu, aglo@citi.umich.edu, Michael.Eisler@netapp.com, spkm@ietf.org, jhutz@cmu.edu
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

Liqiang wrote:
> 
> This is not necessary accurate. In the User2User protocol,
> http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt,
> the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status.

IIRC, the user2user implementation shipped by Microsoft uses a
mechanism OID different from rfc-1964/rfc-4121.

Technically, the "context establishment handshake" is opaque to the 
application.  It is conceivable to define a context establishment handshake
that negotiates (optional) features in multiple steps, and the names
of intermediate tokens are just an implementation detail.  However, the spec
of a mechanism ought to be sufficiently clear that everyone can implement
optional multi-step negotiations reliably in an interoperable fashion.

Retrofitting KRB_ERROR + CONTINUE_NEEDED for rfc-1964 and successors
should NOT break implementations based on the original specs,
which likely do not support this.

-Martin

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

v2.23.0 | Report a Bug | By Email