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

Martin Rex wrote:
> Jeffrey Hutzelman wrote:
>   
>> 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.
>>     
>
> Actually, that is not completely accurate.
>
> 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).
>   
I agree with Jeff that GSS_S_CONTINUE implies another token is coming. I 
also agree with Martin and disagree with Jeff on the issue of handling 
an output token when gss_accept_sec_context() fails. What I would like 
to highlight is the fact that the current draft requires serious 
clarifications when it comes to handling error cases!

GSS API guarantees that an output will be sent if the GSS_S_CONTINUE is 
returned. Thus if you want to convey error details (KRB-ERROR) to your 
peer, then you should return GSS_S_CONTINUE. However this brings me back 
to my original point that the server is left hanging (ie, keeping 
state). As others pointed out, using up resources on the server is not 
desirable.

As I was looking at error tokens in GSS API in general (and also related 
to SPKM3), I was scratching my head trying to figure out how can one 
make use of error tokens as in any GSS mechanism they seem to present 
the problem we are discussing right now. I came to the conclusion that 
error tokens can't be used and we just have to do with error status 
codes. Therefore, I think this spec should be changed to say that on 
failure an error code should be returned instead of the GSS_S_CONTINUE. 
I'm not sure whether or not saying the following is beneficial: that 
KRB-ERROR token could be returned as well but it is up to the GSS 
application to decide whether such output token is sent to the peer.

>> 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.
>>     
> 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.
>   
Agreed!

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