>>>>> "Jim" == Jim Schaad <[email protected]> writes:
Jim> I think he was talking about the RADIUS server not having any
Jim> EAP data to send back to the client. And that in that case the
Jim> server SHOULD send a reject message back.
Jim> I am looking at the case of the EAP client not having any data
Jim> to send. The RADIUS server will not have an opportunity to
Jim> send a reject message, but it will still have some state data
Jim> for a while (as will the EAP server).
OK.
I'm sorry, I should not have tried to respond to mail while paying
attention to a session in a conference.
What happens here on the initiator is that the initiator needs to return
some status other than GSS_S_CONTINUE_NEEDED.
GSS_S_COMPLETE is kind of implausible, so GSS_ERROR will be true for
that status.
The initiator then should call gss_delete_sec_context. At this point, the
initiator is done and has cleaned up state.
Alper claims that the initiator will not know that the EAP layers have
failed to produce output and are done processing the packet. I cannot
think of a plausible EAP implementation strategy with this
characteristic, so I suspect Alper is not correct for likely EAP
implementations. Anything that lets you examine the RFC 4137 state will
allow you to determine what's going on. Certainly anything that you can use for
implementing
GSS-EAP has the property that you'll know when it's done with a packet.
The existing GSS C bindings are sufficiently synchronous that you'll
need that property.
After experimenting with other strategies, we've generally come to the
conclusion that applications rather than GSS mechanisms need to be
responsible for signaling initiator failure.
In some protocols you do this with a TCP close.
In some protocols such as IMAP, there's a SASL abort that you signal.
I think that the GSS mechanism could return an error token at this
point; a quick reading of RFC 2743 2.2.1 is unclear.
However, I'd recommend against changing gss-eap to permit this.
I think returning an output token with an error status will confuse a
lot of applications.
I do think it would be desirable to add text to draft-ietf-abfab-arch
noting that applications SHOULD have a way to signal authentication
aborts.
--Sam
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
