On Wed, Oct 5, 2011 at 10:08 AM, Sam Hartman <[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.
It would be more accurate to say that the GSS-API mechanism can fail without a context token (a token which could only communicate the error, and supplementary information) to send to the other side, and that even when there is such an "error token" the application is not required to send it. Generally only the acceptor would produce an error token. However, it is good form for GSS mechanisms to both, specify and output such error tokens. It should be up to applications whether to send them. And, of course, applications must cope with errors that come with no error token. If EAP has no message suitable for constructing a GSS error token, well, either GSS-EAP could specify one, or you could leave it unspecified and c'est la vie. But spell this out :) Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
