Bret Jordan writes... > Now EAP back in the day may have been the brain child of > simple authentication for PPP links. However, today we need > to look into what is really needed to enforce Security Policies > on networks. It is my belief that regardless of the legacy name > given to the protocol, EAP, EAP makes a great transport for > dealing with the age old questions "is this user who they say they > are" which has been expanded in recent years to be, "is this user > who they say they are and are they using a company owned system > in the right part of the building at the right time of day).
It's not simply about legacies and names. It's about the rules for protocol usage. In the IETF these rules are typically called "applicability statements". These limit the area of intended use for a given protocol. This is not about what's implied by the name, it's about whether we follow the rules or attempt to circumvent them. All I'm suggesting is that we address the rule head on, instead of attempting to dance around it. > Even though the ID badge is valid. The ID badge grants the > holder to access certain resources, but the Security Guard > through visual inspection is able to make a better determination > of are these authentication credentials valid. Such procedures and meta-data are indeed related to authentication. However, that's not to say that *all* network access control policy is authentication meta-data. Some is; some isn't. > It is not that I am not authorized to use the systems at weird > hours, the system just knows that it is out side my normal usage > times and thus it may need to ask me follow up questions to verify > that I really am who I say I am. This is all about authentication. Well, that might be, but there is absolutely no reason that your normal hours of employment need to be communicated in an EAP message. In fact, it would seem much a more reasonable design that the AAA server's database contains such access control policies. I think your argument about the need for additional authentication meta-data is reasonable, but does not on face value justify the need to send that meta-data between an EAP client and EAP server. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
