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

Jeffrey Hutzelman <jhutz@cmu.edu> Sun, 18 March 2007 23:44 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 1HT53F-0005Cs-6D; Sun, 18 Mar 2007 19:44:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT53E-0005B8-8r for spkm@ietf.org; Sun, 18 Mar 2007 19:44:36 -0400
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT53D-0000WI-2b for spkm@ietf.org; Sun, 18 Mar 2007 19:44:36 -0400
Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa11486; 18 Mar 2007 19:44 EDT
Date: Sun, 18 Mar 2007 19:44:29 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
X-X-Sender: <jhutz@minbar.fac.cs.cmu.edu>
To: "Liqiang(Larry) Zhu" <lzhu@windows.microsoft.com>
In-Reply-To: <CAAAEFE273EAD341A4B02AAA9CA6F733051CAA9F@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <Pine.LNX.4.33L.0703181943400.1982-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: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: kitten@lists.ietf.org, andros@citi.umich.edu, Olga Kornievskaia <aglo@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 Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote:

> The intention of the text in -01 is that if a KRB-ERROR message should
> be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be
> returned.


Why?  How does the initiator handle these tokens?  If it does so in any
way other than by producing a new token, then the acceptor should not be
returning GSS_S_CONTINUE_NEEDED.



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