Hi Sam,
>>>>>> "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. This is not necessarily an "abort" case. We are talking about either the EAP layer or the EAP authentication method layer dropping an incoming message (due to various reasons, such as lack of resources, malformed message [by rogue injection, or otherwise], etc.). Such a single packet dropped does not always convert to "abort". The EAP Authenticator retransmits and see what happens. This "message dropped" happening is either at the EAP layer or the EAP authentication method layer. How does it get signaled to the "EAP lower layer"? That's what you need. Is there an API that's commonly implemented by the EAP layers and EAP authentication methods supporting this? (Here's an analogy: TCP hands over a message to the application, and application drops it for one if its own "higher layer" reasons. It's not going to tell TCP that it tossed away the packet.) Alper > 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
