I have been reading more documents (always a bad idea) and I think that the architecture document probably needs to cover some requirements on the host protocol to be used with ABFAB. At this point in time I have the following issues that I think need to be checked:
1. What is the assumption that EAP uses when being transported over RADIUS/DIAMETER. Specifically does it make assumption that the transport is reliable and thus no retries ever need to be made. If this is the case then the same assumption would need to either be placed on the host protocol or on the service provider. 2. What are the trade-offs when running the server as an EAP pass-through service verses as a tunnel. Specifically what are the security and functionality requirements that are imposed. Two issues that I can think of are 1) is the EAP data masked from the server and 2) if the host protocol is not reliable, does the pass-through service need to provide the retry service. 3. It would do well to re-state the requirements from GSSAPI in the document - specifically that it is required the host protocol provide a reliable service that will deliver items to GSSAP in order. This means that an underlying protocol that wants to use UDP for some reason will have additional requirements placed on it that are not there for a TCP based service. 4. Can a host protocol be writing as a pure query/response system or does it need to support full bi-directional, full duplex functionality. Specifically are there any requirements from ABFAB itself (say from EAP) that make it impossible to run as a query/response system. For example, if an EAP server needs to do a re-try and generates a message to be sent down, can this occur? Is this going to be allowed by Radius/Diameter? Is it an issue for the host protocol to understand. These are issues that can be lost if one is looking just at the requirements of the host protocol. (I do not currently know if this is an issue for creating of a GSS-API context or not.) Jim _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
