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

Jeffrey Hutzelman <jhutz@cmu.edu> Sun, 18 March 2007 23:59 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 1HT5HM-0004wx-AU; Sun, 18 Mar 2007 19:59:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HT5HL-0004ui-Kq for spkm@ietf.org; Sun, 18 Mar 2007 19:59:11 -0400
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HT5HK-0001mw-EO for spkm@ietf.org; Sun, 18 Mar 2007 19:59:11 -0400
Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa11507; 18 Mar 2007 19:58 EDT
Date: Sun, 18 Mar 2007 19:58:50 -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: <CAAAEFE273EAD341A4B02AAA9CA6F733051CAAA1@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <Pine.LNX.4.33L.0703181955190.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: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: spkm@ietf.org, andros@citi.umich.edu, kitten@lists.ietf.org, Michael.Eisler@netapp.com
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:

> Jeffrey Hutzelman wrote:
> > 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.
>
> The deployment experience shows that if the client (instead of the
> acceptor or the KDC) can log the error information, the cost of trouble
> shooting is significantly lower.
>
> If the acceptor returns a KRB_ERROR message with a status that is
> anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in
> fact very unlikely that the trouble-shooting information can make it to
> the client side in order to get logged.

No; you are confused.  GSS_S_CONTINUE_NEEDED does not mean "there is a
token to send to the peer".  It means "another token is expected from the
peer".  Any token produced by GSS_Accept_sec_context should be sent to the
peer regardless of the returned status code.

Behaving otherwise violates the abstraction and will break application
protocols which expect the GSS-API to behave as specified, regardless of
which mechanism is being used.



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