Dan Harkins [mailto://dhark...@lounge.org] writes:
... > An EAP server asks "who are you?" and then > proceeds to prove the identity it is told using a method of its choice. > If the EAP method derives keys the keys have to be bound to a > consistent > view of the identities involved in the communication (including the NAS > identity). If the EAP server is successful in proving that the peer > really > is the identity it claimed (and the key is successfully bound to a > consistent view of all identities) there can still be other, > supplementary, > things to consider before deciding to grant access or not-- time-of- > day, > location, up-to-date anti-virus software, etc. But those other, > supplementary, things are not EAP, which is why you're mentioning a > "AAA > server" and not an "EAP server". > > We might want to make them part of EAP since EAP is the only protocol > allowed prior to the access decision being made Yes, it is, but it doesn't have to be. In IEEE 802.1X-2004, for example, the transition from the "Authenticating" state to the "Authenticated" state in the PAE machine is triggered by the reception of an Accept message from the Back-end authentication server, not by EAP-Success. In fact, great pains are taken to ensure that the "correct" EAP message (Success or Failure) is sent to the supplicant, the correctness being based not on the actual result of the EAP authentication but on the decision of the AAA server. > and it's attractive to > pass arbitrary data encapsulated in EAP. Actually, the only thing that's attractive about it (IMHO) is the fact that it is there. There are huge disadvantages to using EAP in this way that could be removed were a new protocol be designed for this purpose. ... _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
