>>>>> "Nico" == Nico Williams <[email protected]> writes:
Nico> On Wed, Oct 5, 2011 at 10:08 AM, Sam Hartman
Nico> <[email protected]> wrote:
>>>>>>> "Jim" == Jim Schaad <[email protected]> writes:
>> Â Â Jim> 1. Â In section 1.2, under what
>> circumstances would an acceptor   Jim> fail to
>> respond to an initiator short of a transport failure? Â
>> Jim> Can this ever happen in a success case? Â If it cannot
>> then I Â Â Jim> would suggest that /acceptor may
>> respond/ be changed to   Jim> /acceptor responds/
>>
>> I've made the change. Technically some protocols declare failure
>> at a level higher than GSS and abandon the authentication at the
>> GSS layer. In this case, the acceptor never responds at the gss
>> layer ever though gss has not failed. However, I don't think
>> this complexity is worth going into so I've adopted your proposed
>> change.
Nico> It would be more accurate to say that the GSS-API mechanism
Nico> can fail without a context token (a token which could only
Nico> communicate the error, and supplementary information) to send
Nico> to the other side, and that even when there is such an "error
Nico> token" the application is not required to send it. Generally
Nico> only the acceptor would produce an error token.
While this is a true statement, it's independent of what I was getting
at. My statement still stands. Some protocols decide to abandon a gss
authentication progress for their own reasons.
It's also true that gss mechanisms fail.
Luke has already pointed out we have an error token. It's described in
the draft; the registry of values to go in it not yet.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
