From jari.arkko@piuha.net Sun Jun 1 18:47:18 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 01 Jun 2003 20:47:18 +0300 Subject: [eap] issue 121 (meaning of successful authentication) In-Reply-To: References: Message-ID: <3EDA3C26.7090804@piuha.net> Alper Yegin wrote: >>We appear to have consensus that the various different >>indications should agree. > > > I think we should agree on the semantics of each one of these "indications". > Do they all mean "authentication", or all "authorization", or a static mix > of both, or a dynamic mix of both (e.g., method indication may mean auth or > authz, depending on the method)? Once we separate which ones mean what, then > yes, the same types should all agree. This a part of the problem: there's a number of inputs to the process (auth & authz), but we do not always have multiple outputs. For instance, with a non-mutually authenticating method, we only have the Success/Failure to work with. So, we may not always be able to give full information to the peer about the reason of the failure. Furthermore, the same indication has to be used for multiple purposes in this case. This leads me to think that its better to documents what the inputs are to the process, but keep the outputs the same. Of course, if specific methods have informative messages (as in EAP TLS), those can tell more. --Jari From jari.arkko@piuha.net Sun Jun 1 21:56:25 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 01 Jun 2003 23:56:25 +0300 Subject: [eap] issue 121: failed auth & succeeded authz? Message-ID: <3EDA6879.4010802@piuha.net> Bernard, as a part of the writeup on issue 121, you wrote the following: > Even with the changes made in Issue 116, I think it is possible for an > authenticator to allow access to a peer which has failed to authenticate > to it. Presumably this would occur with restricted access, so that the > peer might have a chance to correct the deficiency (e.g. signup for an > account, send an email to get help, etc.). I think that would need to be > done with a method that either was one-way, or where the peer successfully > authenticated the authenticator. Might want to double check whether > there are any other "gotchas" in the draft bearing on this. Thinking more closely about this, I'm starting to doubt whether this is possible. The concern that I have relates to situations where EAP produces keys for some purpose. If the authentication fails, there generally aren't any keys available. So how would the peer and the NAS proceed in an environment that requires the keys? Or is the intention that you can only do this if you can proceed to access without keys? Or you can only do this while inside a tunnel? And if you were inside the tunnel, are there any mitm issues involved? So, to me this is starting to sound very complicated. Can you cite a practical case where this is needed? 802.11i authentication with EAP, lack of credentials, downgrade to good old webpage-based login? But does this happen as a part of EAP or as a part of link-layer procedures? --Jari From jari.arkko@piuha.net Sun Jun 1 23:07:39 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 02 Jun 2003 01:07:39 +0300 Subject: [eap] issue 121 (meaning of successful authentication) In-Reply-To: <3ED76A5E.9060400@piuha.net> References: <3ED76A5E.9060400@piuha.net> Message-ID: <3EDA792B.8060804@piuha.net> Suggested text, modified based on what the issue site already contained. Add to the terminology section: "Successful authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access for the peer, and the peer decides to use this access. Note that the authenticator's decision typically involves both authentication and authorization aspects; the peer may provide correct input for the authentication method but not be allowed to access due to policy reasons. " Change the following text in Section 4.2 from: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, the authenticator cannot know whether they have been received. As a result, these packets are not retransmitted by the authenticator. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. Since only a single EAP authentication method is supported within an EAP conversation, a peer that successfully authenticates the authenticator MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link." To: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. On the peer, once the method completes unsuccessfully, the EAP conversation is terminated, the link is disabled, and a Success packet MUST be silently discarded by the peer. As a result, loss of a Failure packet need not result in a timeout. As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. A peer that successfully authenticates the authenticator MUST silently discard Failure packets and MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link. Where the authenticator wishes to deny access even where the peer authenticated successfully (e.g. where the peer is not currently authorized to get access), this can result in lengthy timeouts unless either the method provides authorization-related error messages or a lower layer failure indication is provided. For example, within EAP-TLS [RFC2716], the "access_denied" TLS alert can be used to indicate that a valid certificate was received, but when access control was applied, the authenticator decided not to proceed. If a method provides such error messages, the authenticator SHOULD use them and SHOULD provide information that agrees with the final decision of the authenticator. Section 3.4 provides guidance on the processing of lower layer success and failure indications." From aboba@internaut.com Sun Jun 1 22:51:57 2003 From: aboba@internaut.com (Bernard Aboba) Date: Sun, 1 Jun 2003 14:51:57 -0700 (PDT) Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <3EDA6879.4010802@piuha.net> References: <3EDA6879.4010802@piuha.net> Message-ID: > Thinking more closely about this, I'm starting to doubt whether > this is possible. It is one thing for the peer to assert that "I do not have a valid account and credentials and would like to create them." In such a case (which might or might not involve EAP), the peer might want to verify the server identity, but since it doesn't have a userid and credentials, the server can't verify its identity. It is another thing for the peer to assert "I have a valid account with a userid and credentials" and then to fail to prove the validity of that assertion. > The concern that I have relates to situations where EAP produces > keys for some purpose. If the authentication fails, there generally > aren't any keys available. In tunneled methods, keys can be derived without the peer needing to prove its identity. However I do think it is fair to say that the AAA server should not be providing keys to a NAS in the event of a failed authentication. In fact, the RFC 2548 keying AVPs are not valid within an Access-Reject message, which I believe needs to be carried forward into Diameter. RFC 2869bis discourages situations where the EAP outcome and AAA outcome are different, so that if the AAA outcome is a Reject, then the recommended EAP packet enclosed is a Failure. Based on this, even if the EAP peer and AAA server were to derive keys, in the event that EAP authentication fails, the NAS would not obtain keys and therefore they could not be used to encrypt data between the peer and NAS. > So how would the peer and the NAS proceed > in an environment that requires the keys? I'd argue that if EAP is being used in an environment that requires keys, then EAP SHOULD be used to derive those keys, so that the result of the authentication is tied to subsequent per-packet protection. Perhaps RFC 2284bis needs to state that explicitly. Given that an authentication failure does not result in keys being present on both the peer and the NAS, that would argue that the peer and NAS cannot proceed in such a circumstance. On the other hand, it may be true that keys are not required. However, in that case ("open authentication") I'm not clear why EAP would be needed. > you can only do this while inside a tunnel? And if you were inside > the tunnel, are there any mitm issues involved? I think what may be going on here is that you have a one-way authentication exchange (server -> client) that derives keys, followed by some kind of signup process that results in a user/password being created. However, in that case, assuming that the account gets created (e.g. credit card validation succeeds), then the authentication has been successful, and the user can be allowed on, with the access presumably being billed to the newly created account. So when examined more closely, this is really just like a normal tunneled authentication exchange. However, if the account creation fails, it seems undesirable to allow access at that point -- this looks like any other tunnel method where the inner authentication fails. In such a case, the keys cannot be used to encrypt data, since they don't correspond to an authenticated session. > So, to me this is starting to sound very complicated. Actually, I think it's quite simple :) There appears to be no justification for allowing access in the case where authentication is attempted and fails. > Can you cite a practical case where this is needed? It would appear possible to carry out the scenarios described without requiring that access be provided in event of a failed authentication. Given this, it seems hard to argue for "flexibility", particularly when this could create a security problem. From jari.arkko@piuha.net Mon Jun 2 06:51:22 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 02 Jun 2003 08:51:22 +0300 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: References: <3EDA6879.4010802@piuha.net> Message-ID: <3EDAE5DA.10007@piuha.net> Bernard Aboba wrote: > Actually, I think it's quite simple :) There appears to be no > justification for allowing access in the case where authentication is > attempted and fails. Ok. Updated text suggestion below: Add to the terminology section: "Successful authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access for the peer, and the peer decides to use this access. Note that the authenticator's decision typically involves both authentication and authorization aspects; the peer may provide correct input for the authentication method but not be allowed to access due to policy reasons." Change the following text in Section 4.2 from: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, the authenticator cannot know whether they have been received. As a result, these packets are not retransmitted by the authenticator. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. Since only a single EAP authentication method is supported within an EAP conversation, a peer that successfully authenticates the authenticator MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link." To: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. On the peer, once the method completes unsuccessfully, the EAP conversation is terminated, the link is disabled, and a Success packet MUST be silently discarded by the peer. As a result, loss of a Failure packet need not result in a timeout. As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. A peer that successfully authenticates the authenticator MUST silently discard Failure packets and MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link. The authenticator MAY deny access even where the peer authenticated successfully within the method. For instance, the authenticated peer may not currently be authorized to get access. However, this can result in lengthy timeouts unless either the method provides authorization-related error messages or a lower layer failure indication is provided. For example, within EAP-TLS [RFC2716], the "access_denied" TLS alert can be used to indicate that a valid certificate was received, but when access control was applied, the authenticator decided not to proceed. If a method provides such error messages, the authenticator SHOULD use them and SHOULD provide information that agrees with the final decision of the authenticator. Section 3.4 provides guidance on the processing of lower layer success and failure indications. The authenticator MUST NOT grant access if the authentication method was unsuccessful." From aboba@internaut.com Mon Jun 2 16:06:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 2 Jun 2003 08:06:35 -0700 (PDT) Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <3EDAE5DA.10007@piuha.net> References: <3EDA6879.4010802@piuha.net> <3EDAE5DA.10007@piuha.net> Message-ID: I've edited the suggested fix a bit. Does the following text maintain your intent? Add to the terminology section: "Successful authentication In the context of this document, "successful authentication" is an exchange of EAP messages, as a result of which the authenticator decides to allow access by the peer, and the peer decides to use this access. The authenticator's decision typically involves both authentication and authorization aspects; the peer may successfully authenticate to the authenticator but access may be denied by the authenticator due to policy reasons." Change the following text in Section 4.2 from: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, the authenticator cannot know whether they have been received. As a result, these packets are not retransmitted by the authenticator. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. Since only a single EAP authentication method is supported within an EAP conversation, a peer that successfully authenticates the authenticator MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link." To: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. Within a mutually authenticating method, if the authenticator fails to authenticate to the peer, the peer terminates the EAP conversation, disables the link and the peer MUST silently discard a Success packet. As a result, loss of a Failure packet need not result in a timeout. A peer that successfully authenticates the authenticator MUST silently discard Failure packets and MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link. The authenticator MUST NOT grant access if the authentication method was unsuccessful. The authenticator MAY deny access even where the peer authenticated successfully within the selected EAP method, since the authenticated peer may not be authorized for network access. However, this can result in lengthy timeouts unless either the method provides authorization-related error messages or a lower layer failure indication is provided. For example, within EAP-TLS [RFC2716], the "access_denied" TLS alert can be used to indicate that a valid certificate was received, but when access control was applied, the authenticator decided not to proceed. If a method provides such error messages, the authenticator SHOULD use them so as to ensure consistency with the final decision of the authenticator. Section 3.4 provides guidance on the processing of lower layer success and failure indications." From jsalowey@cisco.com Mon Jun 2 17:31:19 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Mon, 2 Jun 2003 09:31:19 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <3EDAE5DA.10007@piuha.net> Message-ID: <004601c32924$6626dbd0$0200000a@amer.cisco.com> > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Jari Arkko > Sent: Sunday, June 01, 2003 10:51 PM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: [eap] Re: issue 121: failed auth & succeeded authz? > > > Bernard Aboba wrote: > > > Actually, I think it's quite simple :) There appears to be no > > justification for allowing access in the case where > authentication is > > attempted and fails. > > Ok. Updated text suggestion below: > > Add to the terminology section: > > "Successful authentication > > In the context of this document, "successful authentication" > is an exchange of EAP messages, as a result of which the > authenticator decides to allow access for the peer, and the > peer decides to use this access. Note that the > authenticator's decision typically involves both > authentication and authorization aspects; the peer may > provide correct input for the authentication method but not > be allowed to access due to policy reasons." > > Change the following text in Section 4.2 from: > > "EAP Success or Failure packets MUST NOT be sent by an EAP > server prior to completion of the final round of a given > method. A peer EAP implementation receiving a Success or > Failure packet prior to completion of the method in progress > MUST silently discard it. By default, an EAP peer MUST > silently discard a "canned" EAP Success message (an EAP > Success message sent immediately upon connection). This > ensures that a rogue authenticator will not be able to bypass > mutual authentication by sending an EAP Success prior to > conclusion of the EAP method conversation. > > Implementation Note: Because the Success and Failure packets > are not acknowledged, the authenticator cannot know whether > they have been received. As a result, these packets are not > retransmitted by the authenticator. If acknowledged result > indications are desired, these MAY be implemented within > individual EAP methods. Since only a single EAP > authentication method is supported within an EAP > conversation, a peer that successfully authenticates the > authenticator MAY, in the event that an EAP Success is not > received, conclude that the EAP Success packet was lost and > enable the link." > > To: > > "EAP Success or Failure packets MUST NOT be sent by an EAP > server prior to completion of the final round of a given > method. A peer EAP implementation receiving a Success or > Failure packet prior to completion of the method in progress > MUST silently discard it. By default, an EAP peer MUST > silently discard a "canned" EAP Success message (an EAP > Success message sent immediately upon connection). This > ensures that a rogue authenticator will not be able to bypass > mutual authentication by sending an EAP Success prior to > conclusion of the EAP method conversation. > > Implementation Note: Because the Success and Failure packets > are not acknowledged, they are not retransmitted by the > authenticator, and may be potentially lost. A peer MUST allow > for this circumstance. If acknowledged result indications are > desired, these MAY be implemented within individual EAP methods. > > On the peer, once the method completes unsuccessfully, the > EAP conversation is terminated, the link is disabled, and a > Success packet MUST be silently discarded by the peer. As a > result, loss of a Failure packet need not result in a timeout. > > As described in Section 2.1, only a single EAP authentication > method is allowed within an EAP conversation. A peer that > successfully authenticates the authenticator MUST silently > discard Failure packets and MAY, in the event that an EAP > Success is not received, conclude that the EAP Success packet > was lost and enable the link. > > The authenticator MAY deny access even where the peer > authenticated successfully within the method. For instance, > the authenticated peer may not currently be authorized to get > access. However, this can result in lengthy timeouts unless > either the method provides authorization-related error > messages or a lower layer failure indication is provided. For > example, within EAP-TLS [RFC2716], the "access_denied" TLS > alert can be used to indicate that a valid certificate was > received, but when access control was applied, the > authenticator decided not to proceed. If a method provides > such error messages, the authenticator SHOULD use them and > SHOULD provide information that agrees with the final > decision of the authenticator. Section 3.4 provides guidance > on the processing of lower layer success and failure indications. > > The authenticator MUST NOT grant access if the authentication > method was unsuccessful." > [Joe] Hmmm.. What does it mean that an authenticaiton method was unsuccessful? Is it that the Peer or authenticator could not be identified? Is it that the key exchange failed? It is possible for one to succeed without the other. Access is not necessarily a binary decision. It is possible to grant limited access even if the peer could not be identified. I think I agree that if key exchange was required and failed that this may cause a fundamental problem is some systems, but not all. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From Pasi.Eronen@nokia.com Mon Jun 2 17:48:27 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Mon, 2 Jun 2003 19:48:27 +0300 Subject: [eap] Re: issue 121: failed auth & succeeded authz? Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB10@esebe023.ntc.nokia.com> Jari Arkko wrote: > ... > Implementation Note: Because the Success and Failure packets are > not acknowledged, they are not retransmitted by the authenticator, > and may be potentially lost. A peer MUST allow for this circumstance. > If acknowledged result indications are desired, these MAY be > implemented within individual EAP methods. >=20 > On the peer, once the method completes unsuccessfully, the EAP > conversation is terminated, the link is disabled, and a Success > packet MUST be silently discarded by the peer. As a result, > loss of a Failure packet need not result in a timeout. >=20 > As described in Section 2.1, only a single EAP authentication method > is allowed within an EAP conversation. A peer that successfully > authenticates the authenticator MUST silently discard Failure packets > and MAY, in the event that an EAP Success is not received, conclude > that the EAP Success packet was lost and enable the link. > > The authenticator MAY deny access even where the peer > authenticated successfully within the method. For instance, the > authenticated peer may not currently be authorized to > get access. However, this can result in lengthy timeouts unless > either the method provides authorization-related error messages or > a lower layer failure indication is provided. For example, > within EAP-TLS [RFC2716], the "access_denied" TLS alert can be > used to indicate that a valid certificate was received, but when > access control was applied, the authenticator decided not to proceed. > If a method provides such error messages, the authenticator SHOULD use > them and SHOULD provide information that agrees with the final > decision of the authenticator. Section 3.4 provides guidance > on the processing of lower layer success and failure indications. >=20 > The authenticator MUST NOT grant access if the authentication method > was unsuccessful." I don't think this quite captures the desired behavior...=20 it doesn't really matter if the method is mutually authenticating or not.=20 How about this? "Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstances as described in this note. See also Section 3.4 for guidance on the processing of lower layer success and failure indications. As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. Individual EAP methods MAY implement their own acknowledged result indications. If these indications are used, they MUST provide information that agrees with the final decision of the authenticator. On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a method-specific failure indication, or the peer decides that it does want to continue talking to this authenticator), the link is disabled and the EAP conversation is terminated (and any Success and Failure packets are silently discarded). If the authenticator has sent a method-specific success indication, the peer MUST silently discard Failure packets, and MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link. (Note that the peer does not enable the link immediately after receiving the method-specific success indication, since it may be necessary to retransmit the last EAP Response packet.) If the authenticator has not sent any method-specific result indication, and the peer still wants to talk to this authenticator, once the method completes the peer waits for a Success or Failure packet (and cannot silently discard either of them). In the event that neither a Success nor Failure packet is received, the peer SHOULD disable the link to avoid lengthy timeouts in case the lost packet was an EAP Failure." I don't think it's necessary to explicitly forbid the case of allowing access when the authenticator has not verified who the peer is. In most methods, the peer can't tell the difference anyway: e.g., if in EAP-TLS the authenticator simply ignores the certificate given by the peer, nobody will know. The problematic case (the authenticator first says "failure, go away", and then changes its mind) is already=20 forbidden above. Best regards, Pasi From jari.arkko@piuha.net Mon Jun 2 18:59:40 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 02 Jun 2003 20:59:40 +0300 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <004601c32924$6626dbd0$0200000a@amer.cisco.com> References: <004601c32924$6626dbd0$0200000a@amer.cisco.com> Message-ID: <3EDB908C.2080208@piuha.net> Joseph Salowey wrote: > [Joe] Hmmm.. What does it mean that an authenticaiton method was > unsuccessful? Is it that the Peer or authenticator could not be > identified? Is it that the key exchange failed? It is possible for one > to succeed without the other. Access is not necessarily a binary This is largely a method specific issue. In some methods everything happens in one go, and you can't fail key exchange if user authentication as such succeeded. > decision. It is possible to grant limited access even if the peer could > not be identified. I think I agree that if key exchange was required > and failed that this may cause a fundamental problem is some systems, > but not all. In earlier e-mails on the list we started to get a sense that while it would be technically possible to allow EAP to continue after an authentication failure, this appears unnecessary. Better schemes exist, such as tunneled server auth + credit card "auth" inside the tunnel. With these better schemes we do not need to continue after an authentication failure. I get a better feeling from that ;-) --Jari From jari.arkko@piuha.net Mon Jun 2 18:40:19 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 02 Jun 2003 20:40:19 +0300 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: References: <3EDA6879.4010802@piuha.net> <3EDAE5DA.10007@piuha.net> Message-ID: <3EDB8C03.4040505@piuha.net> Bernard Aboba wrote: > I've edited the suggested fix a bit. Does the following text maintain your > intent? Yes. Looks better. --Jari > Add to the terminology section: > > "Successful authentication > > In the context of this document, "successful authentication" > is an exchange of EAP messages, as a result of which the > authenticator decides to allow access by the peer, and the > peer decides to use this access. The authenticator's > decision typically involves both authentication and > authorization aspects; the peer may successfully > authenticate to the authenticator but access may be denied > by the authenticator due to policy reasons." > > Change the following text in Section 4.2 from: > > "EAP Success or Failure packets MUST NOT be sent by an EAP server > prior to completion of the final round of a given method. A peer EAP > implementation receiving a Success or Failure packet prior to > completion of the method in progress MUST silently discard it. By > default, an EAP peer MUST silently discard a "canned" EAP Success > message (an EAP Success message sent immediately upon connection). > This ensures that a rogue authenticator will not be able to bypass > mutual authentication by sending an EAP Success prior to conclusion > of the EAP method conversation. > > Implementation Note: Because the Success and Failure packets are > not acknowledged, the authenticator cannot know whether they have > been received. As a result, these packets are not retransmitted by > the authenticator. If acknowledged result indications > are desired, these MAY be implemented within individual EAP > methods. Since only a single EAP authentication method is > supported within an EAP conversation, a peer that successfully > authenticates the authenticator MAY, in the event that an EAP > Success is not received, conclude that the EAP Success packet was > lost and enable the link." > > To: > > "EAP Success or Failure packets MUST NOT be sent by an EAP server > prior to completion of the final round of a given method. A peer EAP > implementation receiving a Success or Failure packet prior to > completion of the method in progress MUST silently discard it. By > default, an EAP peer MUST silently discard a "canned" EAP Success > message (an EAP Success message sent immediately upon connection). > This ensures that a rogue authenticator will not be able to bypass > mutual authentication by sending an EAP Success prior to > conclusion of the EAP method conversation. > > Implementation Note: Because the Success and Failure packets are > not acknowledged, they are not retransmitted by the authenticator, > and may be potentially lost. A peer MUST allow for this circumstance. > If acknowledged result indications are desired, these MAY be > implemented within individual EAP methods. > > As described in Section 2.1, only a single EAP authentication method > is allowed within an EAP conversation. Within a > mutually authenticating method, if the authenticator fails > to authenticate to the peer, the peer terminates the > EAP conversation, disables the link and the peer MUST > silently discard a Success packet. As a result, > loss of a Failure packet need not result in a timeout. > A peer that successfully authenticates the authenticator MUST > silently discard Failure packets and MAY, in the event that > an EAP Success is not received, conclude that the EAP Success > packet was lost and enable the link. > > The authenticator MUST NOT grant access if the authentication method > was unsuccessful. The authenticator MAY deny access even where the peer > authenticated successfully within the selected EAP method, since the > authenticated peer may not be authorized for network access. > However, this can result in lengthy timeouts unless > either the method provides authorization-related error messages or > a lower layer failure indication is provided. For example, > within EAP-TLS [RFC2716], the "access_denied" TLS alert can be > used to indicate that a valid certificate was received, but when > access control was applied, the authenticator decided not to proceed. > If a method provides such error messages, the authenticator SHOULD use > them so as to ensure consistency with the final > decision of the authenticator. Section 3.4 provides guidance > on the processing of lower layer success and failure indications." > > > > From aboba@internaut.com Mon Jun 2 18:36:38 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 2 Jun 2003 10:36:38 -0700 (PDT) Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB10@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BB10@esebe023.ntc.nokia.com> Message-ID: I think there is an issue with text relating to "enabling the link" because in fact the link really must only be enabled when it is usable, or "link up" triggers will cause all kinds of havoc (like DHCP packets being triggered and sent into the bit bucket, IPv4 linklocal addresses being assigned, etc.). In most link technologies, the link is not truly usable for IP traffic until later. For example, in PPP NCP needs to be concluded; in IEEE 802.11, the 4-way handshake needs to be concluded. As a result, I believe that text indicating that the link should be enabled on successful authentication is misleading and needs to be clarified or removed entirely. The part about disabling the link is ok though. I'd also note that where acknowledged result indications are provided, both sides need to indicate success for the peer to consider the authentication successful. Even if the authenticator is happy, if the peer is not happy (e.g. the authenticator failed to authenticate to it) it is not going to consider the authentication successful. Also, Jari's suggested text relating to authorization error messages seems useful and I think it should be retained. How about this? "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. See also Section 3.4 for guidance on the processing of lower layer success and failure indications. As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. Individual EAP methods MAY implement their own acknowledged result indications. If these indications are used, the authenticator MUST provide a result indication that is consistent with its final decision. That is, a Failure packet MUST only be sent after a method-specific failure indication, and a Success packet MUST only be sent after a method-specific success indication. On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a method-specific failure indication, or the peer decides that it does want to continue talking to this authenticator), the peer MUST terminate the EAP conversation and disable the link. The peer MUST silently discard Success packets and MAY silently discard Failure packets. As a result, loss of a Failure packet need not result in a timeout. On the peer, where an acknowledged result indication is provided, and the method concludes successfully on both sides, a Failure packet MUST be silently discarded by the peer. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and subsequently enable the link. A mutually authenticating method such as EAP-TLS [RFC2716] that provides authorization error messages is considered to provide acknowledged result indications for the purpose of this specification. For example, within EAP-TLS, the peer authenticates the authenticator, and sends TLS-alert messages in the event of an authentication failure. Similarly, the authenticator authenticates the peer, and the "access_denied" TLS alert can be used by the authenticator to indicate that a valid certificate was received from the peer, but when access control was applied, the authenticator decided not to proceed. If a method provides authorization error messages, the authenticator SHOULD use them so as to ensure consistency with the final access decision and avoid lengthy timeouts. If the authenticator has not sent any method-specific result indication, and the peer still wants to talk to this authenticator, once the method completes the peer waits for a Success or Failure packet (and MUST NOT silently discard either of them). In the event that neither a Success nor Failure packet is received, the peer SHOULD disable the link to avoid lengthy timeouts in case the lost packet was an EAP Failure. The authenticator MUST NOT grant access by sending a Success packet if the peer did not successfully authenticate to it. Where the authenticator wishes to deny access even where the peer authenticated successfully (e.g. where the peer is not currently authorized for network access), the authenticator MAY deny access by sending a Failure packet." From jari.arkko@piuha.net Mon Jun 2 19:35:47 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 02 Jun 2003 21:35:47 +0300 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB10@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BB10@esebe023.ntc.nokia.com> Message-ID: <3EDB9903.3080504@piuha.net> Pasi.Eronen@nokia.com wrote: > "Implementation Note: Because the Success and Failure packets are not > acknowledged, they are not retransmitted by the authenticator, and may > be potentially lost. A peer MUST allow for this circumstances as > described in this note. See also Section 3.4 for guidance on the > processing of lower layer success and failure indications. > > As described in Section 2.1, only a single EAP authentication method > is allowed within an EAP conversation. Individual EAP methods MAY > implement their own acknowledged result indications. If these > indications are used, they MUST provide information that agrees with > the final decision of the authenticator. Ok. > On the peer, once the method completes unsuccessfully (that is, either > the authenticator sends a method-specific failure indication, or the > peer decides that it does want to continue talking to this > authenticator), the link is disabled and the EAP conversation is > terminated (and any Success and Failure packets are silently > discarded). Ok. But shouldn't we mention mutual authentication failure in the above? > If the authenticator has sent a method-specific success indication, > the peer MUST silently discard Failure packets, and MAY, in the event > that an EAP Success is not received, conclude that the EAP Success > packet was lost and enable the link. (Note that the peer does not > enable the link immediately after receiving the method-specific > success indication, since it may be necessary to retransmit the last > EAP Response packet.) Ok. > If the authenticator has not sent any method-specific result > indication, and the peer still wants to talk to this authenticator, > once the method completes the peer waits for a Success or Failure > packet (and cannot silently discard either of them). In the event that > neither a Success nor Failure packet is received, the peer SHOULD > disable the link to avoid lengthy timeouts in case the lost packet was > an EAP Failure." Ok. > I don't think it's necessary to explicitly forbid the case of > allowing access when the authenticator has not verified who the peer > is. In most methods, the peer can't tell the difference anyway: e.g., > if in EAP-TLS the authenticator simply ignores the certificate given > by the peer, nobody will know. Your text looks good as such, but I still think that it should say something about "method authentication failure". Somebody will know, if the authentication failure confuses key generation somehow. And even if it does not, what use are the keys if they are not tied to the specific authentication? In short, there appears to be at least some worries in letting the process go forward after an authentication failure. And as discussed previously, there does not appear to be a specific reason to allow this. --Jari From aboba@internaut.com Mon Jun 2 19:15:09 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 2 Jun 2003 11:15:09 -0700 (PDT) Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: References: <052E0C61B69C3741AFA5FE88ACC775A608BB10@esebe023.ntc.nokia.com> Message-ID: > implement their own acknowledged result indications. If these > indications are used, the authenticator MUST provide a result > indication that is consistent with its final decision. That is, > a Failure packet MUST only be sent after a method-specific > failure indication, and a Success packet MUST only be sent > after a method-specific success indication. This isn't quite right. An authenticator could send a method-specific success indication, but the peer could send a method-specific failure indication, in which case the authenticator decision would be a failure. From jsalowey@cisco.com Mon Jun 2 19:42:12 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Mon, 2 Jun 2003 11:42:12 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: Message-ID: <004d01c32936$aeebfd20$0200000a@amer.cisco.com> > The authenticator MUST NOT grant access by sending a Success > packet if the peer did not successfully authenticate to it. > Where the authenticator wishes to deny access even where the > peer authenticated successfully (e.g. where the peer is not > currently authorized for network access), the authenticator > MAY deny access by sending a Failure packet." Why can't the authenticator grant access (perhaps limited access) even if the peer does not successfully authenticate to it? > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Monday, June 02, 2003 10:37 AM > To: Pasi.Eronen@nokia.com > Cc: jari.arkko@piuha.net; eap@frascone.com > Subject: [eap] Re: issue 121: failed auth & succeeded authz? > > > I think there is an issue with text relating to "enabling the > link" because in fact the link really must only be enabled > when it is usable, or "link up" triggers will cause all kinds > of havoc (like DHCP packets being triggered and sent into the > bit bucket, IPv4 linklocal addresses being assigned, etc.). > > In most link technologies, the link is not truly usable for > IP traffic until later. For example, in PPP NCP needs to be > concluded; in IEEE 802.11, the 4-way handshake needs to be concluded. > > As a result, I believe that text indicating that the link > should be enabled on successful authentication is misleading > and needs to be clarified or removed entirely. > > The part about disabling the link is ok though. > > I'd also note that where acknowledged result indications are > provided, both sides need to indicate success for the peer to > consider the authentication successful. Even if the > authenticator is happy, if the peer is not happy (e.g. the > authenticator failed to authenticate to it) it is not going > to consider the authentication successful. > > Also, Jari's suggested text relating to authorization error > messages seems useful and I think it should be retained. > > How about this? > > "EAP Success or Failure packets MUST NOT be sent by an EAP > server prior to completion of the final round of a given > method. A peer EAP implementation receiving a Success or > Failure packet prior to completion of the method in progress > MUST silently discard it. By default, an EAP peer MUST > silently discard a "canned" EAP Success message (an EAP > Success message sent immediately upon connection). This > ensures that a rogue authenticator will not be able to bypass > mutual authentication by sending an EAP Success prior to > conclusion of the EAP method conversation. > > Implementation Note: Because the Success and Failure packets > are not acknowledged, they are not retransmitted by the > authenticator, and may be potentially lost. A peer MUST allow > for this circumstance as described in this note. See also > Section 3.4 for guidance on the processing of lower layer > success and failure indications. > > As described in Section 2.1, only a single EAP authentication > method is allowed within an EAP conversation. Individual EAP > methods MAY implement their own acknowledged result > indications. If these indications are used, the authenticator > MUST provide a result indication that is consistent with its > final decision. That is, a Failure packet MUST only be sent > after a method-specific failure indication, and a Success > packet MUST only be sent after a method-specific success indication. > > On the peer, once the method completes unsuccessfully (that > is, either the authenticator sends a method-specific failure > indication, or the peer decides that it does want to continue > talking to this authenticator), the peer MUST terminate the > EAP conversation and disable the link. The peer MUST silently > discard Success packets and MAY silently discard Failure > packets. As a result, loss of a Failure packet need not > result in a timeout. > > On the peer, where an acknowledged result indication is > provided, and the method concludes successfully on both > sides, a Failure packet MUST be silently discarded by the > peer. The peer MAY, in the event that an EAP Success is not > received, conclude that the EAP Success packet was lost and > subsequently enable the link. > > A mutually authenticating method such as EAP-TLS [RFC2716] > that provides authorization error messages is considered > to provide acknowledged result indications for the purpose > of this specification. > > For example, within EAP-TLS, the peer authenticates > the authenticator, and sends TLS-alert messages in the > event of an authentication failure. Similarly, the > authenticator authenticates the peer, and the "access_denied" > TLS alert can be used by the authenticator to indicate that a > valid certificate was received from the peer, but when access > control was applied, the authenticator decided not to > proceed. If a method provides authorization error messages, > the authenticator SHOULD use them so as to ensure consistency > with the final access decision and avoid lengthy timeouts. > > If the authenticator has not sent any method-specific result > indication, and the peer still wants to talk to this > authenticator, once the method completes the peer waits for a > Success or Failure packet (and MUST NOT silently discard > either of them). In the event that neither a Success nor > Failure packet is received, the peer SHOULD disable the link > to avoid lengthy timeouts in case the lost packet was an EAP Failure. > > The authenticator MUST NOT grant access by sending a Success > packet if the peer did not successfully authenticate to it. > Where the authenticator wishes to deny access even where the > peer authenticated successfully (e.g. where the peer is not > currently authorized for network access), the authenticator > MAY deny access by sending a Failure packet." > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jsalowey@cisco.com Mon Jun 2 19:49:58 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Mon, 2 Jun 2003 11:49:58 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <3EDB908C.2080208@piuha.net> Message-ID: <004e01c32937$c4bb86b0$0200000a@amer.cisco.com> > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, June 02, 2003 11:00 AM > To: Joseph Salowey > Cc: jari.arkko@piuha.net; 'Bernard Aboba'; eap@frascone.com > Subject: Re: [eap] Re: issue 121: failed auth & succeeded authz? > > > Joseph Salowey wrote: > > > [Joe] Hmmm.. What does it mean that an authenticaiton method was > > unsuccessful? Is it that the Peer or authenticator could not be > > identified? Is it that the key exchange failed? It is > possible for > > one to succeed without the other. Access is not > necessarily a binary > > This is largely a method specific issue. In some methods > everything happens in one go, and you can't fail key exchange > if user authentication as such succeeded. > > > decision. It is possible to grant limited access even if the peer > > could not be identified. I think I agree that if key exchange was > > required and failed that this may cause a fundamental > problem is some > > systems, but not all. > > In earlier e-mails on the list we started to get a sense that > while it would be technically possible to allow EAP to > continue after an authentication failure, this appears > unnecessary. Better schemes exist, such as tunneled server > auth + credit card "auth" inside the tunnel. With these > better schemes we do not need to continue after an > authentication failure. I get a better feeling from that ;-) [Joe] I don't think what authenticaiton failure means is at all clear. What happens if the authe schem inside the tunnel fails, is that an authenticaiton failure or not? > > --Jari > > From jari.arkko@piuha.net Tue Jun 3 05:22:11 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 03 Jun 2003 07:22:11 +0300 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <004e01c32937$c4bb86b0$0200000a@amer.cisco.com> References: <004e01c32937$c4bb86b0$0200000a@amer.cisco.com> Message-ID: <3EDC2273.4090200@piuha.net> Joseph Salowey wrote: > I don't think what authenticaiton failure means is at all clear. > What happens if the authe schem inside the tunnel fails, is that an > authenticaiton failure or not? I guess the tunnel method specification should take some standpoint on that ;-) But I do see your point that an authentication failure may not be precisely defined. I just think that perhaps this is something that is defined by the methods. --Jari From jsalowey@cisco.com Tue Jun 3 06:36:57 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Mon, 2 Jun 2003 22:36:57 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <3EDC2273.4090200@piuha.net> Message-ID: <008d01c32992$26cda040$0200000a@amer.cisco.com> If you're not going to define authenticaiton failure in the EAP document then I don't think you should be defining MUST NOTs around it. Joe > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, June 02, 2003 9:22 PM > To: Joseph Salowey > Cc: 'Bernard Aboba'; eap@frascone.com > Subject: Re: [eap] Re: issue 121: failed auth & succeeded authz? > > > Joseph Salowey wrote: > > > I don't think what authenticaiton failure means is at all > clear. What > > happens if the authe schem inside the tunnel fails, is that an > > authenticaiton failure or not? > > I guess the tunnel method specification should take > some standpoint on that ;-) > > But I do see your point that an authentication failure may > not be precisely defined. I just think that perhaps this > is something that is defined by the methods. > > --Jari > > From Pasi.Eronen@nokia.com Tue Jun 3 09:22:35 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Tue, 3 Jun 2003 11:22:35 +0300 Subject: [eap] RE: issue 121: failed auth & succeeded authz? Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122299@esebe023.ntc.nokia.com> Jari Arkko wrote: > > On the peer, once the method completes unsuccessfully (that=20 > > is, either the authenticator sends a method-specific failure=20 > > indication, or the peer decides that it does want to continue=20 > > talking to this authenticator), the link is disabled and the EAP=20 > > conversation is terminated (and any Success and Failure packets=20 > > are silently discarded). >=20 > Ok. But shouldn't we mention mutual authentication failure in > the above? Oops, that should of course be "..., or the peer decides that it=20 does _NOT_ want to continue", and I intended that to cover authentication failures, as well as all other possible reasons. But yes, it's a big unclear. Maybe this one would be better? "On the peer, once the method completes unsuccessfully, the link is disabled and the EAP conversation is terminated (and any Success and Failure packets are silently discarded). unsuccessful completion of a method means that either the authenticator sends a method-specific failure indication, or the peer decides that it does not want to continue talking to this authenticator (for instance, in EAP-TLS, the certificate presented by the authenticator does not satisfy the peer's policy)." (Note that this means that "unsuccessful completion" on the peer can occur before the last message of the method. For instance, in EAP-TLS, if the server's certificate does not satisfy the peer's policy, there's no point in continuing the conversation.) > > If the authenticator has sent a method-specific success indication, > > the peer MUST silently discard Failure packets, and MAY, in=20 > the event > > that an EAP Success is not received, conclude that the EAP Success > > packet was lost and enable the link. (Note that the peer does not > > enable the link immediately after receiving the method-specific > > success indication, since it may be necessary to retransmit the last > > EAP Response packet.) >=20 > Ok. >=20 > > If the authenticator has not sent any method-specific result > > indication, and the peer still wants to talk to this authenticator, > > once the method completes the peer waits for a Success or Failure > > packet (and cannot silently discard either of them). In the=20 > event that > > neither a Success nor Failure packet is received, the peer SHOULD > > disable the link to avoid lengthy timeouts in case the lost=20 > packet was > > an EAP Failure." >=20 > Ok. >=20 > > I don't think it's necessary to explicitly forbid the case of > > allowing access when the authenticator has not verified who the peer > > is. In most methods, the peer can't tell the difference=20 > anyway: e.g., > > if in EAP-TLS the authenticator simply ignores the certificate given > > by the peer, nobody will know.=20 >=20 > Your text looks good as such, but I still think that it should > say something about "method authentication failure". Somebody > will know, if the authentication failure confuses key generation > somehow. And even if it does not, what use are the keys if they > are not tied to the specific authentication? In short, there > appears to be at least some worries in letting the process > go forward after an authentication failure. And as discussed > previously, there does not appear to be a specific reason to > allow this. Since we have forbidden sequences, I think we don't have to=20 differentiate between "method failures" and "EAP conversation=20 failures" anymore. It's probably easier to think that the=20 situation is a failure to a party if that party is unhappy=20 with the situation, and will not enable the link, regardless=20 of the other party's decision (and it does not matter why=20 the failure occured). If we use this definition, then if the authenticator decides=20 to give (maybe some sort of limited) access to the peer, then=20 the situation is a "success" for the authenticator, even if it=20 does not exactly know who the peer is. (The same situation may,=20 of course, be a "failure" for the peer). I agree that in some methods (especially those based on=20 shared secrets), some sort of protocol mismatches will result in lack of keys. But is this a protocol issue or policy issue? After all, in some cases methods that don't=20 derive keys even when succesful are completely acceptable.=20 An authenticator could, of course, have a policy saying that=20 "allow very limited access, if we haven't verified the peer's=20 identity but have derived keys" (of course, the authenticator does not then know who it shares the keys with, but this does not mean they're useless). If we absolutely do want to require that the authenticator=20 must never allow access if it hasn't verified the peer's identity, then I think we should use some other word than=20 "method success" for that (I think Joe Salowey said something=20 like this in his recent mail, that using MUST NOTs around an=20 undefined term isn't a good idea). Maybe something like this=20 would do the job: "If the authenticator has not verified the peer's identity,=20 it MUST send an EAP Failure packet. If the authenticator=20 uses a security policy that may, in some circumstances,=20 allow (possibly limited) access to the peer even when=20 the authenticator has not verified who the peer is, this=20 must be supported by the lower layer outside EAP. In this=20 case, the EAP Success/Failure packet does not completely=20 determine the access control decision, since access may be=20 granted even when EAP Failure is sent. The lower layer=20 must then have some means of signalling that "no, although=20 I sent an EAP Failure, it didn't really mean it."" (And no, I don't think this is a good idea, since it complicates the lower layers, and breaks connection between RADIUS Accept/Reject packets. I think in this case, the authenticator=20 should be allowed to send an EAP Success inside RADIUS=20 Access-Accept that includes a Filter-Id AVP.) Best regards, Pasi From jari.arkko@piuha.net Tue Jun 3 13:52:58 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 03 Jun 2003 15:52:58 +0300 Subject: [eap] minutes from eap sm dt conference call, may 28th Message-ID: <3EDC9A2A.4030102@piuha.net> Notes from the EAP State Machine Design Team conference call Date: Wednesday, 5/28/2003 Time: 8 AM PDT Attendees: Nick Petroni, Jari Arkko, Bernard Aboba, John Vollbrecht, Paul Congdon, Glen Zorn Scribe: Nick Petroni, Jari Arkko O Agenda: (A) Open EAP issues found at http://www.drizzle.com/~aboba/EAP/eapissues.html (B) 802.1aa convergence http://www.ieee802.org/1/files/private/aa-drafts/d6/802-1aa-d6.pdf (userid: p8021 password: go_wildcats) o DISCUSSION ABOUT 802.1AA, 802.11I, AND EAP ========================================== (A) MUTUAL/BI-DIRECTIONAL AUTHENTICATION Paul- What do we need to talk about on the .1aa draft? Bernard- What do you have to do if you have two bridges who want to open up ports to one another? Bernard thinks that the conclusion is mutual authentication implies that both links can come up and you can do spanning tree between them both. D6 suggests auth in both directions. Paul- there is a difference between mutual auth and bi-directional. Bernard- D6 says must do in both directions, but doesn't seem necessary. John- I don't think we intended to specify that bi-directional authentication is needed. DECISION: All parties agree is you don't need bi-directional, and that the D6 needs to be clarified. Bernard's summary: no need to do it to get these links up. Question about controlled port on peer side: was that in d5? No, started to go down that path but it requires a more symmetric model (Paul). Put back in a variable on the supplicant, but don't gain a controlled port. It does not fully work, the specification handwaves this. Bernard- People like linksec conclude can't do spanning tree, but there is actually a link that is up. Paul- port auth state on supplicant doesn't control link up/down so spanning tree would need to know to look at that variable instead of just linkup/down. Bernard- Jesse believes EAP can't work in peer to peer, but it appears to us 802.11i is broken, it may not understand EAP. 11i says bi-directional, not mutual. 11i seems broken in this regard. DECISION: Clarify that this is not necessary in 2284bis. (B) LINK UP Point made about link up and how it does not always occur when EAP finishes (e.g. 802.11i not until after 4-way handshake). Also, link up implies multiple things, such as movement detection, sending dhcp packets. Discussion on disjoint between 11i, 11f, etc for when the processes start. IAPP starts but secure association is not yet up. another problem, 11i has 2 association protocols. You can take people of the network by sending the unprotected association messages. Problem goes away if only the 4-way handshake is dealt with. (C) PLAN FOR PROCEEDING Paul- We still don't have annex f, which is intended to be EAP state machine. DECISION: Start putting state machine into .1aa, simultaneously clean up discrepancies, then we are down to the last nits. John will have a new state machine draft by next ietf. Try to get it before the ballot is run. Bernard says state machine can become a WG item by ietf 57. o OPEN ISSUES =========== (A) ISSUE 138 (MISCELLANEOUS -03 ISSUES) Brought up on the list, think it's closed... (B) Issue 139 (RESPONSE TO DUPLICATE REQUESTS) Issue Summary: 2284 says discard new requests while waiting for user input on the previous copy of the same request, but Nick asks why not just respond. Bernard and Jari came to same conclusion independently. Question is why is it there in the first place, answer is about avoiding unrepeatable user input or generating new values for some cryptographic tokens such as nonces. Issue is that we have not defined the semantics of how or when to process these requests. Jari- State machine is OK in this respect today. Might be useful to clarify text in the state machine draft that the full actions list is executed atomically, not just individual procedures. DECISION: No reason to silently discard assuming you are actually just retransmitting and just process each packet in the order they come in (no going back to user)... Text to be written. Let's bat around on the list for complete text. (scribe's note: and it has been discussed now, and closed.) (C) ISSUE 141 (MINOR NITS) Issue summary: Pasi proposes some reformulation of text, as well as removing keyword language from the terms section. Bernard- MSK deletion is Ok, no longer needed. Jari- Some keyword language should perhaps be rather moved to the normative sections than simply being deleted. Would like to keep the cryptographic separation text, too. Bernard- SASLPREP dependency is worrying. Only one example and it's not done yet, maybe this is actually a dependency? This could delay 2284bis if IESG insists on treating this as a dependency. DECISION: Some things in this issue are Ok, the rest has to be discussed on the list (scribe's note: and it has been discussed now, and closed.) (D) 134 (EAP TRANSPORT ISSUES) Bernard- I haven't come up with text yet. Restrict conversation to EAP retransmission problems. Not that there is MAC backoff, not like nothing would be happening without EAP. Does it make sense to have EAP backoff also? How do these interact? There are questions about where timer is (what protocol layer), whether it should be dynamic, what the parameters for the timers are, what specification changes we need, and about 802.1X retransmissions: - Protocol layer: John- This is also about end-to-end vs. hop-by-hop retransmissions. Who retransmits? Bernard- The EAP authenticator? John- But its always the link layer who actually sends it. Bernard- No, both may do it. Therefore the timescales should be different. Jari- Are there non-retransmitting link layers? Bernard- Yes, 802.11 for instance. Jari- Its very different for the two cases. Bernard- The MAC layer transmission is very different from apps layer ack. You don't see an eap response in the 1 ms that you see the link layer ack. - 802.1X retransmissions: Discussion- it appears there are three layers of retransmit in 1x- .11, 1x, and EAP. This is not what should be happening. It appears separation of 1x and EAP has started a bug. Bernard- Now that they are separated, 802.1x retransmission makes no more sense. Paul- but they are still there. Jari- three layer retransmissions. Paul- The time scales are ms, s, longer than s. Bernard- But the timescales are the same in radius, in the order of s. Seems like the 8021x/eap separation is causing a bug. Paul- this needs a big change to the 802.1x document. DECISION (Bernard)- Move the retransmission behaviour to the EAP part. - Dynamic vs. static timers: Bernard- The question is if the timer should be dynamic vs. fixed Currently 802.11i has a fixed timer Jari- Question: Is the estimation per session or per node/interface? Bernard- That's the question. Is it medium to medium? Is it per access point? Or does it vary per sessions? The reality is that some stations are much slower. CPU on the host has the same effect. Jari- Wireless distance may lead to lower rate; same equipment pair has a different RTT depending on distance. Jari- Where does that leave us? Bernard- Do dynamic estimation but lower RTO MIN to 300 but do it on a per-session basis. John: why not just do static? Bernard- We've seen this with radius, people will pick wrong values. Jari- I think dynamic estimation makes sense. you can still have people specify rtoinitial with a specific value in a specific situation. John- Looks good, but I'm still not convinced that we need to make it dynamic. Jari- Look at tcp. Bernard- What would make sense in your case is per-media initial values. John- If you are going to configure defaults, why not configre the static timers. Jari- Because it works most of the cases, and with static people would get the timers wrong in a large fraction of cases. Bernard- The real problem is radius timers. John- Agree, that has to fixed. Glen- There are interacting timers on eap and radius. If eap timer is too short, this will cause a radius storm. Bernard- if its the same EAP id field value, this does not result in a radius storm. - Parameters for the timers: Jari- Second granularity/minimum sounds very high for fast movements. Discussion between bernard and glen- two different parameters number of retries and how to retry. Glen- TCP has different goals. Needs to get data through any case. Here, we don't care after some amount of time. - Specification changes: So what about the state machine? what needs to change? Multiple ways for timer to be set- radius message or some defaults. what should that be? originally was 6 seconds. Decided to change, but to what? Dynamic retransmission estimation is the default. what are the correct values, etc? o OTHER ISSUES ============ (A) EAP TLV Glen- I was under the impression that EAP TLV would go to the main document. So I'm wondering if that's going to happen. Jari- Is there a reason why this can't be a separate document? Glen- No reason, it already is in a separate document. Thinks we agreed that protected success/failures are to be included in 2284bis. Bernard- We agreed to talk about the issues in them, not necessarily include them. Problem is that since sequences are not supported. Thus TLV would be either method specific or require tunnels. Jari- There is interest in tlv, but need to do it as another document. Bernard- Agree, 2284bis and keying framework need to produced before doing anything else. DECISION: Blocked form doing anything until 2284bis and re-keying are done. Just get them done and then look at other things such as TLV in future works. (B) KEYING FRAMEWORK Will keying framework become WG item when it fills Russ Houseley's requirements? Must describe AAA, 802.11i, etc. interactions. Basically asking for a security proof. Not clear how far we are from meeting these. Might need a discussion on what is needed and why. There is a bunch of stuff that is there and now. With redirect in AAA we can make new claims, the problem seems easier without the need for end-to-end security. Bernard will go through it to make sure what needs to be there is or rewrite. From jsalowey@cisco.com Tue Jun 3 18:25:23 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Tue, 3 Jun 2003 10:25:23 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <3EDC2273.4090200@piuha.net> Message-ID: <00bb01c329f5$1dd0dee0$0200000a@amer.cisco.com> So, if we define failed authenticaiton as the condition in which a method will result in sending and EAP-Failure I think things are okay. Just so long as this is not a circular definition. An EAP-Success may or may not indicate that a particular entity was authenticated successfully. Joe > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Monday, June 02, 2003 9:22 PM > To: Joseph Salowey > Cc: 'Bernard Aboba'; eap@frascone.com > Subject: Re: [eap] Re: issue 121: failed auth & succeeded authz? > > > Joseph Salowey wrote: > > > I don't think what authenticaiton failure means is at all > clear. What > > happens if the authe schem inside the tunnel fails, is that an > > authenticaiton failure or not? > > I guess the tunnel method specification should take > some standpoint on that ;-) > > But I do see your point that an authentication failure may > not be precisely defined. I just think that perhaps this > is something that is defined by the methods. > > --Jari > > From rgm-sec@htt-consult.com Wed Jun 4 21:23:16 2003 From: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Wed, 04 Jun 2003 16:23:16 -0400 Subject: [eap] How would you do AUP? In-Reply-To: <00bb01c329f5$1dd0dee0$0200000a@amer.cisco.com> References: <3EDC2273.4090200@piuha.net> Message-ID: <5.1.0.14.2.20030604162045.02c15a10@localhost> One thing of interest that surfaced in the NSA/NIST WLAN Protection Profile Workshop last month was the requirement to show the WLAN AUP before permitting authentication. Yet I have not seen an EAP method that supports this, nor is there a way to transmit an AUP in 802.1x. So how can this be done? As text in the EAP-Identity-Request (which limits the size of the AUP). Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From jsalowey@cisco.com Wed Jun 4 21:27:48 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 4 Jun 2003 13:27:48 -0700 Subject: [eap] How would you do AUP? In-Reply-To: <5.1.0.14.2.20030604162045.02c15a10@localhost> Message-ID: <013701c32ad7$c4605a50$0200000a@amer.cisco.com> Couldn't EAP-Notificaiton be used for this? > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Robert Moskowitz > Sent: Wednesday, June 04, 2003 1:23 PM > To: eap@frascone.com > Subject: [eap] How would you do AUP? > > > One thing of interest that surfaced in the NSA/NIST WLAN > Protection Profile > Workshop last month was the requirement to show the WLAN AUP before > permitting authentication. > > Yet I have not seen an EAP method that supports this, nor is > there a way to > transmit an AUP in 802.1x. > > So how can this be done? As text in the EAP-Identity-Request > (which limits > the size of the AUP). > > > Robert Moskowitz > TruSecure Corporation > Security Interest EMail: rgm-sec@htt-consult.com > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From rgm-sec@htt-consult.com Wed Jun 4 21:51:06 2003 From: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Wed, 04 Jun 2003 16:51:06 -0400 Subject: [eap] How would you do AUP? In-Reply-To: <013701c32ad7$c4605a50$0200000a@amer.cisco.com> References: <5.1.0.14.2.20030604162045.02c15a10@localhost> Message-ID: <5.1.0.14.2.20030604165027.02cffde0@localhost> At 01:27 PM 6/4/2003 -0700, Joseph Salowey wrote: >Couldn't EAP-Notificaiton be used for this? Isn't that too late? It has to be before the challenge/response for the method. > > -----Original Message----- > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > On Behalf Of Robert Moskowitz > > Sent: Wednesday, June 04, 2003 1:23 PM > > To: eap@frascone.com > > Subject: [eap] How would you do AUP? > > > > > > One thing of interest that surfaced in the NSA/NIST WLAN > > Protection Profile > > Workshop last month was the requirement to show the WLAN AUP before > > permitting authentication. > > > > Yet I have not seen an EAP method that supports this, nor is > > there a way to > > transmit an AUP in 802.1x. > > > > So how can this be done? As text in the EAP-Identity-Request > > (which limits > > the size of the AUP). > > > > > > Robert Moskowitz > > TruSecure Corporation > > Security Interest EMail: rgm-sec@htt-consult.com > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From jsalowey@cisco.com Wed Jun 4 21:58:53 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 4 Jun 2003 13:58:53 -0700 Subject: [eap] How would you do AUP? In-Reply-To: <5.1.0.14.2.20030604165027.02cffde0@localhost> Message-ID: <013b01c32adc$1be9ba60$0200000a@amer.cisco.com> I don't think it is a problem to send a notification request as your first request. However most implementaitons are hard coded to start with an identity request. The notificaiton could happen after the identity request but before the actual authenticaiton method request. > -----Original Message----- > From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com] > Sent: Wednesday, June 04, 2003 1:51 PM > To: Joseph Salowey; eap@frascone.com > Subject: RE: [eap] How would you do AUP? > > > At 01:27 PM 6/4/2003 -0700, Joseph Salowey wrote: > >Couldn't EAP-Notificaiton be used for this? > > Isn't that too late? It has to be before the > challenge/response for the > method. > > > > > > -----Original Message----- > > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On > > > Behalf Of Robert Moskowitz > > > Sent: Wednesday, June 04, 2003 1:23 PM > > > To: eap@frascone.com > > > Subject: [eap] How would you do AUP? > > > > > > > > > One thing of interest that surfaced in the NSA/NIST WLAN > Protection > > > Profile Workshop last month was the requirement to show > the WLAN AUP > > > before permitting authentication. > > > > > > Yet I have not seen an EAP method that supports this, nor > is there a > > > way to transmit an AUP in 802.1x. > > > > > > So how can this be done? As text in the > EAP-Identity-Request (which > > > limits the size of the AUP). > > > > > > > > > Robert Moskowitz > > > TruSecure Corporation > > > Security Interest EMail: rgm-sec@htt-consult.com > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > Robert Moskowitz > TruSecure Corporation > Security Interest EMail: rgm-sec@htt-consult.com > From jose.p.puthenkulam@intel.com Wed Jun 4 22:19:36 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Wed, 4 Jun 2003 14:19:36 -0700 Subject: [eap] How would you do AUP? Message-ID: <0769E8DB76C83645A75E3F8EDDE24F9B0E7CB8@orsmsx407.jf.intel.com> Does AUP stand for Acceptable Use Policy?=20 best regards, jose > -----Original Message----- > From: Joseph Salowey [mailto:jsalowey@cisco.com]=20 > Sent: Wednesday, June 04, 2003 1:59 PM > To: 'Robert Moskowitz'; eap@frascone.com > Subject: RE: [eap] How would you do AUP? >=20 >=20 > I don't think it is a problem to send a notification request as your > first request. However most implementaitons are hard coded to start > with an identity request. The notificaiton could happen after the > identity request but before the actual authenticaiton method=20 > request. =20 >=20 >=20 > > -----Original Message----- > > From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com]=20 > > Sent: Wednesday, June 04, 2003 1:51 PM > > To: Joseph Salowey; eap@frascone.com > > Subject: RE: [eap] How would you do AUP? > >=20 > >=20 > > At 01:27 PM 6/4/2003 -0700, Joseph Salowey wrote: > > >Couldn't EAP-Notificaiton be used for this? > >=20 > > Isn't that too late? It has to be before the=20 > > challenge/response for the=20 > > method. > >=20 > >=20 > >=20 > > > > -----Original Message----- > > > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On=20 > > > > Behalf Of Robert Moskowitz > > > > Sent: Wednesday, June 04, 2003 1:23 PM > > > > To: eap@frascone.com > > > > Subject: [eap] How would you do AUP? > > > > > > > > > > > > One thing of interest that surfaced in the NSA/NIST WLAN=20 > > Protection=20 > > > > Profile Workshop last month was the requirement to show=20 > > the WLAN AUP=20 > > > > before permitting authentication. > > > > > > > > Yet I have not seen an EAP method that supports this, nor=20 > > is there a=20 > > > > way to transmit an AUP in 802.1x. > > > > > > > > So how can this be done? As text in the=20 > > EAP-Identity-Request (which=20 > > > > limits the size of the AUP). > > > > > > > > > > > > Robert Moskowitz > > > > TruSecure Corporation > > > > Security Interest EMail: rgm-sec@htt-consult.com > > > > > > > > _______________________________________________ > > > > eap mailing list > > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > >=20 > > Robert Moskowitz > > TruSecure Corporation > > Security Interest EMail: rgm-sec@htt-consult.com > >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From jsalowey@cisco.com Thu Jun 5 01:57:31 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 4 Jun 2003 17:57:31 -0700 Subject: [eap] How would you do AUP? In-Reply-To: <0769E8DB76C83645A75E3F8EDDE24F9B0E7CB8@orsmsx407.jf.intel.com> Message-ID: <000a01c32afd$71e0db80$0200000a@amer.cisco.com> That is my understanding. Joe > -----Original Message----- > From: Puthenkulam, Jose P [mailto:jose.p.puthenkulam@intel.com] > Sent: Wednesday, June 04, 2003 2:20 PM > To: Joseph Salowey; Robert Moskowitz; eap@frascone.com > Subject: RE: [eap] How would you do AUP? > > > Does AUP stand for Acceptable Use Policy? > > > best regards, > jose > > > > -----Original Message----- > > From: Joseph Salowey [mailto:jsalowey@cisco.com] > > Sent: Wednesday, June 04, 2003 1:59 PM > > To: 'Robert Moskowitz'; eap@frascone.com > > Subject: RE: [eap] How would you do AUP? > > > > > > I don't think it is a problem to send a notification > request as your > > first request. However most implementaitons are hard coded > to start > > with an identity request. The notificaiton could happen after the > > identity request but before the actual authenticaiton > method request. > > > > > > > -----Original Message----- > > > From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com] > > > Sent: Wednesday, June 04, 2003 1:51 PM > > > To: Joseph Salowey; eap@frascone.com > > > Subject: RE: [eap] How would you do AUP? > > > > > > > > > At 01:27 PM 6/4/2003 -0700, Joseph Salowey wrote: > > > >Couldn't EAP-Notificaiton be used for this? > > > > > > Isn't that too late? It has to be before the > > > challenge/response for the > > > method. > > > > > > > > > > > > > > -----Original Message----- > > > > > From: eap-admin@frascone.com > [mailto:eap-admin@frascone.com] On > > > > > Behalf Of Robert Moskowitz > > > > > Sent: Wednesday, June 04, 2003 1:23 PM > > > > > To: eap@frascone.com > > > > > Subject: [eap] How would you do AUP? > > > > > > > > > > > > > > > One thing of interest that surfaced in the NSA/NIST WLAN > > > Protection > > > > > Profile Workshop last month was the requirement to show > > > the WLAN AUP > > > > > before permitting authentication. > > > > > > > > > > Yet I have not seen an EAP method that supports this, nor > > > is there a > > > > > way to transmit an AUP in 802.1x. > > > > > > > > > > So how can this be done? As text in the > > > EAP-Identity-Request (which > > > > > limits the size of the AUP). > > > > > > > > > > > > > > > Robert Moskowitz > > > > > TruSecure Corporation > > > > > Security Interest EMail: rgm-sec@htt-consult.com > > > > > > > > > > _______________________________________________ > > > > > eap mailing list > > > > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > > > > > > > > > Robert Moskowitz > > > TruSecure Corporation > > > Security Interest EMail: rgm-sec@htt-consult.com > > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > From rgm-sec@htt-consult.com Thu Jun 5 03:58:53 2003 From: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Wed, 04 Jun 2003 22:58:53 -0400 Subject: [eap] How would you do AUP? In-Reply-To: <0769E8DB76C83645A75E3F8EDDE24F9B0E7CB8@orsmsx407.jf.intel. com> Message-ID: <5.1.0.14.2.20030604225703.02d75868@localhost> At 02:19 PM 6/4/2003 -0700, Puthenkulam, Jose P wrote: >Does AUP stand for Acceptable Use Policy? Yes. It is common at many Corporations and Gov networks to require presenting the AUP before a person logs into a service. It is amazing that we have not heard more about this, considering the 'considered' legal position for posting AUPs. Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From jari.arkko@piuha.net Thu Jun 5 10:27:21 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 05 Jun 2003 12:27:21 +0300 Subject: [eap] Re: submitting EAP-SIM document In-Reply-To: <3ED651C1.6010207@bell-labs.com> References: <000801c32165$dbb8ca00$23a50587@EDC> <3ED651C1.6010207@bell-labs.com> Message-ID: <3EDF0CF9.7070206@piuha.net> Hello Sarvar, (Speaking individually and as the author of EAP-AKA) Your paper looks like a very useful analysis. First, I wonder if you had done any similar work on EAP-AKA in addition to EAP-SIM? If yes, I'd be very interested to hear your results. And then to the EAP-SIM issues. It looks like the first vulnerability that you describe is valid. I think I also agree with the proposed solution. As to the second vulnerability... if I'm not mistaken this appears to be a property of the GSM authentication rather than the EAP-SIM adaptation of that. With the same assumptions you would be able to spoof yourself as a GSM network, no? But not the user. Interestingly, AKA does not appear to have the same vulnerability, given its replay protection mechanisms; it was designed with stricter requirements. Actually, I wonder how useful it is to try to search for a fix. It might be easier to just document that EAP-SIM has that limitation due to the underlying authentication scheme. You might or might not be worried about the limitation. But if you are, one answer is to upgrade to a USIM from a SIM and use EAP-AKA authentication. --Jari From jose.p.puthenkulam@intel.com Thu Jun 5 16:22:10 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Thu, 5 Jun 2003 08:22:10 -0700 Subject: [eap] How would you do AUP? Message-ID: <0769E8DB76C83645A75E3F8EDDE24F9B0E7CB9@orsmsx407.jf.intel.com> Looks like we need a new EAP method to present such AUP information.=20 best regards, jose > -----Original Message----- > From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com]=20 > Sent: Wednesday, June 04, 2003 7:59 PM > To: Puthenkulam, Jose P; Joseph Salowey; eap@frascone.com > Subject: RE: [eap] How would you do AUP? >=20 >=20 > At 02:19 PM 6/4/2003 -0700, Puthenkulam, Jose P wrote: > >Does AUP stand for Acceptable Use Policy? >=20 > Yes. >=20 > It is common at many Corporations and Gov networks to require=20 > presenting=20 > the AUP before a person logs into a service. >=20 > It is amazing that we have not heard more about this, considering the=20 > 'considered' legal position for posting AUPs. >=20 >=20 >=20 > Robert Moskowitz > TruSecure Corporation > Security Interest EMail: rgm-sec@htt-consult.com >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From jsalowey@cisco.com Thu Jun 5 16:26:41 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 5 Jun 2003 08:26:41 -0700 Subject: [eap] How would you do AUP? In-Reply-To: <0769E8DB76C83645A75E3F8EDDE24F9B0E7CB9@orsmsx407.jf.intel.com> Message-ID: <003501c32b76$ddb3f6c0$0200000a@amer.cisco.com> Why won't EAP-Notification work? > -----Original Message----- > From: Puthenkulam, Jose P [mailto:jose.p.puthenkulam@intel.com] > Sent: Thursday, June 05, 2003 8:22 AM > To: Robert Moskowitz; Joseph Salowey; eap@frascone.com > Subject: RE: [eap] How would you do AUP? > > > Looks like we need a new EAP method to present such AUP information. > > best regards, > jose > > > > > > -----Original Message----- > > From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com] > > Sent: Wednesday, June 04, 2003 7:59 PM > > To: Puthenkulam, Jose P; Joseph Salowey; eap@frascone.com > > Subject: RE: [eap] How would you do AUP? > > > > > > At 02:19 PM 6/4/2003 -0700, Puthenkulam, Jose P wrote: > > >Does AUP stand for Acceptable Use Policy? > > > > Yes. > > > > It is common at many Corporations and Gov networks to require > > presenting > > the AUP before a person logs into a service. > > > > It is amazing that we have not heard more about this, > considering the > > 'considered' legal position for posting AUPs. > > > > > > > > Robert Moskowitz > > TruSecure Corporation > > Security Interest EMail: rgm-sec@htt-consult.com > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > From paul.congdon@hp.com Thu Jun 5 16:33:08 2003 From: paul.congdon@hp.com (CONGDON,PAUL (HP-Roseville,ex1)) Date: Thu, 5 Jun 2003 11:33:08 -0400 Subject: [eap] How would you do AUP? Message-ID: <499DC368E25AD411B3F100902740AD6512992ADE@xrose03.rose.hp.com> So, how would this new method work in conjunction with existing methods. As I understand it, there is no sequencing of methods unless within a tunnel and you can't set-up the tunnel until you have established some credentials (a bit too late). It could be part of EAP/Req-ID (which is really a special method that can be sequenced), or it could be part of the link layer (e.g. a new 802.1X EAPOL-Hello or Notify message), or you simply do run a new EAP method that completely terminates but doesn't succeed in authentication, and then you follow with a completely new EAP method like one of the conventional methods (close to sequencing, but not quite)... > -----Original Message----- > From: Puthenkulam, Jose P [mailto:jose.p.puthenkulam@intel.com] > Sent: Thursday, June 05, 2003 8:22 AM > To: Robert Moskowitz; Joseph Salowey; eap@frascone.com > Subject: RE: [eap] How would you do AUP? > > > Looks like we need a new EAP method to present such AUP information. > > best regards, > jose > > > > > > -----Original Message----- > > From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com] > > Sent: Wednesday, June 04, 2003 7:59 PM > > To: Puthenkulam, Jose P; Joseph Salowey; eap@frascone.com > > Subject: RE: [eap] How would you do AUP? > > > > > > At 02:19 PM 6/4/2003 -0700, Puthenkulam, Jose P wrote: > > >Does AUP stand for Acceptable Use Policy? > > > > Yes. > > > > It is common at many Corporations and Gov networks to require > > presenting > > the AUP before a person logs into a service. > > > > It is amazing that we have not heard more about this, > considering the > > 'considered' legal position for posting AUPs. > > > > > > > > Robert Moskowitz > > TruSecure Corporation > > Security Interest EMail: rgm-sec@htt-consult.com > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jari.arkko@piuha.net Thu Jun 5 18:12:38 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 05 Jun 2003 20:12:38 +0300 Subject: [eap] How would you do AUP? In-Reply-To: <499DC368E25AD411B3F100902740AD6512992ADE@xrose03.rose.hp.com> References: <499DC368E25AD411B3F100902740AD6512992ADE@xrose03.rose.hp.com> Message-ID: <3EDF7A06.5090809@piuha.net> I'm in favor of using Notification for this purpose. --Jari From aboba@internaut.com Thu Jun 5 18:35:31 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 5 Jun 2003 10:35:31 -0700 (PDT) Subject: [eap] Re: AUPs Message-ID: A few comments: a) Since the AUP needs to be displayed regardless of the authentication scheme chosen (open, WEP, WPA, RSN), it seems like this needs to occur prior to EAP authentication. In the December 2002 NIST review, we recommended addition of an Information Element in the Beacon and Probe Response to handle this. b) If it is desired to transmit a displayable message to the user, the EAP-Request/Identity can be used for this purpose. Given the above, a new method (or any protocol changes) seem unnecessary. From rgm-sec@htt-consult.com Thu Jun 5 21:10:15 2003 From: rgm-sec@htt-consult.com (Robert Moskowitz) Date: Thu, 05 Jun 2003 16:10:15 -0400 Subject: [eap] Re: AUPs In-Reply-To: Message-ID: <5.1.0.14.2.20030605160712.02c12990@localhost> At 10:35 AM 6/5/2003 -0700, Bernard Aboba wrote: >a) Since the AUP needs to be displayed regardless of the authentication >scheme chosen (open, WEP, WPA, RSN), it seems like this needs to occur >prior to EAP authentication. In the December 2002 NIST review, we >recommended addition of an Information Element in the Beacon and Probe >Response to handle this. Having done AUPs back at Chrysler in the mid-90s (and so I kick myself on this too), it takes much more than a flag. >b) If it is desired to transmit a displayable message to the user, >the EAP-Request/Identity can be used for this purpose. This is how I see it. Either here or in the EAPoL-Start. Here it provides more functionality; AUP is then provided to all applications of EAP. >Given the above, a new method (or any protocol changes) seem unnecessary. Just some descriptive text about how to implement AUP in your EAP peers by its inclusion in the EAP-Req/Ident. Robert Moskowitz TruSecure Corporation Security Interest EMail: rgm-sec@htt-consult.com From jose.p.puthenkulam@intel.com Thu Jun 5 22:29:42 2003 From: jose.p.puthenkulam@intel.com (Puthenkulam, Jose P) Date: Thu, 5 Jun 2003 14:29:42 -0700 Subject: [eap] Re: AUPs Message-ID: <0769E8DB76C83645A75E3F8EDDE24F9B0E7CBF@orsmsx407.jf.intel.com> I'm ok with not requiring a new EAP method. The reason I suggested that was thinking that user-network interaction would be required in the context of AUP.=20 For example if a user rejects the AUP the client can decide to drop the connection or let the EAP peer make the decision. EAP-Notification could be used, to accomplish the latter model I guess. best regards, jose > -----Original Message----- > From: Robert Moskowitz [mailto:rgm-sec@htt-consult.com]=20 > Sent: Thursday, June 05, 2003 1:10 PM > To: Bernard Aboba; eap@frascone.com > Subject: Re: [eap] Re: AUPs >=20 >=20 > At 10:35 AM 6/5/2003 -0700, Bernard Aboba wrote: >=20 > >a) Since the AUP needs to be displayed regardless of the=20 > authentication > >scheme chosen (open, WEP, WPA, RSN), it seems like this=20 > needs to occur > >prior to EAP authentication. In the December 2002 NIST review, we > >recommended addition of an Information Element in the Beacon=20 > and Probe > >Response to handle this. >=20 > Having done AUPs back at Chrysler in the mid-90s (and so I=20 > kick myself on=20 > this too), it takes much more than a flag. >=20 > >b) If it is desired to transmit a displayable message to the user, > >the EAP-Request/Identity can be used for this purpose. >=20 > This is how I see it. Either here or in the EAPoL-Start. =20 > Here it provides=20 > more functionality; AUP is then provided to all applications of EAP. >=20 > >Given the above, a new method (or any protocol changes) seem=20 > unnecessary. >=20 > Just some descriptive text about how to implement AUP in your=20 > EAP peers by=20 > its inclusion in the EAP-Req/Ident. >=20 >=20 > Robert Moskowitz > TruSecure Corporation > Security Interest EMail: rgm-sec@htt-consult.com >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 From alper@docomolabs-usa.com Fri Jun 6 01:02:59 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 05 Jun 2003 17:02:59 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: Message-ID: >> So, to me this is starting to sound very complicated. > > Actually, I think it's quite simple :) There appears to be no > justification for allowing access in the case where authentication is > attempted and fails. How about this case: I have a laptop that is configured with a single set of credentials from an Internet service provider (e.g., foo@ISP1.com). The shopping mall allows roaming clients from a bunch of other ISPs but not ISP1. It provides premium service (secure, highly available, etc.) to authenticated clients, and willing to provide limited access to anyone else. If I walk into this shopping mall, my laptop will make an attempt to get authenticated, but it will fail, right? But the network is willing to provide limited access to my laptop. Alper From alper@docomolabs-usa.com Fri Jun 6 01:09:49 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 05 Jun 2003 17:09:49 -0700 Subject: [eap] RE: issue 121: failed auth & succeeded authz? In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122299@esebe023.ntc.nokia.com> Message-ID: Hi Pasi, > But yes, it's a big unclear. Maybe this one would be better? > > "On the peer, once the method completes unsuccessfully, the link > is disabled and the EAP conversation is terminated (and any > Success and Failure packets are silently discarded). Why do we need to talk about what happens to the link? Shouldn't we let the consumer of EAP decide what to do with the EAP results. Secondly, this assumption of enabling/disabling links do not apply to other carriers of EAP, such as PANA and IKEv2. > unsuccessful completion of a method means that either the > authenticator sends a method-specific failure indication, or the > peer decides that it does not want to continue talking to this > authenticator (for instance, in EAP-TLS, the certificate > presented by the authenticator does not satisfy the peer's > policy)." ... > "If the authenticator has not verified the peer's identity, > it MUST send an EAP Failure packet. If the authenticator > uses a security policy that may, in some circumstances, > allow (possibly limited) access to the peer even when > the authenticator has not verified who the peer is, this > must be supported by the lower layer outside EAP. In this > case, the EAP Success/Failure packet does not completely > determine the access control decision, since access may be > granted even when EAP Failure is sent. The lower layer > must then have some means of signalling that "no, although > I sent an EAP Failure, it didn't really mean it."" > > (And no, I don't think this is a good idea, since it complicates > the lower layers Why does it complicate the lower layers? It might require additional changes to the existing lower layers, I agree. > , and breaks connection between RADIUS > Accept/Reject packets. I didn't understand this either. Could you please elaborate which breakage is this. > I think in this case, the authenticator > should be allowed to send an EAP Success inside RADIUS > Access-Accept that includes a Filter-Id AVP.) > Thanks. Alper > > Best regards, > Pasi > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > From aboba@internaut.com Fri Jun 6 00:58:45 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 5 Jun 2003 16:58:45 -0700 (PDT) Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: References: Message-ID: > I have a laptop that is configured with a single set of credentials from an > Internet service provider (e.g., foo@ISP1.com). The shopping mall allows > roaming clients from a bunch of other ISPs but not ISP1. It provides premium > service (secure, highly available, etc.) to authenticated clients, and > willing to provide limited access to anyone else. If I walk into this > shopping mall, my laptop will make an attempt to get authenticated, but it > will fail, right? But the network is willing to provide limited access to my > laptop. This scenario is typically handled in IEEE 802.11 by support of multiple Virtual networks. That is, there is a "GUEST" SSID for guests, providing limited access (e.g. separate VLAN) and another SSID for the authenticated network. Similar facilities can be provided in other link technologies that support a discovery facility (such as PPPOE). From aboba@internaut.com Fri Jun 6 01:02:55 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 5 Jun 2003 17:02:55 -0700 (PDT) Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: References: Message-ID: > shopping mall, my laptop will make an attempt to get authenticated, but it > will fail, right? But the network is willing to provide limited access to my > laptop. In this case, the authenticator will also fail to authenticate to the peer, so the peer can't trust that it isn't a rogue network masquerading as another one. So even if the authenticator would choose to allow access, the peer will disable its side of the link, so it does no good. It makes more sense for the authenticator to advertise a separate limited network with a different authentication policy ("open") and let the peer connect to that instead. From alper@docomolabs-usa.com Fri Jun 6 01:51:28 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 05 Jun 2003 17:51:28 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: Message-ID: >> I have a laptop that is configured with a single set of credentials from an >> Internet service provider (e.g., foo@ISP1.com). The shopping mall allows >> roaming clients from a bunch of other ISPs but not ISP1. It provides premium >> service (secure, highly available, etc.) to authenticated clients, and >> willing to provide limited access to anyone else. If I walk into this >> shopping mall, my laptop will make an attempt to get authenticated, but it >> will fail, right? But the network is willing to provide limited access to my >> laptop. > > This scenario is typically handled in IEEE 802.11 by support of multiple > Virtual networks. That is, there is a "GUEST" SSID for guests, > providing limited access (e.g. separate VLAN) and another SSID for the > authenticated network. Similar facilities can be provided in other link > technologies that support a discovery facility (such as PPPOE). I'd like to understand the details a bit more. What is the order of events that leads to aforementioned client receiving limited access service? (does it have to somehow conclude that it is a GUEST before making attempt to get authenticated [if so, how?], or does it fail first auth attempt and realize it is a GUEST and make a second attempt, etc...) Alper From alper@docomolabs-usa.com Fri Jun 6 02:22:38 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 05 Jun 2003 18:22:38 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: Message-ID: >> shopping mall, my laptop will make an attempt to get authenticated, but it >> will fail, right? But the network is willing to provide limited access to my >> laptop. > > In this case, the authenticator will also fail to authenticate to the > peer, so the peer can't trust that it isn't a rogue network masquerading > as another one. So even if the authenticator would choose to allow > access, the peer will disable its side of the link, so it does no good. It does not always have to... For example, I'm willing to access free but insecure networks. > > It makes more sense for the authenticator to advertise a separate limited > network with a different authentication policy ("open") and let the peer > connect to that instead. Yes, this makes sense. But I suspect my client will fail at least once before it falls back to this separate network. Alper From aboba@internaut.com Fri Jun 6 02:01:40 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 5 Jun 2003 18:01:40 -0700 (PDT) Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: References: Message-ID: > I'd like to understand the details a bit more. What is the order of events > that leads to aforementioned client receiving limited access service? (does > it have to somehow conclude that it is a GUEST before making attempt to get > authenticated [if so, how?], or does it fail first auth attempt and realize > it is a GUEST and make a second attempt, etc...) In networks with a discovery service, the peer determines that multiple networks are available on the same wire. The peer can then attempt to connect to any of those networks. Depending on the link technology, it may even be possible to connect to multiple networks at the same time. Typically, a host has some reason to decide to connect to a network. For example, it has signed up for an account with a particular network, and when it discovers the presence of that network, it has reason to believe that it has credentials valid for use with that network. In your example, if the user only has an account with ISP1, that ISP could provide the user with information on the roaming relationships. For example, in the case of dialup, a dialer is typically configured with all the available phone numbers, some of which represent ISP1's facilities, and others of which represent other ISPs with whom ISP1 has established a roaming relationship. In the case of IEEE 802.11 or PPPOE link technologies, multiple networks can be advertised, so that the availability of ISP1's network can be made known to the peer. If ISP1 is not available, then the facilities of networks that are available can be advertised. Depending on the discovery facility, it may be possible to advertise the same network with multiple access mechanisms, as well as different networks with different access mechanisms. So in this case, the ISP could advertise a GUEST network with open access, and another network requiring EAP authentication (e.g. WPA). The peer, upon discovering these networks can choose which network to attempt to connect to. Typically, the peer will not automatically attempt to connect to networks with which it has no pre-existing relationship, and among those networks with which a pre-existing relationship exists, there may be a preference list. In this particular case, the user might have the GUEST network in its preference list, since such a network is commonly used to indicate the availability of (potentially restricted) open access. So upon not recognizing any other configured network, the peer will choose to connect to the GUEST network, rather than attempting to authenticate to another network that it does not recognize. If the ISP1 network had been advertised, then presumably the peer would attempt to authenticate to that network, since the peer is configured with appropriate credentials and as a result, has an expectation that the authentication will be successful. Some more information on Virtual Networks and the implications for network access is available here: http://www.drizzle.com/~aboba/IEEE/virtual-APs.ppt http://www.drizzle.com/~aboba/IEEE/11-03-154r1-I-Virtual-Access-Points.doc From aboba@internaut.com Fri Jun 6 02:04:02 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 5 Jun 2003 18:04:02 -0700 (PDT) Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: References: Message-ID: > It does not always have to... For example, I'm willing to access free but > insecure networks. That's fine -- but then there's no need to use EAP. > Yes, this makes sense. But I suspect my client will fail at least once > before it falls back to this separate network. It shouldn't because there's no reason for a client to be configured to automatically connect to unrecognized networks in preference to recognized ones (including a GUEST network). From jsalowey@cisco.com Fri Jun 6 04:21:31 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 5 Jun 2003 20:21:31 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: Message-ID: <003c01c32bda$ba9c0d80$0200000a@amer.cisco.com> > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Thursday, June 05, 2003 4:59 PM > To: Alper Yegin > Cc: Jari Arkko; eap@frascone.com > Subject: Re: [eap] Re: issue 121: failed auth & succeeded authz? > > > > I have a laptop that is configured with a single set of credentials > > from an Internet service provider (e.g., foo@ISP1.com). The > shopping > > mall allows roaming clients from a bunch of other ISPs but > not ISP1. > > It provides premium service (secure, highly available, etc.) to > > authenticated clients, and willing to provide limited > access to anyone > > else. If I walk into this shopping mall, my laptop will make an > > attempt to get authenticated, but it will fail, right? But > the network > > is willing to provide limited access to my laptop. > > This scenario is typically handled in IEEE 802.11 by support > of multiple Virtual networks. That is, there is a "GUEST" > SSID for guests, providing limited access (e.g. separate > VLAN) and another SSID for the authenticated network. Similar > facilities can be provided in other link technologies that > support a discovery facility (such as PPPOE). > So is it a requirement that EAP be run over a link layer that supports a "discovery facility"? > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Fri Jun 6 04:08:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 5 Jun 2003 20:08:43 -0700 (PDT) Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <003c01c32bda$ba9c0d80$0200000a@amer.cisco.com> References: <003c01c32bda$ba9c0d80$0200000a@amer.cisco.com> Message-ID: > So is it a requirement that EAP be run over a link layer that supports a > "discovery facility"? Every known link layer supporting EAP either supports a discovery facility or negotiation of EAP/non-EAP authentication methods. For example, in PPP if an alternative authentication mechanism (or even no authentication) is desired, it can be negotiated and EAP can be bypassed. So it is not clear why it would be necessary to use EAP authentication in situations in which there is no known trust relationship and therefore authentication would be likely to fail. From jsalowey@cisco.com Fri Jun 6 05:18:56 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Thu, 5 Jun 2003 21:18:56 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: Message-ID: <003e01c32be2$bfce56c0$0200000a@amer.cisco.com> I'm still confused about the meaning of authentication failure (I'm not sure who I'm agreeing with). Currently I look at it as follows: Authentication policies are determined by the mechanism. Some mechanisms may be very strict in what they determine is a failure to authenticate a peer. Others may allow a peer to go unauthenticated and still call the authentication a success (however the entity may receive different authorizations based on the result of the authentication). Authentication fails in one of two cases 1) In cases where key derivation is required and it fails there is authentication failure 2) In cases where the mechanism indicates EAP-Failure there is authentication failure I agree that if either of the above two cases are true there should be no change in access given to peer. Determining what is acceptable authentication policy is up to the mechanism implementation. Does this match up with anyone's view? Joe > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, June 05, 2003 8:09 PM > To: Joseph Salowey > Cc: 'Alper Yegin'; 'Jari Arkko'; eap@frascone.com > Subject: RE: [eap] Re: issue 121: failed auth & succeeded authz? > > > > So is it a requirement that EAP be run over a link layer > that supports > > a "discovery facility"? > > Every known link layer supporting EAP either supports a > discovery facility or negotiation of EAP/non-EAP > authentication methods. > > For example, in PPP if an alternative authentication > mechanism (or even no > authentication) is desired, it can be negotiated and EAP can > be bypassed. > > So it is not clear why it would be necessary to use EAP > authentication in situations in which there is no known trust > relationship and therefore authentication would be likely to fail. > From aboba@internaut.com Fri Jun 6 05:23:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 5 Jun 2003 21:23:43 -0700 (PDT) Subject: [eap] Re: AUP In-Reply-To: <20030606033301.19289.14027.Mailman@wolverine> References: <20030606033301.19289.14027.Mailman@wolverine> Message-ID: > >a) Since the AUP needs to be displayed regardless of the authentication > >scheme chosen (open, WEP, WPA, RSN), it seems like this needs to occur > >prior to EAP authentication. In the December 2002 NIST review, we > >recommended addition of an Information Element in the Beacon and Probe > >Response to handle this. > > Having done AUPs back at Chrysler in the mid-90s (and so I kick myself on > this too), it takes much more than a flag. I was thinking of an IE containing a string. Example: "This is a private network; if you are not authorized DISCONNECT NOW". The advantage of doing this in the Beacon or Probe Response is that the AUP gets to be communicated *before* the user attempts authentication. This is important because the act of attempted authentication itself can be construed as an attempted breakin. > >b) If it is desired to transmit a displayable message to the user, the > >EAP-Request/Identity can be used for this purpose. > > This is how I see it. Either here or in the EAPoL-Start. Here it provides > more functionality; AUP is then provided to all applications of EAP. Yes. With the limitation that the user may already have associated by the time the message is delivered. > Just some descriptive text about how to implement AUP in your EAP peers by > its inclusion in the EAP-Req/Ident. Yes. We need some additional text anyway (to document existing usage of the EAP-Request/Identity field. I'll submit an issue. From jari.arkko@piuha.net Fri Jun 6 07:03:07 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Fri, 06 Jun 2003 09:03:07 +0300 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: <003e01c32be2$bfce56c0$0200000a@amer.cisco.com> References: <003e01c32be2$bfce56c0$0200000a@amer.cisco.com> Message-ID: <3EE02E9B.4060609@piuha.net> Joseph Salowey wrote: > I'm still confused about the meaning of authentication failure (I'm not > sure who I'm agreeing with). Currently I look at it as follows: > > Authentication policies are determined by the mechanism. Some > mechanisms may be very strict in what they determine is a failure to > authenticate a peer. Others may allow a peer to go unauthenticated and > still call the authentication a success (however the entity may receive > different authorizations based on the result of the authentication). > > Authentication fails in one of two cases > > 1) In cases where key derivation is required and it fails there is > authentication failure > > 2) In cases where the mechanism indicates EAP-Failure there is > authentication failure If we look at the root causes of EAP authentication failure, I think we have the following: - Method authentication message somehow invalid (e.g. MAC) - Method key generation somehow failed and keys needed - Method-specific failure indication - Insufficient authorization - Protocol error, timeout, ... --Jari From Pasi.Eronen@nokia.com Fri Jun 6 08:15:31 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Fri, 6 Jun 2003 10:15:31 +0300 Subject: [eap] Re: issue 121: failed auth & succeeded authz? Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222A0@esebe023.ntc.nokia.com> Alper Yegin wrote: >> But yes, it's a big unclear. Maybe this one would be better? >>=20 >> "On the peer, once the method completes unsuccessfully, the link >> is disabled and the EAP conversation is terminated (and any >> Success and Failure packets are silently discarded). >=20 > Why do we need to talk about what happens to the link?=20 > Shouldn't we let the consumer of EAP decide what to do with=20 > the EAP results. Secondly, this assumption of enabling/disabling=20 > links do not apply to other carriers of EAP, such as PANA and IKEv2. By "disabling the link", I meant "terminating the connection instead of doing whatever would have followed if everything had succeeded". So, in IKEv2 this would mean aborting the=20 IKEv2 exchange instead of proceeding to "phase 2". > > "If the authenticator has not verified the peer's identity, > > it MUST send an EAP Failure packet. If the authenticator > > uses a security policy that may, in some circumstances, > > allow (possibly limited) access to the peer even when > > the authenticator has not verified who the peer is, this > > must be supported by the lower layer outside EAP. In this > > case, the EAP Success/Failure packet does not completely > > determine the access control decision, since access may be > > granted even when EAP Failure is sent. The lower layer > > must then have some means of signalling that "no, although > > I sent an EAP Failure, it didn't really mean it."" > >=20 > > (And no, I don't think this is a good idea, since it complicates > > the lower layers >=20 > Why does it complicate the lower layers? It might require=20 > additional changes to the existing lower layers, I agree. Ok, maybe it does not really complicate the lower layers much, but it sure breaks existing lower layers, which IMHO is a=20 good enough reason not to do it.. > > , and breaks connection between RADIUS > > Accept/Reject packets. >=20 > I didn't understand this either. Could you please elaborate=20 > which breakage is this. Current we're trying to say the RADIUS Access-Accept must contain an EAP Success packet. This would break it: Access-Accept could contain an EAP Failure, too.=20 (That is, I think we should stick with the principle that an=20 EAP Success packet means "access granted", and an EAP Failure=20 packet means "access denied".) Best regards, Pasi From uri@bell-labs.com Fri Jun 6 21:38:01 2003 From: uri@bell-labs.com (Uri Blumenthal) Date: Fri, 06 Jun 2003 16:38:01 -0400 Subject: [Fwd: Re: [eap] Re: submitting EAP-SIM document] Message-ID: <3EE0FBA9.9050800@bell-labs.com> Sorry, this reply from Sarvar didn't get forwarded to the list, so I'm remeding it. -------- Original Message -------- Date: Wed, 4 Jun 2003 16:10:21 -0400 From: "Sarvar Patel" To: "EAP mailing List" Hi Joe, thanks for your response. My comments are inline. > With respect to only 64 bits of security this is indeed a problem that > has been overlooked (at least by me). I think the appropriate action > would be to revise the draft to require the client to check to make sure > the RAND values within a request are different. What are your thoughts about including SRES in the MK calculation, since it would add more secret material to the MK even in the case of a single triplet, possibly providing 96 bit of security. This is possible since, as I understand it, the SRES is never exposed in the EAP-SIM protocol. The EAP-Response/SIM/Challenge message creates and sends the MAC of EAP|n*SRES but does not include the SRES values themselves. > Also EAP-SIM most definitely relies upon the secrecy of Kcs to maintain > session independence. As you point out, we must require that all > triplets remain secret, because if an attacker obtains RAND and Kc then > he or she can act as the network. This is discussed in several sections > in the draft, but stronger wording on this fundamental assumption is > probably warranted. I did notice your discussion on the need to keep triplets secret which I found to be in tension with the requirement for fresh triplets for every new instance of the protocol. Let me explain: As I understand the EAP-SIM, like the GSM, protocol specifies that at each different instance of the protocol the authenticator would solicit fresh new triplets to be used in authentication and session key generation with the client. If so then it implies that the EAP-SIM protocol is looking for session independence at the level of triplets like in the GSM world where even if past triplets are compromised or revealed, it has no impact on future sessions. But this triplet independence is not true of the EAP-SIM protocol and as you specify all the triplets need to be kept secret. This then prompts the question, why have the requirement that fresh triplets are needed for every new instance of the protocol? Here are two possible solutions which do not require fresh triplets and will work assuming that the authenticator is trusted: 1) Share the Ki with the authenticator and run a secure mutual authentication and session key agreement protocol (e.g. Bellare-Rogaway protocol) 2) If sharing Ki is not possible, then share n triplets once with the authenticator and the reuse the triplets even with new instances of protocols in the following manner. The authenticator first shares the RANDs values with the client and they both run a secure mutual authentication and session key agreement protocol (e.g. Bellare-Rogaway protocol) using Kc's as the root key. A protocol like Bellare-rogaway would send its own random challenges to be used in creating the responses and session key, unlike the current EAP-SIM protocol which uses the RANDs as both a way to specify Kc value and as challenges to use in response verifications. I suppose the point is that if one cares about session independence at the triplet level, I don't know how to achieve that. However, if one does not care about session independence at the triplet level (that is the authenticator is trusted) then one could specify a protocol where fresh triplets are not needed. The current EAP-SIM would be inefficient in the sense that even though it does not provide session independence at the triplet level, it still requires fresh triplets. At this point, I just wanted to make us aware of these possibilities. >In general I am less concerned about Kc exposure on > the authenticator side than on the client side. This is because with > EAP-SIM triplets do not have to leave the home domain to facilitate > roaming authentication (EAP-SIM typically terminates in the home > network) which is different than the VLR model in GSM. On the client > side there are implementations that perform EAP-SIM calculations on the > SIM card that prevent triplet exposure. Nonetheless it is still a > serious consideration. Hmm, why are you worried about the client side revealing Kc? Is there an incentive for the client to find out the Kc, may be you are thinking that an attacker who temporarily gets the SIM card can find out the Kc and use it later to attack the client. I guess my understanding is limitied on the exact EAP-SIM use, but if Kc being compromised at the client is alsoan issue then the above discussion has to be changed accordingly. thanks Sarvar > Once again thanks for your time. I expect we will be updating the draft > to address your comments in the near future. > > Regards, > > Joe > > -----Original Message----- > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > > On Behalf Of Uri Blumenthal > > Sent: Thursday, May 29, 2003 11:30 AM > > To: EAP mailing List > > Cc: Sarvar Patel; 'S.Mizikovsky' > > Subject: [eap] Re: submitting EAP-SIM document > > > > > > Folks, > > > > My colleange Sarvar Patel asked me to post his analysis > > of EAP-SIM draft. Here's the summary in short, and since > > the entire paper (in PDF) is only 16 KB, I'm attaching > > it to this posting. > > > > EAP-SIM specifies a mechanism for mutual authentication and > > session key > > agreement using the GSM-SIM and by proposing enhancement to the GSM > > authentication procedures. Unfortunately, as we show it does not > > succeed in its goal of providing 128 bit security from the current 64 > > bit security of GSM. Furthermore, it does not provide session > > independence between different sessions. For the first > > problem, we are > > able to provide solutions, but the second problem does not > > seem solvable > > in practice. > > > > > > From alper@docomolabs-usa.com Wed Jun 11 02:32:03 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Tue, 10 Jun 2003 18:32:03 -0700 Subject: [eap] Re: issue 121: failed auth & succeeded authz? In-Reply-To: Message-ID: Thanks Bernard, for elaborating the discovery service model. >> So is it a requirement that EAP be run over a link layer that supports a >> "discovery facility"? > > Every known link layer supporting EAP either supports a discovery facility > or negotiation of EAP/non-EAP authentication methods. This assumption seems like impacting the EAP design. It might be already available in existing lower-layers, but I think we should explicitly include this in the draft for the new lower layers (if we want to maintain this assumption/requirement). > > For example, in PPP if an alternative authentication mechanism (or even no > authentication) is desired, it can be negotiated and EAP can be bypassed. > > So it is not clear why it would be necessary to use EAP authentication in > situations in which there is no known trust relationship and therefore > authentication would be likely to fail. This assumes that the peer can fully and positively determine if the network can surely authenticate it before they are engaged in EAP. Alper > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Wed Jun 11 06:23:07 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 10 Jun 2003 22:23:07 -0700 (PDT) Subject: [eap] Another stab at resolving Issue 121 Message-ID: Here's another try at resolving Issue 121. Comments welcome. Change the following text in Section 4.2 from: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, the authenticator cannot know whether they have been received. As a result, these packets are not retransmitted by the authenticator. If acknowledged result indications are desired, these MAY be implemented within individual EAP methods. Since only a single EAP authentication method is supported within an EAP conversation, a peer that successfully authenticates the authenticator MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and enable the link." To: "EAP Success or Failure packets MUST NOT be sent by an EAP server prior to completion of the final round of a given method. A peer EAP implementation receiving a Success or Failure packet prior to completion of the method in progress MUST silently discard it. By default, an EAP peer MUST silently discard a "canned" EAP Success message (an EAP Success message sent immediately upon connection). This ensures that a rogue authenticator will not be able to bypass mutual authentication by sending an EAP Success prior to conclusion of the EAP method conversation. Implementation Note: Because the Success and Failure packets are not acknowledged, they are not retransmitted by the authenticator, and may be potentially lost. A peer MUST allow for this circumstance as described in this note. See also Section 3.4 for guidance on the processing of lower layer success and failure indications. As described in Section 2.1, only a single EAP authentication method is allowed within an EAP conversation. EAP methods MAY implement acknowledged result indications. After the authenticator sends a method-specific failure indication to the peer, regardless of the response from the peer, it MUST subsequently send a Failure packet. After the authenticator sends a method-specific success indication to the peer, and receives a method-specific success indication from the peer, it MUST subsequently send a Success packet. On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a method-specific failure indication, or the peer decides that it does want to continue the conversation), the peer MUST terminate the conversation and avoid sending data on the link. The peer MUST silently discard Success packets and MAY silently discard Failure packets. As a result, loss of a Failure packet need not result in a timeout. On the peer, after successful acknowledged result indications are exchanged by both sides, a Failure packet MUST be silently discarded by the peer. The peer MAY, in the event that an EAP Success is not received, conclude that the EAP Success packet was lost and that authentication concluded successfully. A mutually authenticating method (such as EAP-TLS [RFC2716]) that provides authorization error messages provides acknowledged result indications for the purpose of this specification. Within EAP-TLS, the peer always authenticates the authenticator, and may send a TLS-alert message in the event of an authentication failure. The authenticator, which authenticates the peer, may use the "access denied" TLS aert to indicate that a valid certificate was received from the peer, but when access control was applied, the authenticator decided not to proceed. If a method provides authorization error messages, the authenticator SHOULD use them so as to ensure consistency with the final access decision and avoid lengthy timeouts. If the authenticator has not sent a method-specific result indication, and the peer is willing to continue the conversation, once the method completes the peer waits for a Success or Failure packet and MUST NOT silently discard either of them. In the event that neither a Success nor Failure packet is received, the peer SHOULD terminate the conversation to avoid lengthy timeouts in case the lost packet was an EAP Failure. If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet. However, an authenticator MAY NOT require that the peer authenticate to it in situations where limited access is offered (e.g. guest access). In this case the authenticator MAY send a Success packet. Where the peer authenticates successfully to the authenticator, but the authenticator does not send a successful result indication (such as in a method in which the authenticator authenticates the peer but the peer does not authenticate the authenticator), the authenticator MAY deny access by sending a Failure packet where the peer is not currently authorized for network access." From aboba@internaut.com Wed Jun 11 06:40:51 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 10 Jun 2003 22:40:51 -0700 (PDT) Subject: [eap] Proposed resolution to Issue 121 Message-ID: In Issue 121 we have defined the circumstances in which the peer may eventually conclude that a Success packet has been lost. In those same circumstances, the proposed change allows the peer to conclude that a Success packet has been lost, without having to wait the full timeout period. It therefore represents an optimization. Here are the proposed fixes: In Section 3.4, Change: "Lower layer failure indications provided to EAP by the lower layer MUST be processed and will cause an EAP exchange in progress to be aborted. However, lower layer success indications MUST NOT affect EAP message processing so that an EAP implementation MUST NOT conclude that authentication has succeeded based on those indications." To: "Section 4.2 defines the circumstances in which a peer, having concluded an EAP method with successful acknowledged result indications, may conclude that a Success packet has been lost after expiration of a timeout. In those same circumstances, if a peer receives a lower layer success indication as defined in Section 7.12, it MAY conclude that a Success packet has been lost without waiting for a timeout." In Section 7.12, change: " [c] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer indications include Disassociate and Deauthenticate frames (link failure indications), and Association and Reassociation Response frames (link success indications). These messages are not authenticated or integrity protected, and although they are not forwardable, they are spoofable by an attacker within range." To: " [c] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer indications include Disassociate and Deauthenticate frames (link failure indications), and the first message of the 4-way handshake (link success indication). These messages are not authenticated or integrity protected, and although they are not forwardable, they are spoofable by an attacker within range." From jsalowey@cisco.com Wed Jun 11 07:12:19 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Tue, 10 Jun 2003 23:12:19 -0700 Subject: [eap] Another stab at resolving Issue 121 In-Reply-To: Message-ID: <006701c32fe0$6a84e560$0200000a@amer.cisco.com> Looks better comments inline: > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Tuesday, June 10, 2003 10:23 PM > To: eap@frascone.com > Subject: [eap] Another stab at resolving Issue 121 > > > Here's another try at resolving Issue 121. Comments welcome. > > Change the following text in Section 4.2 from: > > "EAP Success or Failure packets MUST NOT be sent by an EAP > server prior to completion of the final round of a given > method. A peer EAP implementation receiving a Success or > Failure packet prior to completion of the method in progress > MUST silently discard it. By default, an EAP peer MUST > silently discard a "canned" EAP Success message (an EAP > Success message sent immediately upon connection). This > ensures that a rogue authenticator will not be able to bypass > mutual authentication by sending an EAP Success prior to > conclusion of the EAP method conversation. > > Implementation Note: Because the Success and Failure packets > are not acknowledged, the authenticator cannot know whether > they have been received. As a result, these packets are not > retransmitted by the authenticator. If acknowledged result > indications are desired, these MAY be implemented within > individual EAP methods. Since only a single EAP > authentication method is supported within an EAP > conversation, a peer that successfully authenticates the > authenticator MAY, in the event that an EAP Success is not > received, conclude that the EAP Success packet was lost and > enable the link." > > To: > "EAP Success or Failure packets MUST NOT be sent by an EAP > server prior to completion of the final round of a given > method. A peer EAP implementation receiving a Success or > Failure packet prior to completion of the method in progress > MUST silently discard it. By default, an EAP peer MUST > silently discard a "canned" EAP Success message (an EAP > Success message sent immediately upon connection). This > ensures that a rogue authenticator will not be able to bypass > mutual authentication by sending an EAP Success prior to > conclusion of the EAP method conversation. > > Implementation Note: Because the Success and Failure packets > are not acknowledged, they are not retransmitted by the > authenticator, and may be potentially lost. A peer MUST allow > for this circumstance as described in this note. See also > Section 3.4 for guidance on the processing of lower layer > success and failure indications. > > As described in Section 2.1, only a single EAP authentication > method is allowed within an EAP conversation. EAP methods MAY > implement acknowledged result indications. After the > authenticator sends a method-specific failure indication to > the peer, regardless of the response from the peer, it MUST > subsequently send a Failure packet. After the authenticator > sends a method-specific success indication to the peer, and > receives a method-specific success indication from the peer, > it MUST subsequently send a Success packet. > > On the peer, once the method completes unsuccessfully (that > is, either the authenticator sends a method-specific failure > indication, or the peer decides that it does want to continue > the conversation), the peer MUST terminate the conversation > and avoid sending data on the link. The peer MUST silently > discard Success packets and MAY silently discard Failure > packets. As a result, loss of a Failure packet need not > result in a timeout. > > On the peer, after successful acknowledged result indications > are exchanged by both sides, a Failure packet MUST be > silently discarded by the peer. The peer MAY, in the event > that an EAP Success is not received, conclude that the EAP > Success packet was lost and that authentication concluded > successfully. > > A mutually authenticating method (such as EAP-TLS [RFC2716]) > that provides authorization error messages provides > acknowledged result indications for the purpose of this > specification. Within EAP-TLS, the peer always authenticates > the authenticator, and may send a TLS-alert message in the > event of an authentication failure. The authenticator, which > authenticates the peer, may use the "access denied" TLS aert > to indicate that a valid certificate was received from the > peer, but when access control was applied, the authenticator > decided not to proceed. If a method provides authorization > error messages, the authenticator SHOULD use them so as to > ensure consistency with the final access decision and avoid > lengthy timeouts. > > If the authenticator has not sent a method-specific result > indication, and the peer is willing to continue the > conversation, once the method completes the peer waits for a > Success or Failure packet and MUST NOT silently discard > either of them. In the event that neither a Success nor > Failure packet is received, the peer SHOULD terminate the > conversation to avoid lengthy timeouts in case the lost > packet was an EAP Failure. > > If the peer attempts to authenticate to the authenticator and > fails to do so, the authenticator MUST send a Failure packet > and MUST NOT grant access by sending a Success packet. > However, an authenticator MAY NOT require that the peer > authenticate to it in situations where limited access is > offered (e.g. guest access). In this case the authenticator > MAY send a Success packet. > [Joe] If the authenticator wants to change the access granted to the peer it MUST send an EAP-Success. > Where the peer authenticates successfully to the > authenticator, but the authenticator does not send a > successful result indication (such as in a method in which > the authenticator authenticates the peer but the peer does > not authenticate the authenticator), the authenticator MAY > deny access by sending a Failure packet where the peer is not > currently authorized for network access." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From aboba@internaut.com Wed Jun 11 07:15:44 2003 From: aboba@internaut.com (Bernard Aboba) Date: Tue, 10 Jun 2003 23:15:44 -0700 (PDT) Subject: [eap] Issue 142: Contents of the EAP-Request/Identity Message-ID: Submitter name: Tim Moore Submitter email address: timmoore@microsoft.com Date first submitted: June 9, 2003 Reference: Document: EAP-03 Comment type: T Priority: S Section: 5.1 Rationale/Explanation of issue: Change: " This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." To: " This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field preceeding the null is displayed, with the rest used as a hint to the peer as to the identity to be provided in the Response, as described in Appendix A.2. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet." Add to Appendix A: "A.2 Contents of the Request/Identity Type-Data field So as to provide the peer with a hint as to the appropriate identity to place in the Type-Data field of the EAP-Response/Identity, the authenticator may wish to identity itself EAP-Request/Identity, in addition to providing a displayable message to the peer, such as an Appropriate Use Policy (AUP). The following format is proposed for the null-terminated displayable string and the comma-separated portion of the EAP-Request/Identity message string: \0networkid=,nasid=,portid= Where: network-name: Name of the network to which the authenticator connects. This is typically the SSID for IEEE 802.11. nas-name: Name or address of the NAS. port-id: port that the EAP session is on. The EAP peer should display display-string before the null termination (\0) to enable administrators to display network identification messages or appropriate use policies (AUPs)." From floroiu@fokus.fraunhofer.de Wed Jun 11 14:05:42 2003 From: floroiu@fokus.fraunhofer.de (John Williams Floroiu) Date: Wed, 11 Jun 2003 15:05:42 +0200 Subject: [eap] question on the scope of the master session keys Message-ID: <3EE72926.9080301@fokus.fraunhofer.de> Hi, According to my understanding, the link layer encryption (WEP) keys used by (802.11) access points to protect the data traffic are in number of four (and they are tried one-by-one until one or none matches). This basically means that the encryption keys are neither user nor device specific, but rather common to all clients that attach to a given access point. However some phrasing like the one above, quoted from draft-ietf-eap-rfc2284bis-03.txt: [...] The MSK is used in the derivation of Transient Session Keys (TSKs) for the ciphersuite negotiated between the EAP peer and authenticator. [...] suggest that the "authenticator" may configure EAP peer specific TSKs. Is this functionality envisioned to be supported by future access points? Comments would be greatly appreciated. John. From paul.congdon@hp.com Wed Jun 11 15:46:38 2003 From: paul.congdon@hp.com (CONGDON,PAUL (HP-Roseville,ex1)) Date: Wed, 11 Jun 2003 10:46:38 -0400 Subject: [eap] Issue 142: Contents of the EAP-Request/Identity Message-ID: <499DC368E25AD411B3F100902740AD6512992B3D@xrose03.rose.hp.com> Seems like this should really be considered at the link layer? New EAPOL-Start or EAPOL-Hello messages could contain the discovery information... > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, June 10, 2003 11:16 PM > To: eap@frascone.com > Subject: [eap] Issue 142: Contents of the EAP-Request/Identity > > > Submitter name: Tim Moore > Submitter email address: timmoore@microsoft.com > Date first submitted: June 9, 2003 > Reference: > Document: EAP-03 > Comment type: T > Priority: S > Section: 5.1 > Rationale/Explanation of issue: > > Change: > > " This field MAY contain a displayable message in the > Request, containing UTF-8 encoded ISO 10646 characters > [RFC2279]. The Response uses this field to return the > Identity. If the Identity is unknown, this field should be > zero bytes in length. The field MUST NOT be null terminated. > The length of this field is derived from the Length field of > the Request/Response packet and hence a null is not required." > > To: > > " This field MAY contain a displayable message in the > Request, containing UTF-8 encoded ISO 10646 characters > [RFC2279]. Where the Request contains a null, only the > portion of the field preceeding the null is displayed, with > the rest used as a hint to the peer as to the identity to be > provided in the Response, as described in Appendix A.2. If > the Identity is unknown, the Identity Response field should > be zero bytes in length. The Identity Response field MUST NOT > be null terminated. In all cases, the length of the Type-Data > field is derived from the Length field of the > Request/Response packet." > > Add to Appendix A: > > "A.2 Contents of the Request/Identity Type-Data field > > So as to provide the peer with a hint as to the appropriate > identity to place in the Type-Data field of the > EAP-Response/Identity, the authenticator may wish to identity > itself EAP-Request/Identity, in addition to providing a > displayable message to the peer, such as an Appropriate Use > Policy (AUP). > > The following format is proposed for the null-terminated > displayable string and the comma-separated portion of the > EAP-Request/Identity message > string: > > \0networkid=,nasid=,po > rtid= > > Where: > > network-name: Name of the network to which the authenticator connects. > This is typically the SSID for IEEE 802.11. > > nas-name: Name or address of the NAS. > > > port-id: port that the EAP session is on. > > The EAP peer should display display-string before the null termination > (\0) to enable administrators to display network > identification messages or appropriate use policies (AUPs)." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From cchaplin@sj.symbol.com Wed Jun 11 18:09:49 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Wed, 11 Jun 2003 10:09:49 -0700 Subject: [eap] question on the scope of the master session keys Message-ID: Um, not quite. There are four possible enumerated WEP keys, but the = packet contains a number which states which WEP key was used. But even the above is simplistic. 802.11 has the concept of key-mapping = keys and default keys. For unicast packets with a key index of zero, the = key-mapping key space is searched for a key-mapping key that corresponds = to the sending entity's MAC address, and if found, that key-mapping key is = used, otherwise the default WEP key at key index 0 is used. For all = broadcast traffic and unicast traffic that used key indices 1 through 3, = the corresponding default WEP key is used. No trying of keys is needed, and in fact a lot of the existing hardware = gives you only one chance to decrypt the message. But, of course, this has nothing to do with the question you are asking. Clint (JOATMON) Chaplin >>> John Williams Floroiu 6/11/03 06:05:42 = >>> Hi, According to my understanding, the link layer encryption (WEP) keys used = by (802.11) access points to protect the data=20 traffic are in number of four (and they are tried one-by-one until one or = none matches). This basically means that the=20 encryption keys are neither user nor device specific, but rather common to = all clients that attach to a given access point. However some phrasing like the one above, quoted from draft-ietf-eap-rfc228= 4bis-03.txt: [...] The MSK is used in the derivation of Transient Session Keys (TSKs) for the ciphersuite negotiated between the EAP peer and authenticator. [...] suggest that the "authenticator" may configure EAP peer specific TSKs. Is = this functionality envisioned to be supported=20 by future access points? Comments would be greatly appreciated. John. _______________________________________________ eap mailing list eap@frascone.com=20 http://mail.frascone.com/mailman/listinfo/eap=20 ________________________________________________________________________ This email has been scanned for computer viruses. From yohba@tari.toshiba.com Tue Jun 10 15:32:58 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 10 Jun 2003 07:32:58 -0700 Subject: [eap] Another stab at resolving Issue 121 In-Reply-To: References: Message-ID: <20030610143258.GB6192@steelhead> In the penultimate paragraph of the new text, the key word "MAY NOT" is used but that particular key word is actually not defined in RFC 2119. I think "MAY not" is more appropriate than "MAY NOT". Yoshihiro Ohba On Tue, Jun 10, 2003 at 10:23:07PM -0700, Bernard Aboba wrote: > Here's another try at resolving Issue 121. Comments welcome. > > Change the following text in Section 4.2 from: > > "EAP Success or Failure packets MUST NOT be sent by an EAP server > prior to completion of the final round of a given method. A peer EAP > implementation receiving a Success or Failure packet prior to > completion of the method in progress MUST silently discard it. By > default, an EAP peer MUST silently discard a "canned" EAP Success > message (an EAP Success message sent immediately upon connection). > This ensures that a rogue authenticator will not be able to bypass > mutual authentication by sending an EAP Success prior to conclusion > of the EAP method conversation. > > Implementation Note: Because the Success and Failure packets are > not acknowledged, the authenticator cannot know whether they have > been received. As a result, these packets are not retransmitted by > the authenticator. If acknowledged result indications > are desired, these MAY be implemented within individual EAP > methods. Since only a single EAP authentication method is > supported within an EAP conversation, a peer that successfully > authenticates the authenticator MAY, in the event that an EAP > Success is not received, conclude that the EAP Success packet was > lost and enable the link." > > To: > "EAP Success or Failure packets MUST NOT be sent by an EAP server > prior to completion of the final round of a given method. A peer EAP > implementation receiving a Success or Failure packet prior to > completion of the method in progress MUST silently discard it. By > default, an EAP peer MUST silently discard a "canned" EAP Success > message (an EAP Success message sent immediately upon connection). > This ensures that a rogue authenticator will not be able to bypass > mutual authentication by sending an EAP Success prior to > conclusion of the EAP method conversation. > > Implementation Note: Because the Success and Failure packets are not > acknowledged, they are not retransmitted by the authenticator, and may > be potentially lost. A peer MUST allow for this circumstance as > described in this note. See also Section 3.4 for guidance on the > processing of lower layer success and failure indications. > > As described in Section 2.1, only a single EAP authentication method > is allowed within an EAP conversation. EAP methods MAY > implement acknowledged result indications. > After the authenticator sends a method-specific failure indication > to the peer, regardless of the response from the peer, it MUST > subsequently send a Failure packet. After the authenticator > sends a method-specific success indication to the peer, and > receives a method-specific success indication from the peer, > it MUST subsequently send a Success packet. > > On the peer, once the method completes unsuccessfully (that is, either > the authenticator sends a method-specific failure indication, or the > peer decides that it does want to continue the conversation), the > peer MUST terminate the conversation and avoid sending data on the > link. The peer MUST silently discard Success packets and MAY > silently discard Failure packets. As a result, > loss of a Failure packet need not result in a timeout. > > On the peer, after successful acknowledged result indications > are exchanged by both sides, a Failure packet MUST be silently > discarded by the peer. The peer MAY, in the event that an EAP Success is > not > received, conclude that the EAP Success packet was lost and > that authentication concluded successfully. > > A mutually authenticating method (such as EAP-TLS [RFC2716]) > that provides authorization error messages provides > acknowledged result indications for the purpose > of this specification. Within EAP-TLS, the peer always > authenticates the authenticator, and may send a TLS-alert message > in the event of an authentication failure. The authenticator, > which authenticates the peer, may use the "access denied" > TLS aert to indicate that a valid > certificate was received from the peer, but when > access control was applied, the authenticator decided not to proceed. > If a method provides authorization error messages, the authenticator > SHOULD use them so as to ensure consistency with the final access > decision and avoid lengthy timeouts. > > If the authenticator has not sent a method-specific result > indication, and the peer is willing to continue the conversation, > once the method completes the peer waits for a Success or Failure > packet and MUST NOT silently discard either of them. In the event that > neither a Success nor Failure packet is received, the peer SHOULD > terminate the conversation to avoid lengthy timeouts in case the > lost packet was an EAP Failure. > > If the peer attempts to authenticate to the authenticator and fails > to do so, the authenticator MUST send a Failure packet and MUST NOT > grant access by sending a Success packet. However, an authenticator > MAY NOT require that the peer authenticate to it in situations where > limited access is offered (e.g. guest access). In this case the > authenticator MAY send a Success packet. > > Where the peer authenticates successfully to the authenticator, but > the authenticator does not send a successful result indication > (such as in a method in which the authenticator authenticates the peer > but the peer does not authenticate the authenticator), the authenticator > MAY deny access by sending a Failure packet where the peer is not > currently authorized for network access." > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From yohba@tari.toshiba.com Tue Jun 10 17:19:35 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Tue, 10 Jun 2003 09:19:35 -0700 Subject: [eap] Issue 142: Contents of the EAP-Request/Identity In-Reply-To: <499DC368E25AD411B3F100902740AD6512992B3D@xrose03.rose.hp.com> References: <499DC368E25AD411B3F100902740AD6512992B3D@xrose03.rose.hp.com> Message-ID: <20030610161935.GD6685@steelhead> I agree with Paul on not including the information (AUP, networkid, nasid, portid) in EAP message. Such information should be provided before a peer chooses an appropriate authenticaticator with which it starts EAP conversation. In this sense, including the information in 802.1X frame might also be too late. On the other hand, AUP should be provided in a stateless fashon, because a user on a peer device tends to take more time to read the AUP and make a decision to whether it should start EAP conversation with the EAP authenticator that originated the AUP. Thus, I think the appropriate place is containing it in Beacon frame in the case of 802.11 and in PANA authentication agent discovery exchange in the case of PANA. Of course the size of AUP text should be as small as possible so that it does not consume the bandwidth. Yoshihiro Ohba On Wed, Jun 11, 2003 at 10:46:38AM -0400, CONGDON,PAUL (HP-Roseville,ex1) wrote: > > Seems like this should really be considered at the link layer? New > EAPOL-Start or EAPOL-Hello messages could contain the discovery > information... > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Tuesday, June 10, 2003 11:16 PM > > To: eap@frascone.com > > Subject: [eap] Issue 142: Contents of the EAP-Request/Identity > > > > > > Submitter name: Tim Moore > > Submitter email address: timmoore@microsoft.com > > Date first submitted: June 9, 2003 > > Reference: > > Document: EAP-03 > > Comment type: T > > Priority: S > > Section: 5.1 > > Rationale/Explanation of issue: > > > > Change: > > > > " This field MAY contain a displayable message in the > > Request, containing UTF-8 encoded ISO 10646 characters > > [RFC2279]. The Response uses this field to return the > > Identity. If the Identity is unknown, this field should be > > zero bytes in length. The field MUST NOT be null terminated. > > The length of this field is derived from the Length field of > > the Request/Response packet and hence a null is not required." > > > > To: > > > > " This field MAY contain a displayable message in the > > Request, containing UTF-8 encoded ISO 10646 characters > > [RFC2279]. Where the Request contains a null, only the > > portion of the field preceeding the null is displayed, with > > the rest used as a hint to the peer as to the identity to be > > provided in the Response, as described in Appendix A.2. If > > the Identity is unknown, the Identity Response field should > > be zero bytes in length. The Identity Response field MUST NOT > > be null terminated. In all cases, the length of the Type-Data > > field is derived from the Length field of the > > Request/Response packet." > > > > Add to Appendix A: > > > > "A.2 Contents of the Request/Identity Type-Data field > > > > So as to provide the peer with a hint as to the appropriate > > identity to place in the Type-Data field of the > > EAP-Response/Identity, the authenticator may wish to identity > > itself EAP-Request/Identity, in addition to providing a > > displayable message to the peer, such as an Appropriate Use > > Policy (AUP). > > > > The following format is proposed for the null-terminated > > displayable string and the comma-separated portion of the > > EAP-Request/Identity message > > string: > > > > \0networkid=,nasid=,po > > rtid= > > > > Where: > > > > network-name: Name of the network to which the authenticator connects. > > This is typically the SSID for IEEE 802.11. > > > > nas-name: Name or address of the NAS. > > > > > > port-id: port that the EAP session is on. > > > > The EAP peer should display display-string before the null termination > > (\0) to enable administrators to display network > > identification messages or appropriate use policies (AUPs)." > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > From jsalowey@cisco.com Thu Jun 12 04:42:45 2003 From: jsalowey@cisco.com (Joseph Salowey) Date: Wed, 11 Jun 2003 20:42:45 -0700 Subject: [eap] Re: submitting EAP-SIM document In-Reply-To: <062f01c32ad5$53c73270$23a50587@EDC> Message-ID: <004a01c33094$b06814d0$0200000a@amer.cisco.com> Hi Savar, Comments inline below. > -----Original Message----- > From: Sarvar Patel [mailto:sarvar@lucent.com] > Sent: Wednesday, June 04, 2003 1:10 PM > To: 'EAP mailing List'; Joseph Salowey > Cc: Blumenthal, Uri (Uri); sarvar > Subject: Re: [eap] Re: submitting EAP-SIM document > > > Hi Joe, > thanks for your response. My comments are inline. > > > With respect to only 64 bits of security this is indeed a > problem that > > has been overlooked (at least by me). I think the > appropriate action > > would be to revise the draft to require the client to check to make > > sure the RAND values within a request are different. > > What are your thoughts about including SRES in the MK > calculation, since it would add more secret material to the > MK even in the case of a single triplet, possibly providing > 96 bit of security. This is possible since, as I understand > it, the SRES is never exposed in the EAP-SIM protocol. The > EAP-Response/SIM/Challenge message creates and sends the MAC > of EAP|n*SRES but does not include the SRES values themselves. > [Joe] Within EAP-SIM SRES is secret so it would help. This is something I would like to consider when we upgrade the version of the protocol since it would not be a backward compatable change. > > Also EAP-SIM most definitely relies upon the secrecy of Kcs to > > maintain session independence. As you point out, we must > require that > > all triplets remain secret, because if an attacker obtains > RAND and Kc > > then he or she can act as the network. This is discussed > in several > > sections in the draft, but stronger wording on this fundamental > > assumption is probably warranted. > > I did notice your discussion on the need to keep triplets > secret which I found to be in tension with the requirement > for fresh triplets for every new instance of the protocol. > Let me explain: As I understand the EAP-SIM, like the GSM, > protocol specifies that at each different instance of the > protocol the authenticator would solicit fresh new triplets > to be used in authentication and session key generation with > the client. If so then it implies that the EAP-SIM protocol > is looking for session independence at the level of triplets > like in the GSM world where even if past triplets are > compromised or revealed, it has no impact on future sessions. > > But this triplet independence is not true of the EAP-SIM > protocol and as you specify all the triplets need to be kept > secret. [Joe] EAP-SIM builds mutual authenticaiton on top of the underlying GSM values. GSM does not provide mutual authentication so comparisons are difficult to make. As you know this is the root of the problem you describe. > This then prompts the question, why have the > requirement that fresh triplets are needed for every new > instance of the protocol? Here are two possible solutions > which do not require fresh triplets and will work assuming > that the authenticator is > trusted: > 1) Share the Ki with the authenticator and run a secure > mutual authentication and session key agreement protocol > (e.g. Bellare-Rogaway > protocol) [Joe] I agree that a much better protocol could be chosen if we had access to Ki. I especially like the suggestion of using something along the lines of Bellare-Rogaway protocol, I have used this in other contexts. > 2) If sharing Ki is not possible, then share n triplets once > with the authenticator and the reuse the triplets even with > new instances of protocols in the following manner. The > authenticator first shares the RANDs values with the client > and they both run a secure mutual authentication and session > key agreement protocol (e.g. Bellare-Rogaway protocol) using > Kc's as the root key. A protocol like Bellare-rogaway would > send its own random challenges to be used in creating the > responses and session key, unlike the current EAP-SIM > protocol which uses the RANDs as both a way to specify Kc > value and as challenges to use in response verifications. > > I suppose the point is that if one cares about session > independence at the triplet level, I don't know how to > achieve that. However, if one does not care about session > independence at the triplet level (that is the authenticator > is trusted) then one could specify a protocol where fresh > triplets are not needed. The current EAP-SIM would be > inefficient in the sense that even though it does not provide > session independence at the triplet level, it still requires > fresh triplets. At this point, I just wanted to make us aware > of these possibilities. [Joe] Yes, one could just create a secure protocol around a few static triplets. This is somewhat undesireable because it creates another entity in the network which maintains long term subscriber credentials in addition to the HLR. It also leaves the HLR/AuC out of the authentication/authorization loop. I think it might be beneficial to move more in the direction of EAP-AKA as it becomes more widely available. You might want to have a look at that specification as well (http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-09.txt) > > >In general I am less concerned about Kc exposure on > > the authenticator side than on the client side. This is > because with > >EAP-SIM triplets do not have to leave the home domain to facilitate > >roaming authentication (EAP-SIM typically terminates in the home > > network) which is different than the VLR model in GSM. On > the client > >side there are implementations that perform EAP-SIM > calculations on the > >SIM card that prevent triplet exposure. Nonetheless it is still a > >serious consideration. > > Hmm, why are you worried about the client side revealing Kc? > Is there an incentive for the client to find out the Kc, may > be you are thinking that an attacker who temporarily gets the > SIM card can find out the Kc and use it later to attack the > client. I guess my understanding is limitied on the exact > EAP-SIM use, but if Kc being compromised at the client is > alsoan issue then the above discussion has to be changed accordingly. > > thanks > Sarvar > > > Once again thanks for your time. I expect we will be updating the > > draft to address your comments in the near future. > > > > Regards, > > > > Joe > > > -----Original Message----- > > > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On > > > Behalf Of Uri Blumenthal > > > Sent: Thursday, May 29, 2003 11:30 AM > > > To: EAP mailing List > > > Cc: Sarvar Patel; 'S.Mizikovsky' > > > Subject: [eap] Re: submitting EAP-SIM document > > > > > > > > > Folks, > > > > > > My colleange Sarvar Patel asked me to post his analysis > > > of EAP-SIM draft. Here's the summary in short, and since > the entire > > > paper (in PDF) is only 16 KB, I'm attaching it to this posting. > > > > > > EAP-SIM specifies a mechanism for mutual authentication > and session > > > key agreement using the GSM-SIM and by proposing > enhancement to the > > > GSM authentication procedures. Unfortunately, as we show it does > > > not succeed in its goal of providing 128 bit security from the > > > current 64 bit security of GSM. Furthermore, it does not provide > > > session independence between different sessions. For the first > > > problem, we are > > > able to provide solutions, but the second problem does not > > > seem solvable > > > in practice. > > > > > > > > > > > From alper@docomolabs-usa.com Thu Jun 12 05:53:16 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Wed, 11 Jun 2003 21:53:16 -0700 Subject: [eap] Another stab at resolving Issue 121 In-Reply-To: Message-ID: > On the peer, once the method completes unsuccessfully (that is, either > the authenticator sends a method-specific failure indication, or the > peer decides that it does want to continue the conversation), the > peer MUST terminate the conversation and avoid sending data on the > link. Do we really have to say "peer MUST avoid sending data on the link"? We can note that EAP failure signals failed attempt to authorize, but I don't think we need to limit the actions of peer to simple going away. Also, "disabling link" concept applies to using EAP over link-layers, but not necessarily to PANA and IKEv2, unless we re-define the term "link" in here. > The peer MUST silently discard Success packets and MAY > silently discard Failure packets. As a result, > loss of a Failure packet need not result in a timeout. > If the peer attempts to authenticate to the authenticator and fails > to do so, the authenticator MUST send a Failure packet and MUST NOT > grant access by sending a Success packet. However, an authenticator > MAY NOT require that the peer authenticate to it in situations where > limited access is offered (e.g. guest access). In this case the > authenticator MAY send a Success packet. I'm not sure when this Success packet is sent. If authentication is not required, what is the sequence of events that leads to transmission of this message? Maybe you don't strictly mean EAP-Success here. Alper From aboba@internaut.com Thu Jun 12 07:04:20 2003 From: aboba@internaut.com (Bernard Aboba) Date: Wed, 11 Jun 2003 23:04:20 -0700 (PDT) Subject: [eap] Another stab at resolving Issue 121 In-Reply-To: References: Message-ID: > Do we really have to say "peer MUST avoid sending data on the link"? If we don't do this, then the peer could be sending data to a rogue Authenticator. This was one of the weaknesses found in the University of Maryland state machine analysis. > I'm not sure when this Success packet is sent. If authentication is not > required, what is the sequence of events that leads to transmission of this > message? The peer could authenticate the authenticator, but the authenticator might not need to authenticate the peer. As an example, EAP-TLS could be run without having the authenticator request the client certificate. The authenticator could then send a Success packet. From floroiu@fokus.fraunhofer.de Thu Jun 12 09:56:42 2003 From: floroiu@fokus.fraunhofer.de (John Williams Floroiu) Date: Thu, 12 Jun 2003 10:56:42 +0200 Subject: [eap] question on the scope of the master session keys References: Message-ID: <3EE8404A.7030601@fokus.fraunhofer.de> Clint, Thanks for the clarifications! > But, of course, this has nothing to do with the question you are asking. Well, it has somehow, because the key-mapping keys you mentioned are actually per-device keys. John. From mwatson@nortelnetworks.com Thu Jun 12 12:18:25 2003 From: mwatson@nortelnetworks.com (Mark Watson) Date: Thu, 12 Jun 2003 12:18:25 +0100 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C330D4.57802322 Content-Type: text/plain; charset="iso-8859-1" Could the same approach apply also to EAP Notifications ? A usecase for this (both in Identity & Notifications) is when the user has accounts with many WISPs and the particular WLAN supports users of one or more of them. The user needs to know the WISPs that are supported so that a choice of appropriate NAI can be made (potentially automatically). There are not necessarily separate SSIDs for each WISP. The list of supported WISPs could instead be made available 'out of band' (i.e. stickers in the window of a coffee shop), but this precludes automatic selection. Notifications have the advantage that a mapping from RADIUS Reply-Message to EAP Notification is already defined. So, the information can come from the RADIUS server/proxy in the case of an error due to an unrecognised Domain Name in the NAI. This places less burden on the AP. Additionally, in current 3GPP WLAN interworking work, a user can authenticate through any 3G Operator recognised by the WLAN, even though the user may have no account with that 3G Operator. This is achieved via the roaming agreements between 3G Operators. In this case the selection usually needs to be made automatically, based on information about roaming agreements configured in the user's terminal. I think the idea of a defined 'name=value' format with IANA registrations for names is a good one. Does this align with general practice ? I see we have only one example so far. Regards...Mark > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 29 May 2003 20:08 > To: Bernard Aboba > Cc: eap@frascone.com > Subject: Re: [eap] Re: deciding which NAI to send in an ID-RESPONSE > > > Bernard Aboba wrote: > >>We could (1) ignore such practise and pretend it doesn't > exist or (2) > >>change the definition to say that there may be a null, after which > >>the Displayable Message ends a Non-Displayble message begins ;-) > > > > > > Well, there apparently are some people who care about this > and want to use > > it for something. Perhaps if they spoke up we could > determine what to do. > > > > Off the top of my head, I would think that an Appendix > describing what is > > currently done might be appropriate. It also might make > sense to have an > > IANA registry for the parameters so that interoperability > is possible. > > On the other hand, I could also see handling this issue in > a separate > > draft if it is determined that the effort to specify this > is significant > > (and RFC 2284bis might be delayed). > > Yes. If we want to find something in between, one approach would be > to define that there may be a null character which terminates the > Displayable Message, and that the contents beyond that are > implementation > specific. This would at least warn people not to go beyond the null, > and leave the possibility for later to document the contents of > that field. > > --Jari > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > ------_=_NextPart_001_01C330D4.57802322 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Re: deciding which NAI to send in an = ID-RESPONSE

Could the same approach apply also to EAP = Notifications ?

A usecase for this (both in Identity & = Notifications) is when the user has accounts with many WISPs and the = particular WLAN supports users of one or more of them. The user needs = to know the WISPs that are supported so that a choice of appropriate = NAI can be made (potentially automatically). There are not necessarily = separate SSIDs for each WISP.

The list of supported WISPs could instead be made = available 'out of band' (i.e. stickers in the window of a coffee shop), = but this precludes automatic selection.

Notifications have the advantage that a mapping from = RADIUS Reply-Message to EAP Notification is already defined. So, the = information can come from the RADIUS server/proxy in the case of an = error due to an unrecognised Domain Name in the NAI. This places less = burden on the AP.

Additionally, in current 3GPP WLAN interworking work, = a user can authenticate through any 3G Operator recognised by the WLAN, = even though the user may have no account with that 3G Operator. This is = achieved via the roaming agreements between 3G Operators. In this case = the selection usually needs to be made automatically, based on = information about roaming agreements configured in the user's = terminal.

I think the idea of a defined 'name=3Dvalue' format = with IANA registrations for names is a good one. Does this align with = general practice ? I see we have only one example so far.

Regards...Mark

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: 29 May 2003 20:08
> To: Bernard Aboba
> Cc: eap@frascone.com
> Subject: Re: [eap] Re: deciding which NAI to = send in an ID-RESPONSE
>
>
> Bernard Aboba wrote:
> >>We could (1) ignore such practise and = pretend it doesn't
> exist or (2)
> >>change the definition to say that there = may be a null, after which
> >>the Displayable Message ends a = Non-Displayble message begins ;-)
> >
> >
> > Well, there apparently are some people who = care about this
> and want to use
> > it for something. Perhaps if they spoke up = we could
> determine what to do.
> >
> > Off the top of my head, I would think that = an Appendix
> describing what is
> > currently done might be appropriate. It = also might make
> sense to have an
> > IANA registry for the parameters so that = interoperability
> is possible.
> > On the other hand, I could also see = handling this issue in
> a separate
> > draft if it is determined that the effort = to specify this
> is significant
> > (and RFC 2284bis might be delayed).
>
> Yes. If we want to find something in between, = one approach would be
> to define that there may be a null character = which terminates the
> Displayable Message, and that the contents = beyond that are
> implementation
> specific. This would at least warn people not = to go beyond the null,
> and leave the possibility for later to document = the contents of
> that field.
>
> --Jari
>
>
> = _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>

------_=_NextPart_001_01C330D4.57802322-- From jari.arkko@piuha.net Thu Jun 12 13:50:25 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 12 Jun 2003 15:50:25 +0300 Subject: [eap] Another stab at resolving Issue 121 In-Reply-To: References: Message-ID: <3EE87711.3090403@piuha.net> Bernard Aboba wrote: >>Do we really have to say "peer MUST avoid sending data on the link"? > > If we don't do this, then the peer could be sending data to a rogue > Authenticator. This was one of the weaknesses found in the University of > Maryland state machine analysis. Yes. I agree with Alper that "link" may not be the right terminology in the case of PANA or IKEv2. But it may be easier to deal with that by having those protocols define what they mean as the "link". For instance, IKEv2 could say that in these situations one should not create any IPsec SAs. Anyway, I like Bernard's text. I have edited the second to last paragraph slightly, however, in order to take in account the following: - Yoshi's MAY NOT problem - Joe's reformulation (further edited, hope its ok for Joe) Here's the suggested new text: If the peer attempts to authenticate to the authenticator and fails to do so, the authenticator MUST send a Failure packet and MUST NOT grant access by sending a Success packet. However, an authenticator MAY not require that the peer authenticate to it in situations where limited access is offered (e.g. guest access). If this is the case, the authenticator MUST send a Success packet. --Jari From mwatson@nortelnetworks.com Thu Jun 12 13:51:03 2003 From: mwatson@nortelnetworks.com (Mark Watson) Date: Thu, 12 Jun 2003 13:51:03 +0100 Subject: [eap] Issue 142: Contents of the EAP-Request/Identity Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C330E1.484C7B14 Content-Type: text/plain; charset="iso-2022-jp" It is certainly possible that for a single WLAN ESS (i.e. one SSID), there are several possible WISPs or other organisations that can provide authentication. The user identifies the domain they wish to use for authentication in the domain portion of the NAI and the AP (or RADIUS proxy) routes the Auth request (EAP Response/Identity) to the correct place. You cannot expect information about the possible domains supported by a given WLAN to be obvious from the SSID. Nor can you expect a trial and error approach on the part of the user (i.e. trying different NAI domains until one works), since there may be many possible NAI domains that the user could authenticate with. So, I think there is still a requirement to provide information about the supported authentication domains within the context of a single autenticator/ESS/802.1X system (or whatever the correct term is). The selection decision based on this information is taken subsequent to a decision on which AP/SSID/802.1X authenticator to use, which as noted below can be based on the Beacon frames, or PANA etc. ...Mark > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 10 June 2003 17:20 > To: CONGDON,PAUL (HP-Roseville,ex1) > Cc: 'Bernard Aboba'; eap@frascone.com > Subject: Re: [eap] Issue 142: Contents of the EAP-Request/Identity > > > I agree with Paul on not including the information (AUP, networkid, > nasid, portid) in EAP message. Such information should be provided > before a peer chooses an appropriate authenticaticator with which it > starts EAP conversation. In this sense, including the information in > 802.1X frame might also be too late. On the other hand, AUP should be > provided in a stateless fashon, because a user on a peer > device tends to > take more time to read the AUP and make a decision to whether it > should start EAP conversation with the EAP authenticator that > originated the AUP. > > Thus, I think the appropriate place is containing it in Beacon frame > in the case of 802.11 and in PANA authentication agent discovery > exchange in the case of PANA. Of course the size of AUP text should > be as small as possible so that it does not consume the bandwidth. > > Yoshihiro Ohba > > On Wed, Jun 11, 2003 at 10:46:38AM -0400, CONGDON,PAUL > (HP-Roseville,ex1) wrote: > > > > Seems like this should really be considered at the link layer? New > > EAPOL-Start or EAPOL-Hello messages could contain the discovery > > information... > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: Tuesday, June 10, 2003 11:16 PM > > > To: eap@frascone.com > > > Subject: [eap] Issue 142: Contents of the EAP-Request/Identity > > > > > > > > > Submitter name: Tim Moore > > > Submitter email address: timmoore@microsoft.com > > > Date first submitted: June 9, 2003 > > > Reference: > > > Document: EAP-03 > > > Comment type: T > > > Priority: S > > > Section: 5.1 > > > Rationale/Explanation of issue: > > > > > > Change: > > > > > > " This field MAY contain a displayable message in the > > > Request, containing UTF-8 encoded ISO 10646 characters > > > [RFC2279]. The Response uses this field to return the > > > Identity. If the Identity is unknown, this field should be > > > zero bytes in length. The field MUST NOT be null terminated. > > > The length of this field is derived from the Length field of > > > the Request/Response packet and hence a null is not required." > > > > > > To: > > > > > > " This field MAY contain a displayable message in the > > > Request, containing UTF-8 encoded ISO 10646 characters > > > [RFC2279]. Where the Request contains a null, only the > > > portion of the field preceeding the null is displayed, with > > > the rest used as a hint to the peer as to the identity to be > > > provided in the Response, as described in Appendix A.2. If > > > the Identity is unknown, the Identity Response field should > > > be zero bytes in length. The Identity Response field MUST NOT > > > be null terminated. In all cases, the length of the Type-Data > > > field is derived from the Length field of the > > > Request/Response packet." > > > > > > Add to Appendix A: > > > > > > "A.2 Contents of the Request/Identity Type-Data field > > > > > > So as to provide the peer with a hint as to the appropriate > > > identity to place in the Type-Data field of the > > > EAP-Response/Identity, the authenticator may wish to identity > > > itself EAP-Request/Identity, in addition to providing a > > > displayable message to the peer, such as an Appropriate Use > > > Policy (AUP). > > > > > > The following format is proposed for the null-terminated > > > displayable string and the comma-separated portion of the > > > EAP-Request/Identity message > > > string: > > > > > > \0networkid=,nasid=,po > > > rtid= > > > > > > Where: > > > > > > network-name: Name of the network to which the > authenticator connects. > > > This is typically the SSID for IEEE 802.11. > > > > > > nas-name: Name or address of the NAS. > > > > > > > > > port-id: port that the EAP session is on. > > > > > > The EAP peer should display display-string before the > null termination > > > (\0) to enable administrators to display network > > > identification messages or appropriate use policies (AUPs)." > > > > > > _______________________________________________ > > > eap mailing list > > > eap@frascone.com > > > http://mail.frascone.com/mailman/listinfo/eap > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > ------_=_NextPart_001_01C330E1.484C7B14 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable RE: [eap] Issue 142: Contents of the = EAP-Request/Identity

<this is related to my earlier message, but at = that time I hadn't spotted this thread>

It is certainly possible that for a single WLAN ESS = (i.e. one SSID), there are several possible WISPs or other = organisations that can provide authentication. The user identifies the = domain they wish to use for authentication in the domain portion of the = NAI and the AP (or RADIUS proxy) routes the Auth request (EAP = Response/Identity) to the correct place.

You cannot expect information about the possible = domains supported by a given WLAN to be obvious from the SSID.

Nor can you expect a trial and error approach on the = part of the user (i.e. trying different NAI domains until one works), = since there may be many possible NAI domains that the user could = authenticate with.

So, I think there is still a requirement to provide = information about the supported authentication domains within the = context of a single autenticator/ESS/802.1X system (or whatever the = correct term is). The selection decision based on this information is = taken subsequent to a decision on which AP/SSID/802.1X authenticator to = use, which as noted below can be based on the Beacon frames, or PANA = etc.

...Mark

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com= ]
> Sent: 10 June 2003 17:20
> To: CONGDON,PAUL (HP-Roseville,ex1)
> Cc: 'Bernard Aboba'; eap@frascone.com
> Subject: Re: [eap] Issue 142: Contents of the = EAP-Request/Identity
>
>
> I agree with Paul on not including the = information (AUP, networkid,
> nasid, portid) in EAP message.  Such = information should be provided
> before a peer chooses an appropriate = authenticaticator with which it
> starts EAP conversation.  In this sense, = including the information in
> 802.1X frame might also be too late.  On = the other hand, AUP should be
> provided in a stateless fashon, because a user = on a peer
> device tends to
> take more time to read the AUP and make a = decision to whether it
> should start EAP conversation with the EAP = authenticator that
> originated the AUP.
>
> Thus, I think the appropriate place is = containing it in Beacon frame
> in the case of 802.11 and in PANA = authentication agent discovery
> exchange in the case of PANA.  Of course = the size of AUP text should
> be as small as possible so that it does not = consume the bandwidth.
> 
> Yoshihiro Ohba
>
> On Wed, Jun 11, 2003 at 10:46:38AM -0400, = CONGDON,PAUL
> (HP-Roseville,ex1) wrote:
> >
> > Seems like this should really be = considered at the link layer?   New
> > EAPOL-Start or EAPOL-Hello messages could = contain the discovery
> > information...
> >
> > > -----Original Message-----
> > > From: Bernard Aboba [mailto:aboba@internaut.com] =
> > > Sent: Tuesday, June 10, 2003 11:16 = PM
> > > To: eap@frascone.com
> > > Subject: [eap] Issue 142: Contents of = the EAP-Request/Identity
> > >
> > >
> > > Submitter name: Tim Moore
> > > Submitter email address: = timmoore@microsoft.com
> > > Date first submitted: June 9, = 2003
> > > Reference:
> > > Document: EAP-03
> > > Comment type: T
> > > Priority: S
> > > Section: 5.1
> > > Rationale/Explanation of = issue:
> > >
> > > Change:
> > >
> > > " This field MAY contain a = displayable message in the
> > > Request, containing UTF-8 encoded ISO = 10646 characters
> > > [RFC2279]. The Response uses this = field to return the
> > > Identity. If the Identity is unknown, = this field should be
> > > zero bytes in length. The field MUST = NOT be null terminated.
> > > The length of this field is derived = from the Length field of
> > > the Request/Response packet and hence = a null is not required."
> > >
> > > To:
> > >
> > > " This field MAY contain a = displayable message in the
> > > Request, containing UTF-8 encoded ISO = 10646 characters
> > > [RFC2279]. Where the Request contains = a null, only the
> > > portion of the field preceeding the = null is displayed, with
> > > the rest used as a hint to the peer = as to the identity to be
> > > provided in the Response, as = described in Appendix A.2. If
> > > the Identity is unknown, the Identity = Response field should
> > > be zero bytes in length. The Identity = Response field MUST NOT
> > > be null terminated. In all cases, the = length of the Type-Data
> > > field is derived from the Length = field of the
> > > Request/Response packet."
> > >
> > > Add to Appendix A:
> > >
> > > "A.2 Contents of the = Request/Identity Type-Data field
> > >
> > > So as to provide the peer with a hint = as to the appropriate
> > > identity to place in the Type-Data = field of the
> > > EAP-Response/Identity, the = authenticator may wish to identity
> > > itself EAP-Request/Identity, in = addition to providing a
> > > displayable message to the peer, such = as an Appropriate Use
> > > Policy (AUP).
> > >
> > > The following format is proposed for = the null-terminated
> > > displayable string and the = comma-separated portion of the
> > > EAP-Request/Identity message
> > > string:
> > >
> > > = <display-string>\0networkid=3D<network-name>,nasid=3D<nas= -name>,po
> > > rtid=3D<port-id>
> > >
> > > Where:
> > >
> > > network-name: Name of the network to = which the
> authenticator connects.
> > = >           &n= bsp;   This is typically the SSID for IEEE 802.11.
> > >
> > > nas-name: Name or address of the = NAS.
> > >
> > >
> > > port-id: port that the EAP session is = on.
> > >
> > > The EAP peer should display = display-string before the
> null termination
> > > (\0) to enable administrators to = display network
> > > identification messages or = appropriate use policies (AUPs)."
> > >
> > > = _______________________________________________
> > > eap mailing list
> > > eap@frascone.com
> > > http://mail.frascone.com/mailman/listinfo/eap
> > >
> > = _______________________________________________
> > eap mailing list
> > eap@frascone.com
> > http://mail.frascone.com/mailman/listinfo/eap
> >
> = _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>

------_=_NextPart_001_01C330E1.484C7B14-- From aboba@internaut.com Thu Jun 12 13:58:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Jun 2003 05:58:18 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: References: Message-ID: > WISPs may not have their own SSIDs Is this due to a limitation of current APs that could be removed? For example, if some large number of virtual APs could be defined (say, 255) per AP, so that each WISP could have their own SSIDs, would there be a need for additional information as well? If so, how much information are we talking about? Remember that EAP-Request/Identity (or Notification) doesn't support fragmentation, so it's limited by the MTU size. > Notifications have the advantage that a mapping from RADIUS Reply-Message to > EAP Notification is already defined. Please check RFC 2869bis -- use of RADIUS Reply-Message is deprecated for use with EAP. Use of Notification is preferred. However, in this case it seems like EAP-Request/Identity might make more sense, given the purpose of the displayable message. > So, the information can come from the > RADIUS server/proxy in the case of an error due to an unrecognised Domain > Name in the NAI. This places less burden on the AP. I don't understand why Notification is a burden on the AP -- it's just handled like any other EAP message. > I think the idea of a defined 'name=value' format with IANA registrations > for names is a good one. Does this align with general practice ? I see we > have only one example so far. RFC 2284 states that Notification is for delivery of a displayable messages, and that is what it is used for, as I understand it. Since a Notification Response is sent automatically, there is no way for the sender to know that the peer understood the message, or even that the message was displayed (the peer responds immediately, and doesn't wait until it has done the displaying to reply). On the other hand, some APs do use the name=value format today within EAP-Request/Identity messages, for the purpose of identifying the AP. However, I don't think that EAP peer implementations do anything with it. The problem with going down the road of defining new 'name=value' parameters is that this could create interoperability problems unless the parameters were only treated as hints -- if the wrong NAI is sent, then the displayable message part of the EAP-Request/Identity is set to indicate that. From aboba@internaut.com Thu Jun 12 14:07:17 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Jun 2003 06:07:17 -0700 (PDT) Subject: [eap] Another stab at resolving Issue 121 In-Reply-To: <3EE87711.3090403@piuha.net> References: <3EE87711.3090403@piuha.net> Message-ID: > Here's the suggested new text: > > If the peer attempts to authenticate to the authenticator and > fails to do so, the authenticator MUST send a Failure packet > and MUST NOT grant access by sending a Success packet. > However, an authenticator MAY not require that the peer > authenticate to it in situations where limited access is > offered (e.g. guest access). If this is the case, the > authenticator MUST send a Success packet. I've updated the Issue 121 text to include this. From aboba@internaut.com Thu Jun 12 14:09:12 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Jun 2003 06:09:12 -0700 (PDT) Subject: [eap] Proposed Resolution of Issue 131: Message-ID: The text of Issue 131 is enclosed below. In Issue 121 we have defined the circumstances in which the peer may eventually conclude that a Success packet has been lost. In those same circumstances, the proposed change in Issue 131 allows the peer to conclude that a Success packet has been lost, without having to wait the full timeout period. It therefore represents an optimization. Here are the proposed fixes: In Section 3.4, Change: "Lower layer failure indications provided to EAP by the lower layer MUST be processed and will cause an EAP exchange in progress to be aborted. However, lower layer success indications MUST NOT affect EAP message processing so that an EAP implementation MUST NOT conclude that authentication has succeeded based on those indications." To: "Section 4.2 defines the circumstances in which a peer, having concluded an EAP method with successful acknowledged result indications, may conclude that a Success packet has been lost after expiration of a timeout. In those same circumstances, if a peer receives a lower layer success indication as defined in Section 7.12, it MAY conclude that a Success packet has been lost without waiting for a timeout." In Section 7.12, change: " [c] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer indications include Disassociate and Deauthenticate frames (link failure indications), and Association and Reassociation Response frames (link success indications). These messages are not authenticated or integrity protected, and although they are not forwardable, they are spoofable by an attacker within range." To: " [c] IEEE 802.11 wireless LANs. In IEEE 802.11, link layer indications include Disassociate and Deauthenticate frames (link failure indications), and the first message of the 4-way handshake (link success indication). These messages are not authenticated or integrity protected, and although they are not forwardable, they are spoofable by an attacker within range." From jari.arkko@piuha.net Thu Jun 12 14:38:06 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 12 Jun 2003 16:38:06 +0300 Subject: [eap] Issue 142: Contents of the EAP-Request/Identity In-Reply-To: <20030610161935.GD6685@steelhead> References: <499DC368E25AD411B3F100902740AD6512992B3D@xrose03.rose.hp.com> <20030610161935.GD6685@steelhead> Message-ID: <3EE8823E.1030103@piuha.net> Several issues relate to this problem. One issue is that there's existing deployment where the nul character is used to separate a message and a some other information in EAP Identity Request. Another issue is how to represent AUPs. A third issue is how to represent parameters to the peer, and if such parameters are needed in the first place. Given that we have a deployed protocol, I'd suggest the following approach: 1. We need to document that there can be a nul character in the data part of EAP Identity Request, and that the message should only be displayed until the nul. 2. Perhaps we should not say too much about the use of the field after the nul. Certainly no normative text. I don't think appendix A is the right place for this text. I would try to cut the text down and just place it as a note in the place where the EAP Identity REquest is discussed. Like this, for example: Note: Some existing implementations are known to pass parameters after the nul character. Support for such parameters is implementation specific, but where used their format SHOULD be a comma separated list of parameter=value assignments. 3. Lets not claim anything about the AUP in the text. I agree that its probably best done at the link layer, but this may not always be possible. If it isn't possible then the message in the identity request may be used for that purpose. However, I wouldn't write that down in the spec as I don't think that would the recommended practise. --Jari From mwatson@nortelnetworks.com Thu Jun 12 15:07:14 2003 From: mwatson@nortelnetworks.com (Mark Watson) Date: Thu, 12 Jun 2003 15:07:14 +0100 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C330EB.ED07A0B6 Content-Type: text/plain; charset="iso-8859-1" Hi Bernard, Comments below... I am looking for a solution which places minimum new requirements on elements in the WLAN network - that is the AP and any RADIUS proxies used to route authentication signalling to/from the WISPs that do the actual authentication. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: 12 June 2003 13:58 > To: Watson, Mark [MOP:EP10:EXCH] > Cc: 'jari.arkko@piuha.net'; eap@frascone.com > Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE > > > > WISPs may not have their own SSIDs > > Is this due to a limitation of current APs that could be removed? For > example, if some large number of virtual APs could be defined > (say, 255) > per AP, so that each WISP could have their own SSIDs, would there be a > need for additional information as well? If so, how much > information are > we talking about? Remember that EAP-Request/Identity (or > Notification) > doesn't support fragmentation, so it's limited by the MTU size. > An example: I was in Oslo airport the other day. Oslo airport has a WLAN with a single SSID (well, I could only see one). Oslo airport has agreements with several WISPs. I can authenticate through any of those. SSID limitations or otherwise, I don't think you can require the WLAN owner to provision a separate SSID for each WISP with whom they have an agreement. Further, only one SSID can be broadcast - which one ? Where do I get info about the other SSID's available - if that's from the default WLAN (broadcast SSID) then access to any of the others will be slow (have to associate with the broadcast one first to get the info etc. etc.). The user may know too many domains throught which they can authenticate to try a probe for each one (e.g. 3G case). > > Notifications have the advantage that a mapping from RADIUS > Reply-Message to > > EAP Notification is already defined. > > Please check RFC 2869bis -- use of RADIUS Reply-Message is > deprecated for use with EAP. Use of Notification is preferred. > However, in this case it seems like EAP-Request/Identity > might make more > sense, given the purpose of the displayable message. > > > So, the information can come from the > > RADIUS server/proxy in the case of an error due to an > unrecognised Domain > > Name in the NAI. This places less burden on the AP. > > I don't understand why Notification is a burden on the AP -- it's just > handled like any other EAP message. > I was comparing with putting the info in the Request/Identity. Putting the info in the Request/Identity, if I understand correctly, is a burden on the AP, because the Request/Identity is generated by the AP. Perhaps, though, a subsqeuent Request/Identity after an unrecognised NAI domain error could be generated by the RADIUS proxy detecting this ? But this proxy does not otherwise need to understand EAP. > > I think the idea of a defined 'name=value' format with IANA > registrations > > for names is a good one. Does this align with general > practice ? I see we > > have only one example so far. > > RFC 2284 states that Notification is for delivery of a displayable > messages, and that is what it is used for, as I understand > it. Since a > Notification Response is sent automatically, there is no way for the > sender to know that the peer understood the message, or even that the > message was displayed (the peer responds immediately, and doesn't wait > until it has done the displaying to reply). > > On the other hand, some APs do use the name=value format today within > EAP-Request/Identity messages, for the purpose of identifying the > AP. However, I don't think that EAP peer implementations do > anything with it. > > The problem with going down the road of defining new 'name=value' > parameters is that this could create interoperability > problems unless the > parameters were only treated as hints -- if the wrong NAI is > sent, then > the displayable message part of the EAP-Request/Identity is set to > indicate that. Sure, I would expect this information to be a 'hint' about the NAI domains that *are* supported. You can ignore it if you like & try a different domain, but then you'll get an error response. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > ------_=_NextPart_001_01C330EB.ED07A0B6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Re: deciding which NAI to send in an = ID-RESPONSE

Hi Bernard,

Comments below...

I am looking for a solution which places minimum new = requirements on elements in the WLAN network - that is the AP and any = RADIUS proxies used to route authentication signalling to/from the = WISPs that do the actual authentication.

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: 12 June 2003 13:58
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: 'jari.arkko@piuha.net'; = eap@frascone.com
> Subject: RE: [eap] Re: deciding which NAI to = send in an ID-RESPONSE
>
>
> > WISPs may not have their own SSIDs
>
> Is this due to a limitation of current APs that = could be removed?  For
> example, if some large number of virtual APs = could be defined
> (say, 255)
> per AP, so that each WISP could have their own = SSIDs, would there be a
> need for additional information as well?  = If so, how much
> information are
> we talking about?  Remember that = EAP-Request/Identity (or
> Notification)
> doesn't support fragmentation, so it's limited = by the MTU size.
>

An example: I was in Oslo airport the other day. Oslo = airport has a WLAN with a single SSID (well, I could only see one). = Oslo airport has agreements with several WISPs. I can authenticate = through any of those. SSID limitations or otherwise, I don't think you = can require the WLAN owner to provision a separate SSID for each WISP = with whom they have an agreement.

Further, only one SSID can be broadcast - which one ? = Where do I get info about the other SSID's available - if that's from = the default WLAN (broadcast SSID) then access to any of the others will = be slow (have to associate with the broadcast one first to get the info = etc. etc.).

The user may know too many domains throught which = they can authenticate to try a probe for each one (e.g. 3G = case).

> > Notifications have the advantage that a = mapping from RADIUS
> Reply-Message to
> > EAP Notification is already = defined.
>
> Please check RFC 2869bis -- use of RADIUS = Reply-Message is
> deprecated for use with EAP.  Use of = Notification is preferred.
> However, in this case it seems like = EAP-Request/Identity
> might make more
> sense, given the purpose of the displayable = message.
>
> > So, the information can come from = the
> > RADIUS server/proxy in the case of an = error due to an
> unrecognised Domain
> > Name in the NAI. This places less burden = on the AP.
>
> I don't understand why Notification is a burden = on the AP -- it's just
> handled like any other EAP message.
>

I was comparing with putting the info in the = Request/Identity.

Putting the info in the Request/Identity, if I = understand correctly, is a burden on the AP, because the = Request/Identity is generated by the AP. Perhaps, though, a subsqeuent = Request/Identity after an unrecognised NAI domain error could be = generated by the RADIUS proxy detecting this ? But this proxy does not = otherwise need to understand EAP.

> > I think the idea of a defined = 'name=3Dvalue' format with IANA
> registrations
> > for names is a good one. Does this align = with general
> practice ? I see we
> > have only one example so far.
>
> RFC 2284 states that Notification is for = delivery of a displayable
> messages, and that is what it is used for, as I = understand
> it.  Since a
> Notification Response is sent automatically, = there is no way for the
> sender to know that the peer understood the = message, or even that the
> message was displayed (the peer responds = immediately, and doesn't wait
> until it has done the displaying to = reply).
>
> On the other hand, some APs do use the = name=3Dvalue format today within
> EAP-Request/Identity messages, for the purpose = of identifying the
> AP. However, I don't think that EAP peer = implementations do
> anything with it.
>
> The problem with going down the road of = defining new 'name=3Dvalue'
> parameters is that this could create = interoperability
> problems unless the
> parameters were only treated as hints -- if the = wrong NAI is
> sent, then
> the displayable message part of the = EAP-Request/Identity is set to
> indicate that.

Sure, I would expect this information to be a 'hint' = about the NAI domains that *are* supported. You can ignore it if you = like & try a different domain, but then you'll get an error = response.

> = _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>

------_=_NextPart_001_01C330EB.ED07A0B6-- From cchaplin@sj.symbol.com Thu Jun 12 17:54:11 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Thu, 12 Jun 2003 09:54:11 -0700 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: Wi-Fi or IEEE has >got< to move forward on Virtual APs, or these sorts of = issues are going to keep coming up. Several companies have investigated this issue, and there are several ways = to solve it, some of which include a separate beacon for each SSID. All = solutions have problems with certain existing client implementations, and = some of them are pushing the IEEE 802.11 standard in ways it wasn't = designed to go. (Bernard, I know I'm preaching to the choir with you; = I've seen your Virtual AP presentation you gave at Wi-Fi last week). If speed is essential, the Wi-Fi is the only approprate venue, but if = changes need to be made to the standard, then IEEE needs to be present. Clint (JOATMON) Chaplin >>> "Mark Watson" 6/12/03 07:07:14 >>> Hi Bernard, Comments below... I am looking for a solution which places minimum new requirements on elements in the WLAN network - that is the AP and any RADIUS proxies used = to route authentication signalling to/from the WISPs that do the actual authentication. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: 12 June 2003 13:58 > To: Watson, Mark [MOP:EP10:EXCH] > Cc: 'jari.arkko@piuha.net'; eap@frascone.com=20 > Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE >=20 >=20 > > WISPs may not have their own SSIDs >=20 > Is this due to a limitation of current APs that could be removed? For > example, if some large number of virtual APs could be defined=20 > (say, 255) > per AP, so that each WISP could have their own SSIDs, would there be a > need for additional information as well? If so, how much=20 > information are > we talking about? Remember that EAP-Request/Identity (or=20 > Notification) > doesn't support fragmentation, so it's limited by the MTU size. >=20 An example: I was in Oslo airport the other day. Oslo airport has a WLAN with a single SSID (well, I could only see one). Oslo airport has = agreements with several WISPs. I can authenticate through any of those. SSID limitations or otherwise, I don't think you can require the WLAN owner to provision a separate SSID for each WISP with whom they have an agreement. Further, only one SSID can be broadcast - which one ? Where do I get info about the other SSID's available - if that's from the default WLAN (broadcast SSID) then access to any of the others will be slow (have to associate with the broadcast one first to get the info etc. etc.). The user may know too many domains throught which they can authenticate to try a probe for each one (e.g. 3G case). > > Notifications have the advantage that a mapping from RADIUS=20 > Reply-Message to > > EAP Notification is already defined. >=20 > Please check RFC 2869bis -- use of RADIUS Reply-Message is > deprecated for use with EAP. Use of Notification is preferred. > However, in this case it seems like EAP-Request/Identity=20 > might make more > sense, given the purpose of the displayable message. >=20 > > So, the information can come from the > > RADIUS server/proxy in the case of an error due to an=20 > unrecognised Domain > > Name in the NAI. This places less burden on the AP. >=20 > I don't understand why Notification is a burden on the AP -- it's just > handled like any other EAP message. >=20 I was comparing with putting the info in the Request/Identity. Putting the info in the Request/Identity, if I understand correctly, is a burden on the AP, because the Request/Identity is generated by the AP. Perhaps, though, a subsqeuent Request/Identity after an unrecognised NAI domain error could be generated by the RADIUS proxy detecting this ? But this proxy does not otherwise need to understand EAP. > > I think the idea of a defined 'name=3Dvalue' format with IANA=20 > registrations > > for names is a good one. Does this align with general=20 > practice ? I see we > > have only one example so far. >=20 > RFC 2284 states that Notification is for delivery of a displayable > messages, and that is what it is used for, as I understand=20 > it. Since a > Notification Response is sent automatically, there is no way for the > sender to know that the peer understood the message, or even that the > message was displayed (the peer responds immediately, and doesn't wait > until it has done the displaying to reply). >=20 > On the other hand, some APs do use the name=3Dvalue format today within > EAP-Request/Identity messages, for the purpose of identifying the > AP. However, I don't think that EAP peer implementations do=20 > anything with it. >=20 > The problem with going down the road of defining new 'name=3Dvalue' > parameters is that this could create interoperability=20 > problems unless the > parameters were only treated as hints -- if the wrong NAI is=20 > sent, then > the displayable message part of the EAP-Request/Identity is set to > indicate that. Sure, I would expect this information to be a 'hint' about the NAI domains that *are* supported. You can ignore it if you like & try a different domain, but then you'll get an error response. > _______________________________________________ > eap mailing list > eap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/eap=20 >=20 ________________________________________________________________________ This email has been scanned for computer viruses. From mwatson@nortelnetworks.com Thu Jun 12 18:09:35 2003 From: mwatson@nortelnetworks.com (Mark Watson) Date: Thu, 12 Jun 2003 18:09:35 +0100 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33104.E4496E96 Content-Type: text/plain; charset="iso-8859-1" Clint, Virtual APs, implying a separate beacon for each SSID is certainly a solution to this problem, but I am looking for a solution which does not impact the AP. This problem will exist for WLANs that are being deployed now - even if a virtual AP solution was fully agreed and standardised now, then we couldn't wait for it to be implemented. ...Mark > -----Original Message----- > From: Clint Chaplin [mailto:cchaplin@sj.symbol.com] > Sent: 12 June 2003 17:54 > To: aboba@internaut.com; Watson, Mark [MOP:EP10:EXCH] > Cc: hworstell@att.com; eap@frascone.com; apetrick@icefyre.com; > stuart.kerry@philips.com; jari.arkko@piuha.net > Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE > > > Wi-Fi or IEEE has >got< to move forward on Virtual APs, or > these sorts of issues are going to keep coming up. > > Several companies have investigated this issue, and there are > several ways to solve it, some of which include a separate > beacon for each SSID. All solutions have problems with > certain existing client implementations, and some of them are > pushing the IEEE 802.11 standard in ways it wasn't designed > to go. (Bernard, I know I'm preaching to the choir with you; > I've seen your Virtual AP presentation you gave at Wi-Fi last week). > > If speed is essential, the Wi-Fi is the only approprate > venue, but if changes need to be made to the standard, then > IEEE needs to be present. > > Clint (JOATMON) Chaplin > > >>> "Mark Watson" 6/12/03 07:07:14 >>> > Hi Bernard, > > Comments below... > > I am looking for a solution which places minimum new requirements on > elements in the WLAN network - that is the AP and any RADIUS > proxies used to > route authentication signalling to/from the WISPs that do the actual > authentication. > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 12 June 2003 13:58 > > To: Watson, Mark [MOP:EP10:EXCH] > > Cc: 'jari.arkko@piuha.net'; eap@frascone.com > > Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE > > > > > > > WISPs may not have their own SSIDs > > > > Is this due to a limitation of current APs that could be > removed? For > > example, if some large number of virtual APs could be defined > > (say, 255) > > per AP, so that each WISP could have their own SSIDs, would > there be a > > need for additional information as well? If so, how much > > information are > > we talking about? Remember that EAP-Request/Identity (or > > Notification) > > doesn't support fragmentation, so it's limited by the MTU size. > > > > An example: I was in Oslo airport the other day. Oslo airport > has a WLAN > with a single SSID (well, I could only see one). Oslo airport > has agreements > with several WISPs. I can authenticate through any of those. SSID > limitations or otherwise, I don't think you can require the > WLAN owner to > provision a separate SSID for each WISP with whom they have > an agreement. > > Further, only one SSID can be broadcast - which one ? Where > do I get info > about the other SSID's available - if that's from the default WLAN > (broadcast SSID) then access to any of the others will be > slow (have to > associate with the broadcast one first to get the info etc. etc.). > > The user may know too many domains throught which they can > authenticate to > try a probe for each one (e.g. 3G case). > > > > Notifications have the advantage that a mapping from RADIUS > > Reply-Message to > > > EAP Notification is already defined. > > > > Please check RFC 2869bis -- use of RADIUS Reply-Message is > > deprecated for use with EAP. Use of Notification is preferred. > > However, in this case it seems like EAP-Request/Identity > > might make more > > sense, given the purpose of the displayable message. > > > > > So, the information can come from the > > > RADIUS server/proxy in the case of an error due to an > > unrecognised Domain > > > Name in the NAI. This places less burden on the AP. > > > > I don't understand why Notification is a burden on the AP > -- it's just > > handled like any other EAP message. > > > > I was comparing with putting the info in the Request/Identity. > > Putting the info in the Request/Identity, if I understand > correctly, is a > burden on the AP, because the Request/Identity is generated by the AP. > Perhaps, though, a subsqeuent Request/Identity after an > unrecognised NAI > domain error could be generated by the RADIUS proxy detecting > this ? But > this proxy does not otherwise need to understand EAP. > > > > I think the idea of a defined 'name=value' format with IANA > > registrations > > > for names is a good one. Does this align with general > > practice ? I see we > > > have only one example so far. > > > > RFC 2284 states that Notification is for delivery of a displayable > > messages, and that is what it is used for, as I understand > > it. Since a > > Notification Response is sent automatically, there is no way for the > > sender to know that the peer understood the message, or > even that the > > message was displayed (the peer responds immediately, and > doesn't wait > > until it has done the displaying to reply). > > > > On the other hand, some APs do use the name=value format > today within > > EAP-Request/Identity messages, for the purpose of identifying the > > AP. However, I don't think that EAP peer implementations do > > anything with it. > > > > The problem with going down the road of defining new 'name=value' > > parameters is that this could create interoperability > > problems unless the > > parameters were only treated as hints -- if the wrong NAI is > > sent, then > > the displayable message part of the EAP-Request/Identity is set to > > indicate that. > > Sure, I would expect this information to be a 'hint' about > the NAI domains > that *are* supported. You can ignore it if you like & try a different > domain, but then you'll get an error response. > > > _______________________________________________ > > eap mailing list > > eap@frascone.com > > http://mail.frascone.com/mailman/listinfo/eap > > > > > ______________________________________________________________ > __________ > This email has been scanned for computer viruses. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > ------_=_NextPart_001_01C33104.E4496E96 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Re: deciding which NAI to send in an = ID-RESPONSE

Clint,

Virtual APs, implying a separate beacon for each SSID = is certainly a solution to this problem, but I am looking for a = solution which does not impact the AP. This problem will exist for = WLANs that are being deployed now - even if a virtual AP solution was = fully agreed and standardised now, then we couldn't wait for it to be = implemented.

...Mark

> -----Original Message-----
> From: Clint Chaplin [mailto:cchaplin@sj.symbol.com= ]
> Sent: 12 June 2003 17:54
> To: aboba@internaut.com; Watson, Mark = [MOP:EP10:EXCH]
> Cc: hworstell@att.com; eap@frascone.com; = apetrick@icefyre.com;
> stuart.kerry@philips.com; = jari.arkko@piuha.net
> Subject: RE: [eap] Re: deciding which NAI to = send in an ID-RESPONSE
>
>
> Wi-Fi or IEEE has >got< to move forward = on Virtual APs, or
> these sorts of issues are going to keep coming = up.
>
> Several companies have investigated this issue, = and there are
> several ways to solve it, some of which include = a separate
> beacon for each SSID.  All solutions have = problems with
> certain existing client implementations, and = some of them are
> pushing the IEEE 802.11 standard in ways it = wasn't designed
> to go.  (Bernard, I know I'm preaching to = the choir with you;
> I've seen your Virtual AP presentation you gave = at Wi-Fi last week).
>
> If speed is essential, the Wi-Fi is the only = approprate
> venue, but if changes need to be made to the = standard, then
> IEEE needs to be present.
>
> Clint (JOATMON) Chaplin
>
> >>> "Mark Watson" = <mwatson@nortelnetworks.com> 6/12/03 07:07:14 >>>
> Hi Bernard,
>
> Comments below...
>
> I am looking for a solution which places = minimum new requirements on
> elements in the WLAN network - that is the AP = and any RADIUS
> proxies used to
> route authentication signalling to/from the = WISPs that do the actual
> authentication.
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:aboba@internaut.com] =
> > Sent: 12 June 2003 13:58
> > To: Watson, Mark [MOP:EP10:EXCH]
> > Cc: 'jari.arkko@piuha.net'; = eap@frascone.com
> > Subject: RE: [eap] Re: deciding which NAI = to send in an ID-RESPONSE
> >
> >
> > > WISPs may not have their own = SSIDs
> >
> > Is this due to a limitation of current APs = that could be
> removed?  For
> > example, if some large number of virtual = APs could be defined
> > (say, 255)
> > per AP, so that each WISP could have their = own SSIDs, would
> there be a
> > need for additional information as = well?  If so, how much
> > information are
> > we talking about?  Remember that = EAP-Request/Identity (or
> > Notification)
> > doesn't support fragmentation, so it's = limited by the MTU size.
> >
>
> An example: I was in Oslo airport the other = day. Oslo airport
> has a WLAN
> with a single SSID (well, I could only see = one). Oslo airport
> has agreements
> with several WISPs. I can authenticate through = any of those. SSID
> limitations or otherwise, I don't think you can = require the
> WLAN owner to
> provision a separate SSID for each WISP with = whom they have
> an agreement.
>
> Further, only one SSID can be broadcast - which = one ? Where
> do I get info
> about the other SSID's available - if that's = from the default WLAN
> (broadcast SSID) then access to any of the = others will be
> slow (have to
> associate with the broadcast one first to get = the info etc. etc.).
>
> The user may know too many domains throught = which they can
> authenticate to
> try a probe for each one (e.g. 3G case).
>
> > > Notifications have the advantage that = a mapping from RADIUS
> > Reply-Message to
> > > EAP Notification is already = defined.
> >
> > Please check RFC 2869bis -- use of RADIUS = Reply-Message is
> > deprecated for use with EAP.  Use of = Notification is preferred.
> > However, in this case it seems like = EAP-Request/Identity
> > might make more
> > sense, given the purpose of the = displayable message.
> >
> > > So, the information can come from = the
> > > RADIUS server/proxy in the case of an = error due to an
> > unrecognised Domain
> > > Name in the NAI. This places less = burden on the AP.
> >
> > I don't understand why Notification is a = burden on the AP
> -- it's just
> > handled like any other EAP message.
> >
>
> I was comparing with putting the info in the = Request/Identity.
>
> Putting the info in the Request/Identity, if I = understand
> correctly, is a
> burden on the AP, because the Request/Identity = is generated by the AP.
> Perhaps, though, a subsqeuent Request/Identity = after an
> unrecognised NAI
> domain error could be generated by the RADIUS = proxy detecting
> this ? But
> this proxy does not otherwise need to = understand EAP.
>
> > > I think the idea of a defined = 'name=3Dvalue' format with IANA
> > registrations
> > > for names is a good one. Does this = align with general
> > practice ? I see we
> > > have only one example so far.
> >
> > RFC 2284 states that Notification is for = delivery of a displayable
> > messages, and that is what it is used for, = as I understand
> > it.  Since a
> > Notification Response is sent = automatically, there is no way for the
> > sender to know that the peer understood = the message, or
> even that the
> > message was displayed (the peer responds = immediately, and
> doesn't wait
> > until it has done the displaying to = reply).
> >
> > On the other hand, some APs do use the = name=3Dvalue format
> today within
> > EAP-Request/Identity messages, for the = purpose of identifying the
> > AP. However, I don't think that EAP peer = implementations do
> > anything with it.
> >
> > The problem with going down the road of = defining new 'name=3Dvalue'
> > parameters is that this could create = interoperability
> > problems unless the
> > parameters were only treated as hints -- = if the wrong NAI is
> > sent, then
> > the displayable message part of the = EAP-Request/Identity is set to
> > indicate that.
>
> Sure, I would expect this information to be a = 'hint' about
> the NAI domains
> that *are* supported. You can ignore it if you = like & try a different
> domain, but then you'll get an error = response.
>
> > = _______________________________________________
> > eap mailing list
> > eap@frascone.com
> > http://mail.frascone.com/mailman/listinfo/eap =
> >
>
>
> = ______________________________________________________________
> __________
> This email has been scanned for computer = viruses.
> = _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>

------_=_NextPart_001_01C33104.E4496E96-- From cchaplin@sj.symbol.com Thu Jun 12 18:14:36 2003 From: cchaplin@sj.symbol.com (Clint Chaplin) Date: Thu, 12 Jun 2003 10:14:36 -0700 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: Well, I need to point out one assumption that is incorrect: several = manufacturers are already shipping APs (standalone and wireless switch) = that implement Virtual APs in one form or another. Clint (JOATMON) Chaplin >>> "Mark Watson" 6/12/03 10:09:35 >>> Clint, Virtual APs, implying a separate beacon for each SSID is certainly a solution to this problem, but I am looking for a solution which does not impact the AP. This problem will exist for WLANs that are being deployed = now - even if a virtual AP solution was fully agreed and standardised now, = then we couldn't wait for it to be implemented. ...Mark > -----Original Message----- > From: Clint Chaplin [mailto:cchaplin@sj.symbol.com]=20 > Sent: 12 June 2003 17:54 > To: aboba@internaut.com; Watson, Mark [MOP:EP10:EXCH] > Cc: hworstell@att.com; eap@frascone.com; apetrick@icefyre.com; > stuart.kerry@philips.com; jari.arkko@piuha.net=20 > Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE >=20 >=20 > Wi-Fi or IEEE has >got< to move forward on Virtual APs, or=20 > these sorts of issues are going to keep coming up. >=20 > Several companies have investigated this issue, and there are=20 > several ways to solve it, some of which include a separate=20 > beacon for each SSID. All solutions have problems with=20 > certain existing client implementations, and some of them are=20 > pushing the IEEE 802.11 standard in ways it wasn't designed=20 > to go. (Bernard, I know I'm preaching to the choir with you;=20 > I've seen your Virtual AP presentation you gave at Wi-Fi last week). >=20 > If speed is essential, the Wi-Fi is the only approprate=20 > venue, but if changes need to be made to the standard, then=20 > IEEE needs to be present. >=20 > Clint (JOATMON) Chaplin >=20 > >>> "Mark Watson" 6/12/03 07:07:14 >>> > Hi Bernard, >=20 > Comments below... >=20 > I am looking for a solution which places minimum new requirements on > elements in the WLAN network - that is the AP and any RADIUS=20 > proxies used to > route authentication signalling to/from the WISPs that do the actual > authentication. >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > > Sent: 12 June 2003 13:58 > > To: Watson, Mark [MOP:EP10:EXCH] > > Cc: 'jari.arkko@piuha.net'; eap@frascone.com=20 > > Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE > >=20 > >=20 > > > WISPs may not have their own SSIDs > >=20 > > Is this due to a limitation of current APs that could be=20 > removed? For > > example, if some large number of virtual APs could be defined=20 > > (say, 255) > > per AP, so that each WISP could have their own SSIDs, would=20 > there be a > > need for additional information as well? If so, how much=20 > > information are > > we talking about? Remember that EAP-Request/Identity (or=20 > > Notification) > > doesn't support fragmentation, so it's limited by the MTU size. > >=20 >=20 > An example: I was in Oslo airport the other day. Oslo airport=20 > has a WLAN > with a single SSID (well, I could only see one). Oslo airport=20 > has agreements > with several WISPs. I can authenticate through any of those. SSID > limitations or otherwise, I don't think you can require the=20 > WLAN owner to > provision a separate SSID for each WISP with whom they have=20 > an agreement. >=20 > Further, only one SSID can be broadcast - which one ? Where=20 > do I get info > about the other SSID's available - if that's from the default WLAN > (broadcast SSID) then access to any of the others will be=20 > slow (have to > associate with the broadcast one first to get the info etc. etc.). >=20 > The user may know too many domains throught which they can=20 > authenticate to > try a probe for each one (e.g. 3G case). >=20 > > > Notifications have the advantage that a mapping from RADIUS=20 > > Reply-Message to > > > EAP Notification is already defined. > >=20 > > Please check RFC 2869bis -- use of RADIUS Reply-Message is > > deprecated for use with EAP. Use of Notification is preferred. > > However, in this case it seems like EAP-Request/Identity=20 > > might make more > > sense, given the purpose of the displayable message. > >=20 > > > So, the information can come from the > > > RADIUS server/proxy in the case of an error due to an=20 > > unrecognised Domain > > > Name in the NAI. This places less burden on the AP. > >=20 > > I don't understand why Notification is a burden on the AP=20 > -- it's just > > handled like any other EAP message. > >=20 >=20 > I was comparing with putting the info in the Request/Identity. >=20 > Putting the info in the Request/Identity, if I understand=20 > correctly, is a > burden on the AP, because the Request/Identity is generated by the AP. > Perhaps, though, a subsqeuent Request/Identity after an=20 > unrecognised NAI > domain error could be generated by the RADIUS proxy detecting=20 > this ? But > this proxy does not otherwise need to understand EAP. >=20 > > > I think the idea of a defined 'name=3Dvalue' format with IANA=20 > > registrations > > > for names is a good one. Does this align with general=20 > > practice ? I see we > > > have only one example so far. > >=20 > > RFC 2284 states that Notification is for delivery of a displayable > > messages, and that is what it is used for, as I understand=20 > > it. Since a > > Notification Response is sent automatically, there is no way for the > > sender to know that the peer understood the message, or=20 > even that the > > message was displayed (the peer responds immediately, and=20 > doesn't wait > > until it has done the displaying to reply). > >=20 > > On the other hand, some APs do use the name=3Dvalue format=20 > today within > > EAP-Request/Identity messages, for the purpose of identifying the > > AP. However, I don't think that EAP peer implementations do=20 > > anything with it. > >=20 > > The problem with going down the road of defining new 'name=3Dvalue' > > parameters is that this could create interoperability=20 > > problems unless the > > parameters were only treated as hints -- if the wrong NAI is=20 > > sent, then > > the displayable message part of the EAP-Request/Identity is set to > > indicate that. >=20 > Sure, I would expect this information to be a 'hint' about=20 > the NAI domains > that *are* supported. You can ignore it if you like & try a different > domain, but then you'll get an error response. >=20 > > _______________________________________________ > > eap mailing list > > eap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/eap=20 > >=20 >=20 >=20 > ______________________________________________________________ > __________ > This email has been scanned for computer viruses. > _______________________________________________ > eap mailing list > eap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/eap=20 >=20 ________________________________________________________________________ This email has been scanned for computer viruses. From farooq.bari@attws.com Thu Jun 12 18:23:21 2003 From: farooq.bari@attws.com (Bari, Farooq) Date: Thu, 12 Jun 2003 10:23:21 -0700 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: <84359F26B1241A4E90FBBE7F0996BFE9030D38@WA-MSG12-BTH.wireless.attws.com> Even if the APs can have multiple SSIDs, do the standards allow them to be broadcast i.e. all of them. Also if APs can broadcast all of them, would not this result in extra traffic over the air specially if there are a large no. of roaming agreements (i.e. large no. of SSIDs to broadcast). Alternatively if each of the user device decides to probe for all WISP SSIDs with which user's operator has roaming agreements in an effort to pick the best possible network say in terms of tariffs, it too may be a long process and create extra traffic. A better solution might be that somehow the WLAN (AP or some other entity in the RADIUS path), can pass the supported WISPS information as part of initial user authentication process.=20 Farooq -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: Thursday, June 12, 2003 5:58 AM To: Mark Watson Cc: 'jari.arkko@piuha.net'; eap@frascone.com Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE > WISPs may not have their own SSIDs Is this due to a limitation of current APs that could be removed? For example, if some large number of virtual APs could be defined (say, 255) per AP, so that each WISP could have their own SSIDs, would there be a need for additional information as well? If so, how much information are we talking about? Remember that EAP-Request/Identity (or Notification) doesn't support fragmentation, so it's limited by the MTU size. > Notifications have the advantage that a mapping from RADIUS=20 > Reply-Message to EAP Notification is already defined. Please check RFC 2869bis -- use of RADIUS Reply-Message is deprecated for use with EAP. Use of Notification is preferred. However, in this case it seems like EAP-Request/Identity might make more sense, given the purpose of the displayable message. > So, the information can come from the > RADIUS server/proxy in the case of an error due to an unrecognised=20 > Domain Name in the NAI. This places less burden on the AP. I don't understand why Notification is a burden on the AP -- it's just handled like any other EAP message. > I think the idea of a defined 'name=3Dvalue' format with IANA=20 > registrations for names is a good one. Does this align with general=20 > practice ? I see we have only one example so far. RFC 2284 states that Notification is for delivery of a displayable messages, and that is what it is used for, as I understand it. Since a Notification Response is sent automatically, there is no way for the sender to know that the peer understood the message, or even that the message was displayed (the peer responds immediately, and doesn't wait until it has done the displaying to reply). On the other hand, some APs do use the name=3Dvalue format today within EAP-Request/Identity messages, for the purpose of identifying the AP. However, I don't think that EAP peer implementations do anything with it. The problem with going down the road of defining new 'name=3Dvalue' parameters is that this could create interoperability problems unless the parameters were only treated as hints -- if the wrong NAI is sent, then the displayable message part of the EAP-Request/Identity is set to indicate that. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Thu Jun 12 18:03:56 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Jun 2003 10:03:56 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: References: Message-ID: > I am looking for a solution which places minimum new requirements on > elements in the WLAN network - that is the AP and any RADIUS proxies used to > route authentication signalling to/from the WISPs that do the actual > authentication. Are we talking about minimum requirements beyond what will be required for WFA certification of a public access AP? > Further, only one SSID can be broadcast - which one ? This is purely a limitation of the AP implementation. Assuming that support for multiple SSIDs were available, would you still need support within EAP? > Where do I get info > about the other SSID's available Two possibilities: a. Send a Probe Request for the broadcast SSID. b. Send a Probe Request for a specific SSID. > (broadcast SSID) then access to any of the others will be slow (have to > associate with the broadcast one first to get the info etc. etc.). In IEEE 802.11, scanning (Beacons, Probe Request/Response) occurs prior to authentication or association. Typical response times are on the order of 1-2 ms. It's the EAP exchange that may require Association first (if pre-authentication isn't used). > The user may know too many domains throught which they can authenticate to > try a probe for each one (e.g. 3G case). How many domains are we talking about? A dozen? A hundred? A thousand? > Putting the info in the Request/Identity, if I understand correctly, is a > burden on the AP, because the Request/Identity is generated by the AP. Since the contents of the Request/Identity message doesn't change, the AP can just store the contents of the Type-Data field, so we're just talking about a little memory, no computational load. > Perhaps, though, a subsqeuent Request/Identity after an unrecognised NAI > domain error could be generated by the RADIUS proxy detecting this ? But > this proxy does not otherwise need to understand EAP. Yes, it could be generated by the proxy. > Sure, I would expect this information to be a 'hint' about the NAI domains > that *are* supported. You can ignore it if you like & try a different > domain, but then you'll get an error response. OK. Out of curiosity, how many domains (e.g. values of network-id) are we talking about? From aboba@internaut.com Thu Jun 12 18:06:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Jun 2003 10:06:27 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: References: Message-ID: Thanks, Clint. My question is this: Assuming this happens (and I agree there is lots of need for it), do we need something else in EAP too? If so, what? It would be nice to avoid a zillion bells and whistles if possible. On Thu, 12 Jun 2003, Clint Chaplin wrote: > Wi-Fi or IEEE has >got< to move forward on Virtual APs, or these sorts of issues are going to keep coming up. > > Several companies have investigated this issue, and there are several ways to solve it, some of which include a separate beacon for each SSID. All solutions have problems with certain existing client implementations, and some of them are pushing the IEEE 802.11 standard in ways it wasn't designed to go. (Bernard, I know I'm preaching to the choir with you; I've seen your Virtual AP presentation you gave at Wi-Fi last week). > > If speed is essential, the Wi-Fi is the only approprate venue, but if changes need to be made to the standard, then IEEE needs to be present. > > Clint (JOATMON) Chaplin From aboba@internaut.com Thu Jun 12 18:15:55 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Jun 2003 10:15:55 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: <84359F26B1241A4E90FBBE7F0996BFE9030D38@WA-MSG12-BTH.wireless.attws.com> References: <84359F26B1241A4E90FBBE7F0996BFE9030D38@WA-MSG12-BTH.wireless.attws.com> Message-ID: > Even if the APs can have multiple SSIDs, do the standards allow them to > be broadcast i.e. all of them. Also if APs can broadcast all of them, > would not this result in extra traffic over the air specially if there > are a large no. of roaming agreements (i.e. large no. of SSIDs to > broadcast). It results in extra traffic, but it's modest. A Beacon is around 100 octets (800 bits). So even if you had 100 Virtual APs, with a Beacon interval of 1 second, we are only talking about 80 Kbps of traffic. > Alternatively if each of the user device decides to probe for all WISP > SSIDs with which user's operator has roaming agreements in an effort to > pick the best possible network say in terms of tariffs, it too may be a > long process and create extra traffic. Sure. That's why only being able to broadcast a single SSID isn't an optimal solution. > A better solution might be that somehow the WLAN (AP or some other > entity in the RADIUS path), can pass the supported WISPS information as > part of initial user authentication process. Since the EAP-Request/Identity does not support fragmentation, you'd have to limit the size of the Type-Data field based on the MTU. Not sure how big an issue this is, though. From aboba@internaut.com Thu Jun 12 18:24:05 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Jun 2003 10:24:05 -0700 (PDT) Subject: [eap] Issue 142: Contents of the EAP-Request/Identity In-Reply-To: <3EE8823E.1030103@piuha.net> References: <499DC368E25AD411B3F100902740AD6512992B3D@xrose03.rose.hp.com> <20030610161935.GD6685@steelhead> <3EE8823E.1030103@piuha.net> Message-ID: > 1. We need to document that there can be a nul character > in the data part of EAP Identity Request, and that > the message should only be displayed until the nul. I agree. > Note: Some existing implementations are known to > pass parameters after the nul character. Support > for such parameters is implementation specific, > but where used their format SHOULD be a comma > separated list of parameter=value assignments. If we say even this much, we still have to define a grammar for the parameters and the value assignments. For example, I presume that a value can't include a "," or "=" value without some sort of escape mechanism. And the question will arise as to what characters are legal within the parameters. And once we have an ABNF, then we'll need to make sure it compiles and is actually correct. I also suspect that even going this far will require some sort of IANA registry to be set up, even if no parameters are defined in RFC 2284bis. > 3. Lets not claim anything about the AUP in the text. > I agree that its probably best done at the link layer, > but this may not always be possible. If it isn't > possible then the message in the identity request > may be used for that purpose. However, I wouldn't > write that down in the spec as I don't think that > would the recommended practise. Sure. It's just displayable text. It could be used for an AUP, or alternatively, a witty Message of the Day :) From jari.arkko@piuha.net Thu Jun 12 20:28:48 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 12 Jun 2003 22:28:48 +0300 Subject: [eap] Issue 142: Contents of the EAP-Request/Identity In-Reply-To: References: <499DC368E25AD411B3F100902740AD6512992B3D@xrose03.rose.hp.com> <20030610161935.GD6685@steelhead> <3EE8823E.1030103@piuha.net> Message-ID: <3EE8D470.7040509@piuha.net> Bernard Aboba wrote: >> Note: Some existing implementations are known to >> pass parameters after the nul character. Support >> for such parameters is implementation specific, >> but where used their format SHOULD be a comma >> separated list of parameter=value assignments. > > > If we say even this much, we still have to define a grammar for the > parameters and the value assignments. For example, I presume that > a value can't include a "," or "=" value without some sort of escape > mechanism. And the question will arise as to what characters are legal > within the parameters. And once we have an ABNF, then we'll need to make > sure it compiles and is actually correct. And probably also what information should be put in... > I also suspect that even going this far will require some sort of IANA > registry to be set up, even if no parameters are defined in RFC 2284bis. Point taken. It looks like we have two alternatives. 1) Just say that there's some implementation dependent data after the nul. 2) Define the syntax, semantics, and IANA considerations for the parameters. So, if you think we need interoperability for the parameters, we need to go for alternative #2. Perhaps the text that you posted earlier is good enough for that, though I'd move the syntax text from appendix to the main document. --Jari From aboba@internaut.com Thu Jun 12 20:19:43 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Jun 2003 12:19:43 -0700 (PDT) Subject: [eap] Issue 142: Contents of the EAP-Request/Identity In-Reply-To: <3EE8D470.7040509@piuha.net> References: <499DC368E25AD411B3F100902740AD6512992B3D@xrose03.rose.hp.com> <20030610161935.GD6685@steelhead> <3EE8823E.1030103@piuha.net> <3EE8D470.7040509@piuha.net> Message-ID: > Point taken. > > It looks like we have two alternatives. > > 1) Just say that there's some implementation dependent > data after the nul. > 2) Define the syntax, semantics, and IANA considerations > for the parameters. > > So, if you think we need interoperability for the parameters, > we need to go for alternative #2. Perhaps the text that you > posted earlier is good enough for that, though I'd move the > syntax text from appendix to the main document. How about this: a) In RFC 2284bis, we only do #1. b) In a separate document, go for alternative #2 (assuming that there is WG consensus), including all the work of specifying (and checking) the ABNF, specifying parameters, writing the IANA considerations section, etc. I'm just somewhat wary that task b) may be considerably larger than we might imagine at the moment, and I don't want to delay RFC 2284bis until it is done. From jari.arkko@piuha.net Thu Jun 12 21:03:32 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 12 Jun 2003 23:03:32 +0300 Subject: [eap] Issue 142: Contents of the EAP-Request/Identity In-Reply-To: References: <499DC368E25AD411B3F100902740AD6512992B3D@xrose03.rose.hp.com> <20030610161935.GD6685@steelhead> <3EE8823E.1030103@piuha.net> <3EE8D470.7040509@piuha.net> Message-ID: <3EE8DC94.2040408@piuha.net> Bernard Aboba wrote: > a) In RFC 2284bis, we only do #1. > b) In a separate document, go for alternative #2 (assuming that there is > WG consensus), including all the work of specifying (and checking) the > ABNF, specifying parameters, writing the IANA considerations section, etc. > > I'm just somewhat wary that task b) may be considerably larger than we > might imagine at the moment, and I don't want to delay RFC 2284bis until > it is done. Yes, that's what I also worried about. I'm OK with your suggestion above. --Jari From aboba@internaut.com Thu Jun 12 21:27:23 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 12 Jun 2003 13:27:23 -0700 (PDT) Subject: [eap] Proposed Resolution to Issue 142 Message-ID: Issue 142 is enclosed below. For the full text of all issues, see: http://www.drizzle.com/~aboba/EAP/eapissues.html I am concerned that the material proposed for Appendix A.2 is currently not specified well enough, and would require considerable additional work in order to complete, delaying RFC 2284bis. What we need is: a) An ABNF describing the grammar for the parameters and values; b) IANA considerations for allocation of parameters and values. This material is likely to require enough work (and be large enough) to warrant a separate document on the subject. Therefore my recommendation is that we only take the changes to Section 5.1 at this point, and examine whether there is sufficient WG consensus to start work on a separate document to handle a) and b). Here are the proposed fixes: In Section 5.1, change: "This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." To: "This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet." -------------------------------------------------------------- Issue 142: Contents of EAP-Request/Identity Submitter name: Tim Moore Submitter email address: timmoore@microsoft.com Date first submitted: June 9, 2003 Reference: Document: EAP-03 Comment type: T Priority: S Section: 5.1, Appendix A Rationale/Explanation of issue: In Section 5.1, change: "This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." To: "This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed, with portion after the null used as a hint to the peer as to the identity to be provided in the Response, as described in Appendix A.2. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet." Add to Appendix A: "A.2 Contents of the EAP Request/Identity Type-Data field In addition to providing a displayable message to the peer, the authenticator may wish to provide a hint as to the appropriate identity to place in the Type-Data field of the EAP-Response/Identity. To allow for both a displayable message as well as potential hints, the EAP-Request/Identity message is formatted as follows: \0networkid=,nasid=,portid= Where: network-name: Name(s) of the network(s) to which the authenticator connects. For 802.11, this will typically correspond to the SSID. nas-name: Name or address of the NAS. port-id: port that the EAP session is on. The EAP peer should display display-string before the null termination (\0)" [Jari Arkko]: Several issues relate to this problem. One issue is that there's existing deployment where the nul character is used to separate a message and a some other information in EAP Identity Request. Another issue is how to represent AUPs. A third issue is how to represent parameters to the peer, and if such parameters are needed in the first place. Given that we have a deployed protocol, I'd suggest the following approach: 1. We need to document that there can be a nul character in the data part of EAP Identity Request, and that the message should only be displayed until the nul. 2. Perhaps we should not say too much about the use of the field after the nul. Certainly no normative text. I don't think appendix A is the right place for this text. I would try to cut the text down and just place it as a note in the place where the EAP Identity REquest is discussed. Like this, for example: Note: Some existing implementations are known to pass parameters after the nul character. Support for such parameters is implementation specific, but where used their format SHOULD be a comma separated list of parameter=value assignments. 3. Lets not claim anything about the AUP in the text. I agree that its probably best done at the link layer, but this may not always be possible. If it isn't possible then the message in the identity request may be used for that purpose. However, I wouldn't write that down in the spec as I don't think that would the recommended practice. From mwatson@nortelnetworks.com Fri Jun 13 09:34:52 2003 From: mwatson@nortelnetworks.com (Mark Watson) Date: Fri, 13 Jun 2003 09:34:52 +0100 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33186.A8B89A78 Content-Type: text/plain; charset="iso-8859-1" > > > I am looking for a solution which places minimum new requirements on > > elements in the WLAN network - that is the AP and any > RADIUS proxies used to > > route authentication signalling to/from the WISPs that do the actual > > authentication. > > Are we talking about minimum requirements beyond what will be > required for WFA certification of a public access AP? > I am not familiar with the WFA certification requirements, but in terms of the 3G interworking activity, the objective is to minimise the requirements on the AP to those that are absolutely necessary (e.g. for security we require WPA). Any additional requirements will reduce the set of WLAN deployments that could interwork with 3G networks. > > Further, only one SSID can be broadcast - which one ? > > This is purely a limitation of the AP implementation. Only in the sense that you could implement multiple logically distinct APs in one physical AP. A single logical AP as described in 802.11 has only one broadcast SSID, as I understand it. > Assuming that > support for multiple SSIDs were available, would you still need > support within EAP? > Well, if all the available SSIDs are broadcast, this could work. But this is not widely supported in WLANs today. Also, I am not sure that it's a reasonable restriction to place on the WLAN owner - I gave the example of the existing WLAN at Oslo airport - can we *require* that Oslo airport modifies their WLAN to provide a separate SSID for each WISP they work with ? There will still be users who do not have an automatic authentication capability (i.e. who rely on the 'landing page' & web-based username/password) - how will they know which SSID to use ?? > > Where do I get info > > about the other SSID's available > > Two possibilities: > > a. Send a Probe Request for the broadcast SSID. > b. Send a Probe Request for a specific SSID. > There are too many to use probes. To answer you question below, the user may be able to authenticate through hundreds of domains. It would be too slow to probe these all to see which is available. > > (broadcast SSID) then access to any of the others will be > slow (have to > > associate with the broadcast one first to get the info etc. etc.). > > In IEEE 802.11, scanning (Beacons, Probe Request/Response) > occurs prior to > authentication or association. Typical response times are on > the order of > 1-2 ms. It's the EAP exchange that may require Association first (if > pre-authentication isn't used). > No, given that trial-and-error probes are too slow, then if you use multiple SSIDs, with only one broadcast, then you will need to associate to the broadcast one to get the information about what SSIDs are available (various ways to do this once you've associated). Then you'd have to re-associate with your chosen SSID. So, I think that separate SSIDs for each network is unreasonable unless they are all broadcast, requiring Virtual AP support, which is not ubiquitous in todays WLANs. > > The user may know too many domains throught which they can > authenticate to > > try a probe for each one (e.g. 3G case). > > How many domains are we talking about? A dozen? A hundred? A thousand? > > > Putting the info in the Request/Identity, if I understand > correctly, is a > > burden on the AP, because the Request/Identity is generated > by the AP. > > Since the contents of the Request/Identity message doesn't > change, the AP > can just store the contents of the Type-Data field, so we're > just talking > about a little memory, no computational load. > Yep, but it's a new function which would have to be implemented on APs. A WLAN owner would need to upgrade all their APs or buy new ones before they could support this mechanism. > > Perhaps, though, a subsqeuent Request/Identity after an > unrecognised NAI > > domain error could be generated by the RADIUS proxy > detecting this ? But > > this proxy does not otherwise need to understand EAP. > > Yes, it could be generated by the proxy. This would be easier for the WLAN network owner - probably only a small number of RADIUS proxies. > > > Sure, I would expect this information to be a 'hint' about > the NAI domains > > that *are* supported. You can ignore it if you like & try a > different > > domain, but then you'll get an error response. > > OK. Out of curiosity, how many domains (e.g. values of > network-id) are we > talking about? Hundreds, could be more than a thousand, I am not sure - one for each 3G operator in the world. As a 3G subscriber I can authenticate through any 3G operator which has a roaming agreement with my home operator. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > ------_=_NextPart_001_01C33186.A8B89A78 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Re: deciding which NAI to send in an = ID-RESPONSE

>
> > I am looking for a solution which places = minimum new requirements on
> > elements in the WLAN network - that is the = AP and any
> RADIUS proxies used to
> > route authentication signalling to/from = the WISPs that do the actual
> > authentication.
>
> Are we talking about minimum requirements = beyond what will be
> required for WFA certification of a public = access AP?
>

I am not familiar with the WFA certification = requirements, but in terms of the 3G interworking activity, the = objective is to minimise the requirements on the AP to those that are = absolutely necessary (e.g. for security we require WPA). Any additional = requirements will reduce the set of WLAN deployments that could = interwork with 3G networks.

> > Further, only one SSID can be broadcast - = which one ?
>
> This is purely a limitation of the AP = implementation.

Only in the sense that you could implement multiple = logically distinct APs in one physical AP. A single logical AP as = described in 802.11 has only one broadcast SSID, as I understand = it.

> Assuming that
> support for multiple SSIDs were available, = would you still need
> support within EAP?
>

Well, if all the available SSIDs are broadcast, this = could work. But this is not widely supported in WLANs today. Also, I am = not sure that it's a reasonable restriction to place on the WLAN owner = - I gave the example of the existing WLAN at Oslo airport - can we = *require* that Oslo airport modifies their WLAN to provide a separate = SSID for each WISP they work with ? There will still be users who do = not have an automatic authentication capability (i.e. who rely on the = 'landing page' & web-based username/password) - how will they know = which SSID to use ??

> > Where do I get info
> > about the other SSID's available
>
> Two possibilities:
>
> a. Send a Probe Request for the broadcast = SSID.
> b. Send a Probe Request for a specific = SSID.
>

There are too many to use probes. To answer you = question below, the user may be able to authenticate through hundreds = of domains. It would be too slow to probe these all to see which is = available.

> > (broadcast SSID) then access to any of the = others will be
> slow (have to
> > associate with the broadcast one first to = get the info etc. etc.).
>
> In IEEE 802.11, scanning (Beacons, Probe = Request/Response)
> occurs prior to
> authentication or association. Typical response = times are on
> the order of
> 1-2 ms. It's the EAP exchange that may require = Association first (if
> pre-authentication isn't used).
>

No, given that trial-and-error probes are too slow, = then if you use multiple SSIDs, with only one broadcast, then you will = need to associate to the broadcast one to get the information about = what SSIDs are available (various ways to do this once you've = associated). Then you'd have to re-associate with your chosen = SSID.

So, I think that separate SSIDs for each network is = unreasonable unless they are all broadcast, requiring Virtual AP = support, which is not ubiquitous in todays WLANs.

> > The user may know too many domains throught = which they can
> authenticate to
> > try a probe for each one (e.g. 3G = case).
>
> How many domains are we talking about? A dozen? = A hundred? A thousand?
>
> > Putting the info in the Request/Identity, = if I understand
> correctly, is a
> > burden on the AP, because the = Request/Identity is generated
> by the AP.
>
> Since the contents of the Request/Identity = message doesn't
> change, the AP
> can just store the contents of the Type-Data = field, so we're
> just talking
> about a little memory, no computational = load.
>

Yep, but it's a new function which would have to be = implemented on APs. A WLAN owner would need to upgrade all their APs or = buy new ones before they could support this mechanism.

> > Perhaps, though, a subsqeuent = Request/Identity after an
> unrecognised NAI
> > domain error could be generated by the = RADIUS proxy
> detecting this ? But
> > this proxy does not otherwise need to = understand EAP.
>
> Yes, it could be generated by the proxy.

This would be easier for the WLAN network owner - = probably only a small number of RADIUS proxies.

>
> > Sure, I would expect this information to = be a 'hint' about
> the NAI domains
> > that *are* supported. You can ignore it if = you like & try a
> different
> > domain, but then you'll get an error = response.
>
> OK. Out of curiosity, how many domains (e.g. = values of
> network-id) are we
> talking about?

Hundreds, could be more than a thousand, I am not = sure - one for each 3G operator in the world.

As a 3G subscriber I can authenticate through any 3G = operator which has a roaming agreement with my home operator.

> = _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>

------_=_NextPart_001_01C33186.A8B89A78-- From henrik@levkowetz.com Fri Jun 13 12:19:20 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Fri, 13 Jun 2003 13:19:20 +0200 Subject: [eap] New intermediary EAPbis draft available Message-ID: <20030613131920.0cecc6ee.henrik@levkowetz.com> A new intermediate version of the EAPbis draft is available for inspection here: http://www.levkowetz.com/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.e.txt Html and diffs are also available: http://www.levkowetz.com/ietf/drafts/eap/ The new EAP-04.e version resolves the following issues which has been raised since version -03: 121 131 134 138 139 141 142. For more detail on open and resolved issues, see the EAP Issues List at: http://www.drizzle.com/~aboba/EAP/eapissues.html Henrik From aboba@internaut.com Fri Jun 13 14:52:27 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 13 Jun 2003 06:52:27 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: References: Message-ID: > There are too many to use probes. To answer you question below, the user may > be able to authenticate through hundreds of domains. It would be too slow to > probe these all to see which is available. Are hundreds of domains likely to be active in ths same location? Would they all need to be encoded within the EAP-Request/Identity? From mwatson@nortelnetworks.com Fri Jun 13 15:38:40 2003 From: mwatson@nortelnetworks.com (Mark Watson) Date: Fri, 13 Jun 2003 15:38:40 +0100 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C331B9.28F9FDEE Content-Type: text/plain; charset="iso-8859-1" No, I would expect only a handful (<10, probably <5) to be available in any one location. These are the domains with which the WLAN operator has a direct agreement. ...Mark > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: 13 June 2003 14:52 > To: Watson, Mark [MOP:EP10:EXCH] > Cc: eap@frascone.com > Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE > > > > There are too many to use probes. To answer you question > below, the user may > > be able to authenticate through hundreds of domains. It > would be too slow to > > probe these all to see which is available. > > Are hundreds of domains likely to be active in ths same > location? Would > they all need to be encoded within the EAP-Request/Identity? > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > ------_=_NextPart_001_01C331B9.28F9FDEE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Re: deciding which NAI to send in an = ID-RESPONSE

No, I would expect only a handful (<10, probably = <5) to be available in any one location. These are the domains with = which the WLAN operator has a direct agreement.

...Mark

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: 13 June 2003 14:52
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: eap@frascone.com
> Subject: RE: [eap] Re: deciding which NAI to = send in an ID-RESPONSE
>
>
> > There are too many to use probes. To = answer you question
> below, the user may
> > be able to authenticate through hundreds = of domains. It
> would be too slow to
> > probe these all to see which is = available.
>
> Are hundreds of domains likely to be active in = ths same
> location?  Would
> they all need to be encoded within the = EAP-Request/Identity?
> = _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>

------_=_NextPart_001_01C331B9.28F9FDEE-- From aboba@internaut.com Fri Jun 13 16:06:35 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 13 Jun 2003 08:06:35 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: References: Message-ID: > Only in the sense that you could implement multiple logically distinct APs > in one physical AP. A single logical AP as described in 802.11 has only one > broadcast SSID, as I understand it. Actually, IEEE 802.11-1999 doesn't define a "logical AP" nor does it restrict the number of SSIDs it may use. That's part of the problem -- the specification may be interpretted as supporting "Virtual APs" in multiple ways. Thus the interest in defining a single interoperable way of handling this. > Well, if all the available SSIDs are broadcast, this could work. > > I am not sure that it's a > reasonable restriction to place on the WLAN owner - I gave the example of > the existing WLAN at Oslo airport - can we *require* that Oslo airport > modifies their WLAN to provide a separate SSID for each WISP? Probably not. However, there are a number of potential solutions to the problem, and the question is "how do we evaluate them?" I'm not sure that the principle of "no changes to the AP" holds universally -- there are other situations where "no changes to the peer" are desirable. For example, in enterprise deployments, updating 50K+ clients is a *very* expensive operation, whereas an AP firmware upgrade is much less costly. > ? There will still be users who do not have an automatic authentication > capability (i.e. who rely on the 'landing page' & web-based > username/password) - how will they know which SSID to use ?? Today that problem already exists because multiple APs can be advertising different SSIDs. Some Airports are already quite crowded, with networks from the airlines, WISPs, and even sometimes the airport itself (e.g. baggage handling system). Typically this is handled either via user intervention or by preferences on the peer. > So, I think that separate SSIDs for each network is unreasonable unless they > are all broadcast I agree. > Yep, but it's a new function which would have to be implemented on APs. A > WLAN owner would need to upgrade all their APs or buy new ones before they > could support this mechanism. As we discussed, only the first EAP-Request/Identity need be sent by the AP. Subsequent ones can be sent by the RADIUS server/proxy. Typically a software upgrade is not insurmountable, but a "forklift upgrade" is another story. From mwatson@nortelnetworks.com Fri Jun 13 17:19:49 2003 From: mwatson@nortelnetworks.com (Mark Watson) Date: Fri, 13 Jun 2003 17:19:49 +0100 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C331C7.9CBADEF2 Content-Type: text/plain; charset="iso-8859-1" > Actually, IEEE 802.11-1999 doesn't define a "logical AP" nor does it > restrict the number of SSIDs it may use. That's part of the > problem -- > the specification may be interpretted as supporting "Virtual APs" in > multiple ways. Thus the interest in defining a single > interoperable way > of handling this. > I'm not an expert in 802.11, but I was led to believe that an AP as defined in 802.11-1999 can only broadcast a single SSID at one time (a quick reading of the MLME-START.request and MLME-RESET.request management primitives seems to suggest this, but as I say, I'm no expert here). I thought that it could support many SSIDs, which can be probed, but not many simultaneous beacons. Of course, you can always put several APs in one physical box. But we seem to be agreeing that there is not a fully-defined way to do this right now, even though there may be a number of existing implementations that appear to work. > > Well, if all the available SSIDs are broadcast, this could work. > > > > I am not sure that it's a > > reasonable restriction to place on the WLAN owner - I gave > the example of > > the existing WLAN at Oslo airport - can we *require* that > Oslo airport > > modifies their WLAN to provide a separate SSID for each WISP? > > Probably not. However, there are a number of potential > solutions to the > problem, and the question is "how do we evaluate them?" I'm > not sure that > the principle of "no changes to the AP" holds universally -- there > are other situations where "no changes to the peer" are > desirable. For > example, in enterprise deployments, updating 50K+ clients is a *very* > expensive operation, whereas an AP firmware upgrade is much > less costly. > Perhaps different solutions will be appropriate in diffent situations. But I don't think the problem we are discussing admits a solution which does not impact the client. The problem is for the client to discover the available domains with which to authenticate - how can this be done without impacting the client ? > > ? There will still be users who do not have an automatic > authentication > > capability (i.e. who rely on the 'landing page' & web-based > > username/password) - how will they know which SSID to use ?? > > Today that problem already exists because multiple APs can be > advertising > different SSIDs. Some Airports are already quite crowded, > with networks > from the airlines, WISPs, and even sometimes the airport itself (e.g. > baggage handling system). Typically this is handled either via user > intervention or by preferences on the peer. > Ok, so you're saying there might be a 'default' SSID that needs to be advertised to 'legacy' users (who use web-based authentication) and through which all WISPs are available. Then separate SSIDs for each WISP for 802.1X authentication ?? > > So, I think that separate SSIDs for each network is > unreasonable unless they > > are all broadcast > > I agree. > > > Yep, but it's a new function which would have to be > implemented on APs. A > > WLAN owner would need to upgrade all their APs or buy new > ones before they > > could support this mechanism. > > As we discussed, only the first EAP-Request/Identity need be > sent by the > AP. Subsequent ones can be sent by the RADIUS server/proxy. > I meant support of multiple broadcast SSIDs on a single AP was a new function - at least we seem to agree that it is not currently supported in a well-defined known-to-be-interoperable way. > Typically a software upgrade is not insurmountable, but a "forklift > upgrade" is another story. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > ------_=_NextPart_001_01C331C7.9CBADEF2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Re: deciding which NAI to send in an = ID-RESPONSE

> Actually, IEEE 802.11-1999 doesn't define a = "logical AP" nor does it
> restrict the number of SSIDs it may use.  = That's part of the
> problem --
> the specification may be interpretted as = supporting "Virtual APs" in
> multiple ways.  Thus the interest in = defining a single
> interoperable way
> of handling this.
>

I'm not an expert in 802.11, but I was led to believe = that an AP as defined in 802.11-1999 can only broadcast a single SSID = at one time (a quick reading of the MLME-START.request and = MLME-RESET.request management primitives seems to suggest this, but as = I say, I'm no expert here).

I thought that it could support many SSIDs, which can = be probed, but not many simultaneous beacons.

Of course, you can always put several APs in one = physical box.

But we seem to be agreeing that there is not a = fully-defined way to do this right now, even though there may be a = number of existing implementations that appear to work.

> > Well, if all the available SSIDs are = broadcast, this could work.
> >
> > I am not sure that it's a
> > reasonable restriction to place on the = WLAN owner - I gave
> the example of
> > the existing WLAN at Oslo airport - can we = *require* that
> Oslo airport
> > modifies their WLAN to provide a separate = SSID for each WISP?
>
> Probably not.  However, there are a number = of potential
> solutions to the
> problem, and the question is "how do we = evaluate them?" I'm
> not sure that
> the principle of "no changes to the = AP" holds universally -- there
> are other situations where "no changes to = the peer" are
> desirable.  For
> example, in enterprise deployments, updating = 50K+ clients is a *very*
> expensive operation, whereas an AP firmware = upgrade is much
> less costly.
>

Perhaps different solutions will be appropriate in = diffent situations.

But I don't think the problem we are discussing = admits a solution which does not impact the client. The problem is for = the client to discover the available domains with which to authenticate = - how can this be done without impacting the client ?

> > ? There will still be users who do not have = an automatic
> authentication
> > capability (i.e. who rely on the 'landing = page' & web-based
> > username/password) - how will they know = which SSID to use ??
>
> Today that problem already exists because = multiple APs can be
> advertising
> different SSIDs.  Some Airports are = already quite crowded,
> with networks
> from the airlines, WISPs, and even sometimes = the airport itself (e.g.
> baggage handling system).  Typically this = is handled either via user
> intervention or by preferences on the = peer.
>

Ok, so you're saying there might be a 'default' SSID = that needs to be advertised to 'legacy' users (who use web-based = authentication) and through which all WISPs are available. Then = separate SSIDs for each WISP for 802.1X authentication ??

> > So, I think that separate SSIDs for each = network is
> unreasonable unless they
> > are all broadcast
>
> I agree.
>
> > Yep, but it's a new function which would = have to be
> implemented on APs. A
> > WLAN owner would need to upgrade all their = APs or buy new
> ones before they
> > could support this mechanism.
>
> As we discussed, only the first = EAP-Request/Identity need be
> sent by the
> AP. Subsequent ones can be sent by the RADIUS = server/proxy.
>

I meant support of multiple broadcast SSIDs on a = single AP was a new function - at least we seem to agree that it is not = currently supported in a well-defined known-to-be-interoperable = way.

> Typically a software upgrade is not = insurmountable, but a "forklift
> upgrade" is another story.
>
> = _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>

------_=_NextPart_001_01C331C7.9CBADEF2-- From aboba@internaut.com Fri Jun 13 18:02:29 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 13 Jun 2003 10:02:29 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: References: Message-ID: > But we seem to be agreeing that there is not a fully-defined way to do this > right now, even though there may be a number of existing implementations > that appear to work. Actually, there are several ways it can be done, and a number of existing AP approaches, several of which do *not* work reliably with existing stations. The approach that does work with all existing stations is not implementable by all existing APs. For example, putting multiple SSID Information Elements in a Beacon or Probe Response is not prohibited by IEEE 802.11-1999 -- but most stations will not interpret this correctly. Similarly, if different capability sets and SSIDs are sent in a Beacon originating from the same BSSID, some drivers will interpret this as a configuration change on the AP -- and overwrite the existing configuration. As a result, instead of seeing multiple virtual APs, the station will only see a single virtual AP with the capabilities rapidly "flipping" between the different configurations. > Perhaps different solutions will be appropriate in diffent situations. > > But I don't think the problem we are discussing admits a solution which does > not impact the client. The problem is for the client to discover the > available domains with which to authenticate - how can this be done without > impacting the client ? Existing stations have to be able to deal with multiple physical APs, so they will also deal with multiple virtual APs that advertise with different BSSIDs -- since the two cases cannot be distinguished by the station. > Ok, so you're saying there might be a 'default' SSID that needs to be > advertised to 'legacy' users (who use web-based authentication) and through > which all WISPs are available. Then separate SSIDs for each WISP for 802.1X > authentication ?? A Virtual AP is like a physical AP in that you can choose the SSID and capabilities independently from other APs. It's possible to have one Virtual AP advertising "SSIDA" with one set of capabilities, and another advertising "SSIDB" with a different set. It's also possible to have several Virtual APs advertising the same SSID, but with different capabilities. For example, many WISPs now support Web portal, but want to also support WPA. With Virtual APs, the WISP could create one Virtual AP advertising a Web Portal (open auth) and another Virtual AP advertising WPA -- and they both can have the same SSID. Clients can then choose based on their preferences and capabilities. > I meant support of multiple broadcast SSIDs on a single AP was a new > function - at least we seem to agree that it is not currently supported in a > well-defined known-to-be-interoperable way. Actually, virtual APs using separate BSSIDs *do* interoperate with existing clients -- and the way to do this is well defined, because it's indistinguishable from how different physical APs work today. However, some chipsets cannot support this, just as some drivers cannot not support alternative approaches. So I do agree with your conclusion that even if virtual AP capability were standardized, that it would be a while before it could be used, and so some interim measure is probably required. The question is whether the problem can be addressed by defining parameters to be advertised in the EAP-Request/Identity. This seems like the most reasonable EAP-based approach to me, since while one can expect an EAP-Request/Identity to influence the EAP-Response/Identity, since it's the same method, expecting a Notification-Request to influence an EAP-Response/Identity in an automated way would appear to violate the EAP multiplexing model. From mwatson@nortelnetworks.com Mon Jun 16 09:10:02 2003 From: mwatson@nortelnetworks.com (Mark Watson) Date: Mon, 16 Jun 2003 09:10:02 +0100 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C333DE.1BD96D3A Content-Type: text/plain; charset="iso-8859-1" One small point & I think we are just about agreeing... > > Existing stations have to be able to deal with multiple > physical APs, so > they will also deal with multiple virtual APs that advertise with > different BSSIDs -- since the two cases cannot be distinguished by the > station. Yes, but there is no way today for the station to learn the relationship between SSID it can see and the NAI domains that will be accepted. So, any solution to this will involve the client. Since there is certainly a client impact (at least for clients which support multiple NAI domains), then you might as well allow support of all the NAIs domains on a single SSID, since this does not restrict the way WLAN operators can use SSIDs - and as we know they already use different SSIDs for various other purposes. ...Mark ------_=_NextPart_001_01C333DE.1BD96D3A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Re: deciding which NAI to send in an = ID-RESPONSE

One small point & I think we are just about = agreeing...
>
> Existing stations have to be able to deal with = multiple
> physical APs, so
> they will also deal with multiple virtual APs = that advertise with
> different BSSIDs -- since the two cases cannot = be distinguished by the
> station.

Yes, but there is no way today for the station to = learn the relationship between SSID it can see and the NAI domains that = will be accepted. So, any solution to this will involve the = client.

Since there is certainly a client impact (at least = for clients which support multiple NAI domains), then you might as well = allow support of all the NAIs domains on a single SSID, since this does = not restrict the way WLAN operators can use SSIDs - and as we know they = already use different SSIDs for various other purposes.

...Mark

------_=_NextPart_001_01C333DE.1BD96D3A-- From aboba@mail.internaut.com Mon Jun 16 13:41:14 2003 From: aboba@mail.internaut.com (Bernard Aboba) Date: Mon, 16 Jun 2003 05:41:14 -0700 (PDT) Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE In-Reply-To: References: Message-ID: > Yes, but there is no way today for the station to learn the relationship > between SSID it can see and the NAI domains that will be accepted. So, any > solution to this will involve the client. OK. Since there is no relationship between SSIDs and domains, it may not be obvious what domain is appropriate given the SSID. For example, is it obvious that SSID MSFTWLAN is expecting an NAI of bernarda@microsoft.com, and that an NAI of aboba@internaut.com won't be accepted? Not unless there is preconfiguration or user intervention. If this could be handled automatically it would be better. Note however that since we're talking about FQDNs, there may not be room for a lot of them in the EAP-Request/Identity. From aboba@mail.internaut.com Mon Jun 16 13:55:38 2003 From: aboba@mail.internaut.com (Bernard Aboba) Date: Mon, 16 Jun 2003 05:55:38 -0700 (PDT) Subject: [eap] EAP WG last call on RFC 2284bis Message-ID: This is an announcement of EAP WG last call on RFC 2284bis, prior to sending it on to the IESG for consideration as an IETF Proposed Standard. The draft is not yet available on the IETF archive, but should be there by Wednesday or Thursday at the latest. Until then, it is available for examination here: http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.e.txt When it arrives on the archive, the document will be available for examination here: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt EAP WG last call will last until July 7, 2003. Please send comments to the EAP WG mailing list (eap@frascone.com) in the format specified on the EAP Issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html From mwatson@nortelnetworks.com Mon Jun 16 14:46:45 2003 From: mwatson@nortelnetworks.com (Mark Watson) Date: Mon, 16 Jun 2003 14:46:45 +0100 Subject: [eap] Re: deciding which NAI to send in an ID-RESPONSE Message-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3340D.B99F87C8 Content-Type: text/plain; charset="iso-8859-1" Yes, space might be a problem. But we're not expecting there to be all that many domains available in a single WLAN - there is a limit to the number of relationships that a WLAN owner will be bothered to make/maintain & a law of diminishing returns (in terms of the number of additional potential users each new relationship will bring in). And then, should the Request/Identity advertise just the domains available from this particular SSID, or should it include domains available from other SSIDs in the same area (and those corresponding SSIDs, of course). If the former, then if you do run out of space you have a solution in terms of multiple SSIDs (remembering that this space problem is unlikely to bite for some time, so equipment capability issues are not so pressing). Alternatively, the user does know all the possible domains they could authenticate with - it's just there might be too many to try them one by one. It may be sufficient to provide, say, a 4-octet hash of each FQDN available if we're short of space. Collissions result in users very occasionally attempting to authenticate with a domain which is not available. We should think about this when we have a better idea how many FQDNs we could fit in the message. ...Mark > -----Original Message----- > From: Bernard Aboba [mailto:aboba@mail.internaut.com] > Sent: 16 June 2003 13:41 > To: Watson, Mark [MOP:EP10:EXCH] > Cc: 'jari.arkko@piuha.net'; eap@frascone.com > Subject: RE: [eap] Re: deciding which NAI to send in an ID-RESPONSE > > > > Yes, but there is no way today for the station to learn the > relationship > > between SSID it can see and the NAI domains that will be > accepted. So, any > > solution to this will involve the client. > > OK. Since there is no relationship between SSIDs and domains, > it may not > be obvious what domain is appropriate given the SSID. For > example, is it > obvious that SSID MSFTWLAN is expecting an NAI of > bernarda@microsoft.com, > and that an NAI of aboba@internaut.com won't be accepted? Not > unless there > is preconfiguration or user intervention. If this could be handled > automatically it would be better. > > Note however that since we're talking about FQDNs, there may > not be room > for a lot of them in the EAP-Request/Identity. > ------_=_NextPart_001_01C3340D.B99F87C8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] Re: deciding which NAI to send in an = ID-RESPONSE

Yes, space might be a problem. But we're not = expecting there to be all that many domains available in a single WLAN = - there is a limit to the number of relationships that a WLAN owner = will be bothered to make/maintain & a law of diminishing returns = (in terms of the number of additional potential users each new = relationship will bring in).

And then, should the Request/Identity advertise just = the domains available from this particular SSID, or should it include = domains available from other SSIDs in the same area (and those = corresponding SSIDs, of course). If the former, then if you do run out = of space you have a solution in terms of multiple SSIDs (remembering = that this space problem is unlikely to bite for some time, so equipment = capability issues are not so pressing).

Alternatively, the user does know all the possible = domains they could authenticate with - it's just there might be too = many to try them one by one. It may be sufficient to provide, say, a = 4-octet hash of each FQDN available if we're short of space. = Collissions result in users very occasionally attempting to = authenticate with a domain which is not available. We should think = about this when we have a better idea how many FQDNs we could fit in = the message.

...Mark

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@mail.internaut.com= ]
> Sent: 16 June 2003 13:41
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: 'jari.arkko@piuha.net'; = eap@frascone.com
> Subject: RE: [eap] Re: deciding which NAI to = send in an ID-RESPONSE
>
>
> > Yes, but there is no way today for the = station to learn the
> relationship
> > between SSID it can see and the NAI = domains that will be
> accepted. So, any
> > solution to this will involve the = client.
>
> OK. Since there is no relationship between = SSIDs and domains,
> it may not
> be obvious what domain is appropriate given the = SSID. For
> example, is it
> obvious that SSID MSFTWLAN is expecting an NAI = of
> bernarda@microsoft.com,
> and that an NAI of aboba@internaut.com won't be = accepted? Not
> unless there
> is preconfiguration or user intervention.  = If this could be handled
> automatically it would be better.
>
> Note however that since we're talking about = FQDNs, there may
> not be room
> for a lot of them in the = EAP-Request/Identity.
>

------_=_NextPart_001_01C3340D.B99F87C8-- From aboba@mail.internaut.com Mon Jun 16 23:13:33 2003 From: aboba@mail.internaut.com (Bernard Aboba) Date: Mon, 16 Jun 2003 15:13:33 -0700 (PDT) Subject: [eap] [802.1] Working Group ballot of P802.1aa/D6.1 - 802.1X maintenance (fwd) Message-ID: From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Tony Jeffree Sent: Monday, June 16, 2003 2:49 PM To: stds-802-1@ieee.org Subject: [802.1] Working Group ballot of P802.1aa/D6.1 - 802.1X maintenance This Email is attached to an official 802.1 Task Group ballot form for P802.1aa/D6.1. As this is a full Working Group ballot, only 802.1 voting members and liaisons are entitled to vote; however, any non-voting participants in the activities of 802.1 may submit a "Comment Only" ballot on the draft. In accordance with established practice in 802, all comments received, whether from voters or non-voters, are given due consideration during the ballot resolution process. The closing date of this ballot is: 17th July 2003 The PDF file of P802.1aa/D6.1 can be found at: http://www.ieee802.org/1/files/private/aa-drafts/d6/802-1aa-d6-1.pdf Username: p8021 Password: go_wildcats If you have any difficulty downloading or reading this file, let me know. PLEASE NOTE that the volume of change in this document relative to D5 is large, due to the re-description of the state machines in order to show the distinction between the 802.1X protion and the "EAP Layer" portion of the solution. In order to improve the clarity of the document, all redline/strikout marking has been removed from D6.1, as the clutter of deleted material was rendering the text difficult to read. However, a version of D6.1 with redline/strikeout marking retained can be found in the aa-drafts/d6 subdirectory of the website. As is normal with our ballots, comments should specify not only what problems have been identified with the text, but also what the commenter proposes as a solution. In particular, Disapprove ballots MUST be accompanied by Technical, Required and/or Editorial, Required comments that clearly identify what the balloter requires to be done in order to change his/her vote to Approve. Any comments accompanying the ballot should be presented using the following template: NAME: COMMENT TYPE: CLAUSE: PAGE: LINE: COMMENT START:
COMMENT END: SUGGESTED CHANGES START:
SUGGESTED CHANGES END: RETURNING YOUR BALLOT FORM ========================== Your ballot must be returned to: stds-802-1@ieee.org You are requested to use (exactly!) the appropriate Subject line from the following set when returning your ballot. Please send your ballot with the Subject line explicitly set, rather than using the Reply function in your mailer. P802.1aa/D6.1 Ballot - Approve P802.1aa/D6.1 Ballot - Comments (with approve) P802.1aa/D6.1 Ballot - Disapprove P802.1aa/D6.1 Ballot - Comments (with abstain) P802.1aa/D6.1 Ballot - Abstain Regards, Tony Jeffree 802.1 Chair. ****************************** Ballot form follows..... ****************************** ------------------------------------------------------------------------ ------------------------------------------------------------------------ NOTE: EMAIL ALL BALLOT RESPONSES ONLY TO: stds-802-1@ieee.org ------------------------------------------------------------------------ ------------------------------------------------------------------------ P802.1aa/D6.1 EMAIL BALLOT 16th June 2003 TO: Tony Jeffree Editor, P802.1aa/D6.1 SUBJECT: P802.1aa/D6.1 - 802.1X Maintenance _____ 802.1 Voting Member _____ I Approve (may attach non-binding comments below) _____ I Disapprove (must attach binding comments below) _____ I Abstain for the following reasons (may attach non-binding comments below): ________ Lack of Time ________ Lack of Expertise ________ Other: _______________________________________________ _____ Comment Only - Non-voter (comments attached below) ____________________________________________ (Name) ____________________________________________ (Telephone No.) ------------------------------------------------------------------------ INCLUDE COMMENTS BELOW THIS POINT From jrv@umich.edu Tue Jun 17 02:53:20 2003 From: jrv@umich.edu (John Vollbrecht) Date: Mon, 16 Jun 2003 21:53:20 -0400 Subject: [eap] EAP 2284bis last call issues In-Reply-To: References: Message-ID: <722806.1055800400@[10.0.1.2]> The document is quite good. Thanks to all who have worked on it, including Henri, Bernard, and Jari among others. Three small issues: Issue 1 Editorial Issue: use intial key activation instead of key activation Submitter name: John Vollbrecht Submitter email address:jrv@umich.edu Date first submitted: June 16, 2003 Document: RFC2284bis Comment type: E Priority: '2' Section: 3.1 paragraph 5 Rationale/Explanation of issue: 802 key activation may be prolonged by authentication as well as initiated. The text here applies to initial authentication. Requested change: insert the word ", initial" between "media" and "key activation" Issue 2 Description of issue: Sequences of Methods are not allowed in untunnelled layer methods, but are allowed inside tunnels Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: June 16,2003 Document: RFC2284bis Comment type: T Priority: '2' Section: 7.4 paragraph 2 Rationale/Explanation of issue: Security issues addressed in this section seem to address only what happens in an unprotected EAP method. Section 2.1 indicates that within a tunnel sequences may be used. Requested change: add the word "untunnelled" between the words "permit" and "sequences". Issue 3 Description of issue: Peer policy may allow different methods for different Access Points Submitter name: John Vollbrecht Submitter email address: jrv@umich.edu Date first submitted: June 16,2003 Document: RFC2284bis Comment type: T Priority: '2' Section: 7.8 Paragraph 2 Rationale/Explanation of issue: Peers may include policy, especially when connecting subnets. Additionally the same identity may have different permissions at different Access Points. Requested change: In paragraph 2 make the following 2 changes noted in quotes below - Within or associated with each authenticator, it is not anticipated that a particular named peer will support a choice of methods "for a given connection". This would make the peer vulnerable to attacks that negotiate the least secure method from among a set. Instead, for each named peer there SHOULD be an indication of exactly one method used to authenticate that peer name "at an access point". If a peer needs to make use of different authentication methods under different circumstances, then distinct identities SHOULD be employed, each of which identifies exactly one authentication method. From Internet-Drafts@ietf.org Tue Jun 17 12:38:19 2003 From: Internet-Drafts@ietf.org (Internet-Drafts@ietf.org) Date: Tue, 17 Jun 2003 07:38:19 -0400 Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-04.txt Message-ID: <200306171138.HAA07732@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk et al. Filename : draft-ietf-eap-rfc2284bis-04.txt Pages : 56 Date : 2003-6-16 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix B. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-rfc2284bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-rfc2284bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17075126.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17075126.I-D@ietf.org> --OtherAccess-- --NextPart-- From jari.arkko@piuha.net Tue Jun 17 14:10:11 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 17 Jun 2003 16:10:11 +0300 Subject: [eap] EAP 2284bis last call issues In-Reply-To: <722806.1055800400@[10.0.1.2]> References: <722806.1055800400@[10.0.1.2]> Message-ID: <3EEF1333.8090904@piuha.net> John Vollbrecht wrote: > The document is quite good. Thanks to all who have worked on it, Many thanks to you as well! > Three small issues: > > Issue 1 > > Editorial Issue: use intial key activation instead of key activation > Submitter name: John Vollbrecht > Submitter email address:jrv@umich.edu > Date first submitted: June 16, 2003 > Document: RFC2284bis > Comment type: E > Priority: '2' > Section: 3.1 paragraph 5 > Rationale/Explanation of issue: 802 key activation may be prolonged by > authentication as well as initiated. The text here applies to initial > authentication. > > Requested change: insert the word ", initial" between "media" and "key > activation" I think this is right. > Issue 2 > > Description of issue: Sequences of Methods are not allowed in > untunnelled layer methods, but are allowed inside tunnels > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: June 16,2003 > Document: RFC2284bis > Comment type: T > Priority: '2' > Section: 7.4 paragraph 2 > > Rationale/Explanation of issue: Security issues addressed in this > section seem to address only what happens in an unprotected EAP method. > Section 2.1 indicates that within a tunnel sequences may be used. > > > Requested change: add the word "untunnelled" between the words "permit" > and "sequences". Agree. > Issue 3 > > Description of issue: Peer policy may allow different methods for > different Access Points > Submitter name: John Vollbrecht > Submitter email address: jrv@umich.edu > Date first submitted: June 16,2003 > Document: RFC2284bis > Comment type: T > Priority: '2' > Section: 7.8 Paragraph 2 > > Rationale/Explanation of issue: Peers may include policy, especially > when connecting subnets. Additionally the same identity may have > different permissions at different Access Points. > > > Requested change: In paragraph 2 make the following 2 changes noted in > quotes below - > > Within or associated with each authenticator, it is not anticipated that > a particular named peer will support a choice of methods "for a given > connection". This would make the peer vulnerable to attacks that > negotiate the least secure method from among a set. Instead, for each > named peer there SHOULD be an indication of exactly one method used to > authenticate that peer name "at an access point". If a peer needs to > make use of different authentication methods under different > circumstances, then distinct identities SHOULD be employed, each of > which identifies exactly one authentication method. Hmm... I don't have a warm and fuzzy feeling about this. What if the attacker spoofs the name of the access point to get the bidding down attack started? --Jari From jrv@umich.edu Tue Jun 17 16:07:53 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 17 Jun 2003 11:07:53 -0400 Subject: [eap] EAP 2284bis last call issues In-Reply-To: <3EEF1333.8090904@piuha.net> References: <722806.1055800400@[10.0.1.2]> <3EEF1333.8090904@piuha.net> Message-ID: <922142.1055848072@[10.0.1.2]> Issue three discussion below - --On Tuesday, June 17, 2003 4:10 PM +0300 Jari Arkko wrote: > John Vollbrecht wrote: > > The document is quite good. Thanks to all who have worked on it, > > Many thanks to you as well! > > > Three small issues: > > > > > Issue 3 > > > > Description of issue: Peer policy may allow different methods for > > different Access Points > > Submitter name: John Vollbrecht > > Submitter email address: jrv@umich.edu > > Date first submitted: June 16,2003 > > Document: RFC2284bis > > Comment type: T > > Priority: '2' > > Section: 7.8 Paragraph 2 > > > > Rationale/Explanation of issue: Peers may include policy, especially > > when connecting subnets. Additionally the same identity may have > > different permissions at different Access Points. > > > > > > Requested change: In paragraph 2 make the following 2 changes noted in > > quotes below - > > > > Within or associated with each authenticator, it is not anticipated > > that a particular named peer will support a choice of methods "for a > > given connection". This would make the peer vulnerable to attacks that > > negotiate the least secure method from among a set. Instead, for each > > named peer there SHOULD be an indication of exactly one method used to > > authenticate that peer name "at an access point". If a peer needs to > > make use of different authentication methods under different > > circumstances, then distinct identities SHOULD be employed, each of > > which identifies exactly one authentication method. > > Hmm... I don't have a warm and fuzzy feeling about this. > What if the attacker spoofs the name of the access point > to get the bidding down attack started? > This is where policy must be involved. if the attacker AP bids up, the authentication should go up. If the attacker AP bids down, the authentication and also the rights should go down. Additional info may be involved, depending whether the AP is wireless or wired. Wireless may require Keys and a different authentication method than wired. I think the idea that there should be only one id for each authentication method is too restrictive. The same user should be able to get on in different places, with different rights, using different authentication methods. The user could have different ids for each authentication method and try to match the id to the access type, geographic location, etc. - but this seems unlikely in practice. -- John From jari.arkko@piuha.net Tue Jun 17 16:17:22 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 17 Jun 2003 18:17:22 +0300 Subject: [eap] EAP 2284bis last call issues In-Reply-To: <922142.1055848072@[10.0.1.2]> References: <722806.1055800400@[10.0.1.2]> <3EEF1333.8090904@piuha.net> <922142.1055848072@[10.0.1.2]> Message-ID: <3EEF3102.2030400@piuha.net> John Vollbrecht wrote: > I think the idea that there should be only one id for each > authentication method is too restrictive. The same user should be able > to get on in different places, with different rights, using different > authentication methods. The user could have different ids for each > authentication method and try to match the id to the access type, > geographic location, etc. - but this seems unlikely in practice. I can see your argument. But I'm still worried that without a specific model for what policies are possible, there'll be bidding down problems. For instance, the AP identity does not appear to be a good source for the policy, but link type (wired/wireless) might be slightly better. So, I'd rather err on the safe side and not allow such flexibility. The downside is that it might make things hard for some cases. But I'm not sure how typical the per-AP or per-link type credential policies are. Do you have any information on that? Compared to the SSID and other information presented by the authenticator? --Jari From jrv@umich.edu Tue Jun 17 16:44:20 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 17 Jun 2003 11:44:20 -0400 Subject: [eap] schedule for SM draft for Vienna In-Reply-To: References: Message-ID: <1053422.1055850260@[10.0.1.2]> --On Monday, June 16, 2003 9:19 PM -0400 Nick Petroni wrote: > > What do you envision as the schedule from here on? I am heading back to > the UK on Weds and will be working remotely a few days next week. I think > the deadline for Vienna drafts is June 30 so I think we should aim to get > an -04 by next friday if that is our goal. Let me know what you think. > Nick - thanks for the heads up. I would like to have a clean version of the SM doc by the end of next week. I think there are a few issues remaining. I will list the ones I am aware of - we do not have a tracking mechanism as Bernard has set up for 2284bis, so we will need to rely on memory some. I think we should have one more conf call - perhaps next week sometime to be sure we are all ok. The issues I know of are 1. Need to show how method can silently discard Notify Req if is so constituted. (Sec. 5.2 of 2284bis) 2. Success and Fail need to return something (eapNoResp) so lower layer can finish (Jim Burns) 3. Expanded NAK MUST NOT be sent in a REQ (Pasi Erronen - is this fixed?) 4. Yoshihiro Ohba's issues (memo 6-3) - I will respond and we can do email for a bit of this. Perhaps Pasi has a suggestion. Please list any other issues. Jari - I think yours have been covered, and I think most of Pasi's have been covered. Please note if some have been missed. Finally, I would like to talk about add on docs. I think Pasi's description of issues could be a good start. It might be part of or different from a description of how tunnelled methods are constructed and used. Pasi has thought about a "tunnelled" EAP state machine which might be part of this. I think such a document or documents are useful in conjunction with 2284bis and SM. Discussion is welcome. From henrik@levkowetz.com Tue Jun 17 18:30:28 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 17 Jun 2003 19:30:28 +0200 Subject: [eap] WG last call issue: EAP-04 editorial nits Message-ID: <20030617193028.58d21882.henrik@levkowetz.com> Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: June 17, 2003 Document: EAP-04 Comment type: E Priority: 1 Section: Various Rationale/Explanation of issue: Section 1.3: "Acknowledged result indications The ability of the authenticator to provide the peer with an indication of whether the peer has successfully authenticated to it, and for the peer to acknowledge receipt, as well as providing an indication of whether the authenticator has successfully authenticated to the peer. Since EAP Success and Failure packets are neither acknowledged nor integrity protected, this claim requires implementation of a method-specific result exchange that is authenticated, integrity and replay protected on a per-packet basis." s/authenticated, /authenticated and/ Section 2.2: "EAP packets with codes of Success or Failure do not include a Type, and therefore are not delivered to an EAP method. Success and Failure are discussed in Section 4.2." s/and therefore/and/ (- I don't see an immediate logic, so I'd rather just state the rule here.) Section 3.1: "[1] Unreliable transport. In EAP, the authenticator retransmits Requests that have not yet received Responses, so that EAP does not assume that lower layers are reliable. Since EAP defines it own retransmission behavior, when run over a reliable lower layer, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer." Awkward. Rewrite last part to: "Since EAP defines its own retransmission behavior, it is possible (though undesirable) for retransmission to occur both in the lower layer and the EAP layer when EAP is run over a reliable lower layer." ... "After EAP authentication is complete, the peer will typically transmit data to the network via the authenticator. In order to provide assurance that the peer transmitting data is the same entity that successfully completed EAP authentication, the lower layer needs to bind per-packet integrity, authentication and replay protection to the original EAP authentication, using keys derived during EAP authentication. Alternatively, the lower layer needs to be physically secure. Otherwise it is possible for subsequent data traffic to be hijacked, or replayed." s/hijacked,/hijacked/ ... "In IEEE 802 media, key activation also typically occurs after completion of EAP authentication. Therefore an initial EAP exchange typically cannot be protected by lower layer ciphersuite, although an EAP re-authentication or pre-authentication exchange can be protected." s/by lower layer/by the lower layer/ Section 4.1: "Retransmitted Requests MUST be sent with the same Identifier value in order to distinguish them from new Requests. The contents of the data field are dependent on the Request Type. The peer MUST send a Response packet in reply to a valid Request packet. Responses MUST only be sent in reply to a valid Request and never retransmitted on a timer." s/The contents of the data field are/The content of the data field is/ Section 5.3.2: "Length >=40" Is my math off today? I count the length to 20 octets or more, not 40 or more. s/40/20/ ... 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 (OTP) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 20 (MIT) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s/Length/Length=28/ An Expanded Nak Response indicating a no desired alternative would appear as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Nak) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=254 | 0 (IETF) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (No alternative) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s/Length/Length=20/ Section 5.7: "The Expanded Type is also used to expand the global Method Type space beyond the original 255 values. A Vendor-Id of 0 maps the original 255 possible Types onto a namespace of 2^32-1 possible Types, allowing for virtually unlimited expansion. (Type 0 is only used in a Nak Response, to indicate no acceptable alternative)" s/namespace/number space/ s/, allowing for virtually unlimited expansion// (the last part of the sentence, while true, is maybe too much elaborating the obvious?) Section 7.4 Man-in-the-middle attacks: "As noted in Section 2.1, EAP does not permit sequences of authentication methods. Were a sequence of EAP authentication methods to be permitted, the peer might not have proof that a single entity has acted as the authenticator for all EAP methods within the sequence. For example, an authenticator might terminate one EAP method, then forward the next method in the sequence to another party without the peer's knowledge or consent. Similarly, the authenticator might not have proof that a single entity has acted as the peer for all EAP methods within the sequence. This enables an attack by a rogue EAP authenticator tunneling EAP to ..." s/This enables/Tunnelling EAP within another protocol enables/ Section 7.6: "Where EAP runs over lower layers which are not physically secure, in order to protect against dictionary attacks, an authentication algorithm resistant to dictionary attack (as defined in Section 7.2) SHOULD be used." Rewrite as: "In order to protect against dictionary attacks, an authentication algorithm resistant to dictionary attack (as defined in Section 7.2) SHOULD be used where EAP runs over lower layers which are not physically secure." "If an authentication algorithm is used that is known to be vulnerable to dictionary attack, then the conversation may be tunneled within a protected channel, in order to provide additional protection. However, as noted in Section 7.4, EAP tunneling may result in a man-in-the-middle vulnerability, and therefore dictionary attack resistant methods are preferred." s/channel,/channel/ Section Appendix B. Changes from RFC 2284: Add: "o In sections 5, 5.1 and 5.2, requirements has been added that fields with displayable messages should contain UTF-8 encoded ISO 10646 characters." From henrik@levkowetz.com Tue Jun 17 18:33:54 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 17 Jun 2003 19:33:54 +0200 Subject: [eap] EAP 2284bis last call issues In-Reply-To: <722806.1055800400@[10.0.1.2]> References: <722806.1055800400@[10.0.1.2]> Message-ID: <20030617193354.377260e3.henrik@levkowetz.com> On Mon, 16 Jun 2003 21:53:20 -0400 John Vollbrecht wrote: > The document is quite good. Thanks to all who have worked on it, including > Henri, Bernard, and Jari among others. Thanks, and of course the same thanks are due to yourself, too, John! Henrik -- Basic research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun From henrik@levkowetz.com Tue Jun 17 18:44:09 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 17 Jun 2003 19:44:09 +0200 Subject: [eap] WG last call issue: EAP-04 Section 5.3 - use of zero in a NAK Message-ID: <20030617194409.67f102e8.henrik@levkowetz.com> Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: June 17, 2003 Document: EAP-04 Comment type: T Priority: 1 Section: 5.3 Rationale/Explanation of issue: There is various text on the use of zero in a NAK, for instance, Section 5.3.1 says: "The legacy Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. The Response contains one or more authentication Types desired by the Peer. Type zero (0) is used to indicate that the sender has no viable alternatives." Reading this, I wondered: When is the value zero used in a NAK? When the peer doesn't want to *disclose* alternatives, or when there are none left? May the authenticator continue probing after receiving a zero NAK? From jrv@umich.edu Tue Jun 17 20:16:40 2003 From: jrv@umich.edu (John Vollbrecht) Date: Tue, 17 Jun 2003 15:16:40 -0400 Subject: [eap] EAP 2284bis last call issues Message-ID: <1144537.1055863000@[10.0.1.2]> some notes below - --On Tuesday, June 17, 2003 6:17 PM +0300 Jari Arkko wrote: > John Vollbrecht wrote: > > > I think the idea that there should be only one id for each > > authentication method is too restrictive. The same user should be able > > to get on in different places, with different rights, using different > > authentication methods. The user could have different ids for each > > authentication method and try to match the id to the access type, > > geographic location, etc. - but this seems unlikely in practice. > > I can see your argument. > > But I'm still worried that without a specific model > for what policies are possible, there'll be bidding down > problems. For instance, the AP identity does not appear to be > a good source for the policy, but link type (wired/wireless) > might be slightly better. > > So, I'd rather err on the safe side and not allow such > flexibility. The downside is that it might make things > hard for some cases. But I'm not sure how typical the > per-AP or per-link type credential policies are. Do > you have any information on that? Compared to the SSID > and other information presented by the authenticator? > I think there can be specific models and policies. Creating a draft that does not allow them seems to be a problem. For example, while an attacking AP may claim to be someone else, it won't be able to authenticate as someone else. If , for example, the AP claims to be X but can't prove it, then there is no connection. A claim that a peer may choose only one method seems reasonable, but that it must always be the same seems not so reasonable. In this case the user my have two identities. Depending on who the AP is it may used a selected identity. If it chooses based on the AP id, then it is no different than policy, and the AP can try to negotiate down. What I hear is that people would like to be able to use the same identity to authenticate from multiple places - e.g. from a wireless location, from a dialup location, from a hot spot, from a visitor lounge, from their desk. Seems reasonable to me - am I missing something? John From henrik@levkowetz.com Tue Jun 17 20:32:26 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 17 Jun 2003 21:32:26 +0200 Subject: [eap] WG last call issue: EAP-04 Terminology: Man-in-the-Middle resistance Message-ID: <20030617213226.156a0503.henrik@levkowetz.com> Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: June 17, 2003 Document: EAP-04 Comment type: T Priority: S Section: Terminology and throughout Rationale/Explanation of issue: "Man-in-the-Middle resistance". I don't really feel comfortable with the use of this term. From what I know, Man-in-the-middle attacks have a well established existing meaning, while here we are defining something related which applies only to sequences or tunnelled methods. If a reader skips lightly over the definitions, and doesn't catch the limited meaning of this term, the classification of MitM resistance: N/A for the basic authentication methods will not make sense, or in the worst case be misleading. If I understand the issues correctly, all the basic authentication methods (MD5, OTP, GTC) *are* vulnerable to classic MitM attacks - but our MitM resistance term describes something else, and I'd therefore prefer to call it something else. From henrik@levkowetz.com Tue Jun 17 20:34:57 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Tue, 17 Jun 2003 21:34:57 +0200 Subject: [eap] WG last call issue: EAP-04 Section 2.2: EAP multiplexing model requriements Message-ID: <20030617213457.262d0a27.henrik@levkowetz.com> Submitter name: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: June 17, 2003 Document: EAP-04 Comment type: T Priority: 1 Section: 2.2 EAP multiplexing model Rationale/Explanation of issue: The draft says: "Since EAP authentication methods may wish to access the Identity, the Identity Request and Response can be assumed to be accessible to authentication methods (Types 4 or greater) in addition to the Identity method. The Identity Type is discussed in Section 5.1." There's a requirement on an implementation here, I think. Maybe we should say that the Identity Request and Response SHOULD or MUST be made accessible to authentication methods? From jari.arkko@piuha.net Wed Jun 18 20:31:58 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 18 Jun 2003 22:31:58 +0300 Subject: [eap] WG last call issue: EAP-04 Section 5.3 - use of zero in a NAK In-Reply-To: <20030617194409.67f102e8.henrik@levkowetz.com> References: <20030617194409.67f102e8.henrik@levkowetz.com> Message-ID: <3EF0BE2E.9060602@piuha.net> > "The legacy Nak Type is valid only in Response messages. It is > sent in reply to a Request where the desired authentication Type > is unacceptable. Authentication Types are numbered 4 and above. > The Response contains one or more authentication Types desired by > the Peer. Type zero (0) is used to indicate that the sender has > no viable alternatives." > > Reading this, I wondered: When is the value zero used in a NAK? When the > peer doesn't want to *disclose* alternatives, or when there are none > left? May the authenticator continue probing after receiving a zero NAK? The text seems to say that the peer has no alternatives. Still, I wonder if zero is used for other purposes as well. Has it been used for implementations that can't tell what methods might be appropriate? If not, I'd rather say SHOULD NOT probe after receiving a zero NAK. --Jari From jari.arkko@piuha.net Wed Jun 18 20:54:25 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 18 Jun 2003 22:54:25 +0300 Subject: [eap] WG last call issue: EAP-04 Terminology: Man-in-the-Middle resistance In-Reply-To: <20030617213226.156a0503.henrik@levkowetz.com> References: <20030617213226.156a0503.henrik@levkowetz.com> Message-ID: <3EF0C371.3000801@piuha.net> > "Man-in-the-Middle resistance". > > I don't really feel comfortable with the use of this term. From what I > know, Man-in-the-middle attacks have a well established existing > meaning, while here we are defining something related which applies only > to sequences or tunnelled methods. If a reader skips lightly over the > definitions, and doesn't catch the limited meaning of this term, the > classification of MitM resistance: N/A for the basic authentication > methods will not make sense, or in the worst case be misleading. > > If I understand the issues correctly, all the basic authentication > methods (MD5, OTP, GTC) *are* vulnerable to classic MitM attacks - > but our MitM resistance term describes something else, and I'd > therefore prefer to call it something else. I agree. MITM is too general term. "Compound authentication Man-in-the-Middle attack resistance"? Shorter name would be useful... --Jari From jari.arkko@piuha.net Wed Jun 18 21:00:57 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Wed, 18 Jun 2003 23:00:57 +0300 Subject: [eap] WG last call issue: EAP-04 Section 2.2: EAP multiplexing model requriements In-Reply-To: <20030617213457.262d0a27.henrik@levkowetz.com> References: <20030617213457.262d0a27.henrik@levkowetz.com> Message-ID: <3EF0C4F9.3020202@piuha.net> > The draft says: > > "Since EAP authentication methods may wish to access the Identity, the > Identity Request and Response can be assumed to be accessible to > authentication methods (Types 4 or greater) in addition to the > Identity method. The Identity Type is discussed in Section 5.1." > > There's a requirement on an implementation here, I think. > Maybe we should say that the Identity Request and Response > SHOULD or MUST be made accessible to authentication methods? Yes. ... esponse SHOULD be accessible to ....? --Jari From yohba@tari.toshiba.com Wed Jun 18 13:35:29 2003 From: yohba@tari.toshiba.com (Yoshihiro Ohba) Date: Wed, 18 Jun 2003 05:35:29 -0700 Subject: [eap] EAP WG last call on RFC 2284bis In-Reply-To: References: Message-ID: <20030618123529.GA2377@steelhead> Description of issue: Lower-layer behavior for limited access Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date first submitted: June 18, 2003 Document: RFC2284bis Comment type: T Priority: 1 Section: 4.2 Rationale/Explanation of issue: Text in section 7.9 allows limited access for peer after completion of EAP authentication with failure, with stating that the interaction of EAP with lower layers are highly implementation dependent. On the other hand, the following text in section 4.2 contains some wording that does not seem to consistent with section 7.9. "On the peer, once the method completes unsuccessfully (that is, either the authenticator sends a method-specific failure indication, or the peer decides that it does want to continue the conversation, possibly after sending a method-specific failure indication), the peer MUST terminate the conversation and avoid sending data on the link." I think whether the peer avoids sending data on the link is a sort of thing that should be described in each lower-layer protocol that carries EAP, since this is heavily lower-layer dependent as described in section 7.9. In fact, if the peer avoids sending data on the link, limited access scenario cannot be realized (though it might depend on the definition of "link"). In sectioni 4.2, it is described that a backend EAP server can send EAP Success when it does not need to authenticate the peer, but how it can determine it does not need to authenticate the peer in a roaming environment where it might be difficult for the EAP server to know the network access policy on the remote NAS? I know this issue was recently discussed and section 4.2 was updated to reflect the discussion, but I still find an inconsistency that should be resolved. Requested change: Remove "and avoid sending data on the link". Thanks, Yoshihiro Ohba From henrik@levkowetz.com Thu Jun 19 10:50:56 2003 From: henrik@levkowetz.com (Henrik Levkowetz) Date: Thu, 19 Jun 2003 11:50:56 +0200 Subject: [eap] WG last call issue: EAP-04 Terminology: Man-in-the-Middle resistance In-Reply-To: <3EF0C371.3000801@piuha.net> References: <20030617213226.156a0503.henrik@levkowetz.com> <3EF0C371.3000801@piuha.net> Message-ID: <20030619115056.0f4a41b6.henrik@levkowetz.com> On Wed, 18 Jun 2003 22:54:25 +0300 Jari Arkko wrote: > > > "Man-in-the-Middle resistance". > > > > I don't really feel comfortable with the use of this term. From what I > > know, Man-in-the-middle attacks have a well established existing > > meaning, while here we are defining something related which applies only > > to sequences or tunnelled methods. If a reader skips lightly over the > > definitions, and doesn't catch the limited meaning of this term, the > > classification of MitM resistance: N/A for the basic authentication > > methods will not make sense, or in the worst case be misleading. > > > > If I understand the issues correctly, all the basic authentication > > methods (MD5, OTP, GTC) *are* vulnerable to classic MitM attacks - > > but our MitM resistance term describes something else, and I'd > > therefore prefer to call it something else. > > I agree. MITM is too general term. > > "Compound authentication Man-in-the-Middle attack resistance"? > > Shorter name would be useful... Slightly shorter: Compound method MitM resistance ? Henrik -- Experience is something you don't get until just after you need it. From jari.arkko@piuha.net Thu Jun 19 12:38:20 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Thu, 19 Jun 2003 14:38:20 +0300 Subject: [eap] WG last call issue: EAP-04 Terminology: Man-in-the-Middle resistance In-Reply-To: <20030619115056.0f4a41b6.henrik@levkowetz.com> References: <20030617213226.156a0503.henrik@levkowetz.com> <3EF0C371.3000801@piuha.net> <20030619115056.0f4a41b6.henrik@levkowetz.com> Message-ID: <3EF1A0AC.4040804@piuha.net> > Compound method MitM resistance ? Good enough. For for it. But maybe s/method/authentication/. --Jari From jrv@umich.edu Thu Jun 19 13:31:36 2003 From: jrv@umich.edu (John Vollbrecht) Date: Thu, 19 Jun 2003 08:31:36 -0400 Subject: [eap] EAP WG last call on RFC 2284bis In-Reply-To: <20030618123529.GA2377@steelhead> References: <20030618123529.GA2377@steelhead> Message-ID: <2189703.1056011496@[10.0.1.2]> I asgree with this. EAP should not specify behaviour on otherlayers -- John --On Wednesday, June 18, 2003 5:35 AM -0700 Yoshihiro Ohba wrote: > > > Description of issue: Lower-layer behavior for limited access > Submitter name: Yoshihiro Ohba > Submitter email address: yohba@tari.toshiba.com > Date first submitted: June 18, 2003 > Document: RFC2284bis > Comment type: T > Priority: 1 > Section: 4.2 > Rationale/Explanation of issue: > > Text in section 7.9 allows limited access for peer after completion of > EAP authentication with failure, with stating that the interaction of > EAP with lower layers are highly implementation dependent. > > On the other hand, the following text in section 4.2 contains > some wording that does not seem to consistent with section 7.9. > > "On the peer, once the method completes unsuccessfully (that is, > either the authenticator sends a method-specific failure indication, > or the peer decides that it does want to continue the conversation, > possibly after sending a method-specific failure indication), the peer > MUST terminate the conversation and avoid sending data on the link." > > I think whether the peer avoids sending data on the link is a sort of > thing that should be described in each lower-layer protocol that > carries EAP, since this is heavily lower-layer dependent as described > in section 7.9. In fact, if the peer avoids sending data on the link, > limited access scenario cannot be realized (though it might depend on > the definition of "link"). In sectioni 4.2, it is described that a > backend EAP server can send EAP Success when it does not need to > authenticate the peer, but how it can determine it does not need to > authenticate the peer in a roaming environment where it might be > difficult for the EAP server to know the network access policy on the > remote NAS? I know this issue was recently discussed and section 4.2 > was updated to reflect the discussion, but I still find an > inconsistency that should be resolved. > > Requested change: > > Remove "and avoid sending data on the link". > > > Thanks, > Yoshihiro Ohba > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From jari.arkko@piuha.net Mon Jun 23 08:16:25 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 23 Jun 2003 10:16:25 +0300 Subject: [eap] agenda items for Vienna Message-ID: <3EF6A949.7030709@piuha.net> In Vienna, the EAP WG will have two slots, Monday 15:30 - 17:30 and Thursday 13:00-15:00. We will be talking about 2284bis and its issues (I'm hoping there'd be none left, but...), the state machine draft, issues in the keying framework, and the compound binding problem. If you have an additional agenda item for the meeting, please send mail to the chairs. --Jari From jari.arkko@piuha.net Mon Jun 23 11:24:40 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Mon, 23 Jun 2003 13:24:40 +0300 Subject: [eap] review of sm-03: authenticator Message-ID: <3EF6D568.4060501@piuha.net> I'm reviewing the state machine draft version 03 (http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-03.ps). The authenticator state machine in Section 5 appears to be in very good shape, I like it! I have a few nits and question marks, however: 1) The three calls to Policy.update have different argument lists. It would help the reader if the state machine explicitly defined what input goes to this function. Looks like it is given eapRespData (either in a method or in a NAK), as well as the flags that the authenticator has already calculated, e.g., was the response valid. How about Policy.update(currentMethod, eapRespData, intCheck) 2) Can't find calculateTimeout from 5.3. 3) I'd rather not see a "..." in the calculateTimeout argument list. Can we be more specific? See also item 1 above. 4) I'm not sure if the m.buildSuccFail in the diagram (state METHOD) and 2284bis Section 4.2 requirements are aligned. The latter seems to require that after a method specific indication, we still must send a Success or Failure. But maybe I'm just confused by what "m.buildSuccFail" means since I haven't read the passthrough part of the document yet. 5) Similarly, I'm not sure the state machine prevents the sending of a canned Success. These seem to be forbidden by 2284bis Section 4.2. 6) Should there be initializations of all variables in the DISABLED and BACKEND_DISABLED states? Variables such as eapFail do not appear to get an initial value, at least not in the diagram. The text says it is initialized by the lower layer, but why? Wouldn't it be easier to treat this variable as an EAP layer variable which is only read by the lower layer, not set? 7) Section 5.1.1 s/outside/Outside/ 8) Section 5.2 indentation looks funny. 9) Can you explain why BACKEND_DISABLED and DISABLED have to be separate states? It looks like they could be combined, and the EapBackend variable could be checked before branching on to the next states. But perhaps this has something to do with the IEEE lower layer state machine interface? 10) Why not use the same substructure in 5.2 as is used in 5.1? Variables from method->eap layer, eap layer-> method, etc. Then you could also group 5.4 contents into its appropriate place in 5.1/5.2/5.3. --Jari From jari.arkko@piuha.net Tue Jun 24 07:51:28 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Tue, 24 Jun 2003 09:51:28 +0300 Subject: [eap] review of sm-03: authenticator In-Reply-To: <3EF6D568.4060501@piuha.net> References: <3EF6D568.4060501@piuha.net> Message-ID: <3EF7F4F0.4010909@piuha.net> Additional comments on the state machine draft version 03 (http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-03.ps). Overall, I like the way that you have represented the passthrough and direct/AAA authenticators. The separation of the state machines to small pieces in nicely organized layers is very good design -- thanks! I do have some comments, though: 1) In the overview figure in Section 6.2, if I have understood correctly the two authenticator state machines have been instantiated with a different EapBackend value. Perhaps this could be shown in the figure. 2) It would be very useful to have the same kind of variable and interface descriptions following the passthrough and backend state machines as were given for the authenticator. 3) I don't understand why Policy.update needs to be called in the AAA_FAILURE state of the passthrough state machine. If this happen, we fail completely, right? 4) Similarly, I'm not sure I understand what the policy updates do in AAA_REJECT and AAA_ACCEPT. Can you clarify? 5) In state AAA_REQUEST, maybe change if (isIdentity(eapRespData)) to if (respId == currentId) unless I'm missing something... 6) The passthrough state machine does not appear to contain all processing required by RFC 2869bis. For instance, Section 2.6.3 about conflicting messages is not described. This may be fine, but at least there should be an explanation of the scope of the state machine. 7) References need to be split to normative and non-normative. I'd say 2284bis and 2869bis are normative along with RFC 2119. IEEE is non-normative. 8) Are these all references? I suspect at least the keying framework needs to be referenced. 9) The format used for describing the state machine and the actions. Do you have a possibility for feeding this into a state machine tool for analysis? Also, http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt mentions that you can use languages such as C. However, the IESG statement said that it must be clear whether you just use some pseudo code that just looks like C or the language itself. I think we have the former case. This should be stated. Finally, the IESG statement requires a normative reference to the used language or format. In this case I don't think we have it, or? If not, maybe we should be more strict in defining the language used for the actions, say with BNF, including semantics defined in English? --Jari From aboba@mail.internaut.com Tue Jun 24 12:53:35 2003 From: aboba@mail.internaut.com (Bernard Aboba) Date: Tue, 24 Jun 2003 04:53:35 -0700 (PDT) Subject: [eap] EAP MTU? Message-ID: The question has arisen in AAA WG as to exactly how RFC 2869bis implementations interpret the Framed-MTU attribute. If you have implemented RFC 2869bis, can you reply to this message stating: a) If you utilize the Framed-MTU attribute at all. b) If you do utilize it, how the maximum size EAP packet is calculated from it. From Pasi.Eronen@nokia.com Wed Jun 25 13:53:40 2003 From: Pasi.Eronen@nokia.com (Pasi.Eronen@nokia.com) Date: Wed, 25 Jun 2003 15:53:40 +0300 Subject: [eap] review of sm-03: authenticator Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BB44@esebe023.ntc.nokia.com> Thanks for your review! See below for comments to=20 both of your emails: Jari Arkko wrote (23.6.): > > I'm reviewing the state machine draft version 03 > = (http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-03.ps). > The authenticator state machine in Section 5 appears to be in > very good shape, I like it! >=20 > I have a few nits and question marks, however: >=20 > 1) The three calls to Policy.update have different > argument lists. It would help the reader if the > state machine explicitly defined what input goes > to this function. Looks like it is given eapRespData > (either in a method or in a NAK), as well as the flags > that the authenticator has already calculated, e.g., > was the response valid. How about > > Policy.update(currentMethod, eapRespData, intCheck) The diagram was done back when sequences were still allowed...=20 The idea was that Policy is independent of methods, and the methods just feed somethign to the Policy (e.g. "I've authenticated the peer as joe@example.com") and the Policy would decide what to do next (e.g. permit or deny access, follow with some other method, etc.). I guess the real problem here is that the "pseudo-code" in METHOD isn't really C-like pseudo-code at all -- it just illustrates that the method should feed something to the policy. Nothing really restricts what sort of information is communicated here. In theory, Policy could have access to everything that can be deduced from eapRespData, but this would require the Policy knows how to parse it. One alternative would be to replace the Policy.update call with "m.process(eapRespData, Policy)", meaning that m.process would feed something to the Policy. =20 Or "Policy.update(m.getPolicyInformation())"? > 2) Can't find calculateTimeout from 5.3. OK, will be added. > 3) I'd rather not see a "..." in the calculateTimeout > argument list. Can we be more specific? See also > item 1 above. 2284bis is quite vague on this. I guess we could specify=20 RFC2988 style behavior here: add two new variables (eapSRTT, eapRTTVAR) that are set by the lower layer,=20 and give them to calculateTimeout. Would this be better? > 4) I'm not sure if the m.buildSuccFail in the diagram > (state METHOD) and 2284bis Section 4.2 requirements > are aligned. The latter seems to require that after > a method specific indication, we still must send > a Success or Failure. But maybe I'm just confused > by what "m.buildSuccFail" means since I haven't > read the passthrough part of the document yet. m.buildSuccFail actually just takes the Success/Failure packet=20 from the Access-Accept/Reject message. Maybe we should rename it=20 to something more understandable (m.getSuccFail) or at least document it better... > 5) Similarly, I'm not sure the state machine prevents > the sending of a canned Success. These seem to be > forbidden by 2284bis Section 4.2. You're right, it does not prevent this: if Policy.isSatisfied()=20 always returns TRUE, the authenticator just sends a "canned"=20 EAP Success packet. (There are other things Policy shouldn't do, e.g. sequences, contradict method-specific result indications, etc.) > 6) Should there be initializations of all variables > in the DISABLED and BACKEND_DISABLED states? Variables > such as eapFail do not appear to get an initial > value, at least not in the diagram. The text says > it is initialized by the lower layer, but why? Wouldn't > it be easier to treat this variable as an EAP layer > variable which is only read by the lower layer, not set? I just checked 802.1aa/D6.1, and they certainly don't initialize=20 the variables... I guess there are two possible solutions: - Add statement saying "All boolean variables are initialized=20 to FALSE before the state machine execution begins." I would really prefer this option. =20 - If variables have undetermined values before they are assigned, then we need a lot of initializations. The problem is that e.g. eapFail has to be initialized in lower layer, because otherwise we get synchronization issues (the lower layer could read it before the initialization block in EAP state=20 machine has been executed). Figuring out what goes where is a lot of work.. I guess this should be checked with the 802.1aa folks as well. (John, are you reading this?) > 7) Section 5.1.1 s/outside/Outside/ OK. > 8) Section 5.2 indentation looks funny. I agree. =20 > 9) Can you explain why BACKEND_DISABLED and DISABLED > have to be separate states? It looks like they > could be combined, and the EapBackend variable > could be checked before branching on to the next > states. But perhaps this has something to do with > the IEEE lower layer state machine interface? They could be combined (and were combined in an earlier version),=20 but we thought it's easier to read this way. > 10) Why not use the same substructure in 5.2 as is used > in 5.1? Variables from method->eap layer, eap layer-> > method, etc. Then you could also group 5.4 contents into > its appropriate place in 5.1/5.2/5.3. Most of 5.2 is just descriptive text, which is more difficult to group. Also, the interface to the lower layer is quite well-defined, but the interface to methods isn't that clear (or another way to put it would be that "many difficult details are hidden in Policy calls"). Then your next message: Jari Arkko wrote (24.6.): > > Additional comments on the state machine draft version 03 > = (http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-03.ps). > Overall, I like the way that you have represented the passthrough > and direct/AAA authenticators. The separation of the state machines > to small pieces in nicely organized layers is very good design -- > thanks! >=20 > I do have some comments, though: >=20 > 1) In the overview figure in Section 6.2, if I have understood > correctly the two authenticator state machines have been > instantiated with a different EapBackend value. Perhaps > this could be shown in the figure. OK. > 2) It would be very useful to have the same kind of > variable and interface descriptions following the passthrough > and backend state machines as were given for the authenticator. Agreed. Will be added. > 3) I don't understand why Policy.update needs to be called > in the AAA_FAILURE state of the passthrough state machine. > If this happen, we fail completely, right? Yes, we fail, but before the authenticator state machine reaches=20 the FAILURE state, it calls Policy.isSatisfied() and Policy.getNextMethod(). The Policy.update call just informs=20 the policy so it knows to return the correct values (FALSE and NONE). > 4) Similarly, I'm not sure I understand what the policy updates > do in AAA_REJECT and AAA_ACCEPT. Can you clarify? Same as above.=20 > 5) In state AAA_REQUEST, maybe change > if (isIdentity(eapRespData)) > to > if (respId =3D=3D currentId) > unless I'm missing something... Here "identity" actually refers to contents of Identity Response, not ID number field. (Yes, you're right, we need a list of variables/procedures for these :-) > 6) The passthrough state machine does not appear to contain > all processing required by RFC 2869bis. For instance, > Section 2.6.3 about conflicting messages is not described. > This may be fine, but at least there should be an > explanation of the scope of the state machine. I think the backend authenticator+adapter can't ever send conflicting messages (EAP Success inside Access-Reject or vice versa). Do you think the pass-through authenticator+forwarder needs something=20 special for this? > 7) References need to be split to normative and non-normative. > I'd say 2284bis and 2869bis are normative along with RFC 2119. > IEEE is non-normative. Ok (but see below; we might want to make IEEE normative). > > 8) Are these all references? I suspect at least the keying > framework needs to be referenced. Yes, we actually mention the keying framework in the text, so we should add a reference. > 9) The format used for describing the state machine and > the actions. Do you have a possibility for feeding this > into a state machine tool for analysis? >=20 > Also, http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt > mentions that you can use languages such as C. However, the IESG > statement said that it must be clear whether you just use > some pseudo code that just looks like C or the language itself. > I think we have the former case. This should be stated. >=20 > Finally, the IESG statement requires a normative reference > to the used language or format. In this case I don't think > we have it, or? If not, maybe we should be more strict in > defining the language used for the actions, say with BNF, > including semantics defined in English? No, we don't have any analysis tool for this (also, it's not clear what results any tool could give for these diagrams alone?). The pseudocode is defined in 802.1X-2001 Maybe we should just add=20 a normative reference there, and remove Section 3.1 (so we don't=20 have to copy the pseudo-code definition as well)? Best regards, Pasi From jrv@umich.edu Wed Jun 25 20:41:30 2003 From: jrv@umich.edu (John Vollbrecht) Date: Wed, 25 Jun 2003 15:41:30 -0400 Subject: [eap] review of sm-03: authenticator In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB44@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BB44@esebe023.ntc.nokia.com> Message-ID: <6561179.1056555690@[10.0.1.2]> Thanks for the review -- some comments in line - John --On Wednesday, June 25, 2003 3:53 PM +0300 Pasi.Eronen@nokia.com wrote: > Thanks for your review! See below for comments to > both of your emails: > > Jari Arkko wrote (23.6.): > > > > I'm reviewing the state machine draft version 03 > > (http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-03.ps). > > The authenticator state machine in Section 5 appears to be in > > very good shape, I like it! > > thanks ! > > I have a few nits and question marks, however: > > > > 1) The three calls to Policy.update have different > > argument lists. It would help the reader if the > > state machine explicitly defined what input goes > > to this function. Looks like it is given eapRespData > > (either in a method or in a NAK), as well as the flags > > that the authenticator has already calculated, e.g., > > was the response valid. How about > > > > Policy.update(currentMethod, eapRespData, intCheck) > > The diagram was done back when sequences were still allowed... > The idea was that Policy is independent of methods, and the methods > just feed somethign to the Policy (e.g. "I've authenticated the peer > as joe@example.com") and the Policy would decide what to do next > (e.g. permit or deny access, follow with some other method, etc.). > We may have a difference of bias here - my opinion is that this should not allow sequences outside tunnels but they are ok inside. This means that if EAP will work with both tunnelled and untunnelled methods, sequences must be possible. In untunnelled methods they are not allowed but in others they are. There are a number of things that are to be worked out, but I believe we agree on this. > I guess the real problem here is that the "pseudo-code" in METHOD > isn't really C-like pseudo-code at all -- it just illustrates that the > method should feed something to the policy. Nothing really restricts > what sort of information is communicated here. In theory, Policy > could have access to everything that can be deduced from eapRespData, > but this would require the Policy knows how to parse it. > > One alternative would be to replace the Policy.update call with > "m.process(eapRespData, Policy)", meaning that m.process would > feed something to the Policy. > Or "Policy.update(m.getPolicyInformation())"? > I think what we have is fine. The others could work if others feel strongly. > > 2) Can't find calculateTimeout from 5.3. > > OK, will be added. > > > 3) I'd rather not see a "..." in the calculateTimeout > > argument list. Can we be more specific? See also > > item 1 above. > > 2284bis is quite vague on this. I guess we could specify > RFC2988 style behavior here: add two new variables > (eapSRTT, eapRTTVAR) that are set by the lower layer, > and give them to calculateTimeout. Would this be better? > > > 4) I'm not sure if the m.buildSuccFail in the diagram > > (state METHOD) and 2284bis Section 4.2 requirements > > are aligned. The latter seems to require that after > > a method specific indication, we still must send > > a Success or Failure. But maybe I'm just confused > > by what "m.buildSuccFail" means since I haven't > > read the passthrough part of the document yet. > > m.buildSuccFail actually just takes the Success/Failure packet > from the Access-Accept/Reject message. Maybe we should rename it > to something more understandable (m.getSuccFail) or at least > document it better... > > > 5) Similarly, I'm not sure the state machine prevents > > the sending of a canned Success. These seem to be > > forbidden by 2284bis Section 4.2. > > You're right, it does not prevent this: if Policy.isSatisfied() > always returns TRUE, the authenticator just sends a "canned" > EAP Success packet. > This is interesting. Policy.update decides if the method succeeds/fails/etc. Perhaps a policy variable that is initialized nul or false should be set that prohibits creating a canned Success or Failure if no method has been called. > (There are other things Policy shouldn't do, e.g. sequences, > contradict method-specific result indications, etc.) > > > 6) Should there be initializations of all variables > > in the DISABLED and BACKEND_DISABLED states? Variables > > such as eapFail do not appear to get an initial > > value, at least not in the diagram. The text says > > it is initialized by the lower layer, but why? Wouldn't > > it be easier to treat this variable as an EAP layer > > variable which is only read by the lower layer, not set? > > I just checked 802.1aa/D6.1, and they certainly don't initialize > the variables... I guess there are two possible solutions: > > - Add statement saying "All boolean variables are initialized > to FALSE before the state machine execution begins." > I would really prefer this option. > me too. > - If variables have undetermined values before they are assigned, > then we need a lot of initializations. The problem is that > e.g. eapFail has to be initialized in lower layer, because > otherwise we get synchronization issues (the lower layer > could read it before the initialization block in EAP state > machine has been executed). Figuring out what goes where > is a lot of work.. > > I guess this should be checked with the 802.1aa folks as well. > (John, are you reading this?) > I will check with Paul and Jim on this. > > 7) Section 5.1.1 s/outside/Outside/ > > OK. > > > 8) Section 5.2 indentation looks funny. > > I agree. > > > 9) Can you explain why BACKEND_DISABLED and DISABLED > > have to be separate states? It looks like they > > could be combined, and the EapBackend variable > > could be checked before branching on to the next > > states. But perhaps this has something to do with > > the IEEE lower layer state machine interface? > > They could be combined (and were combined in an earlier version), > but we thought it's easier to read this way. > > > 10) Why not use the same substructure in 5.2 as is used > > in 5.1? Variables from method->eap layer, eap layer-> > > method, etc. Then you could also group 5.4 contents into > > its appropriate place in 5.1/5.2/5.3. > > Most of 5.2 is just descriptive text, which is more difficult to > group. Also, the interface to the lower layer is quite well-defined, > but the interface to methods isn't that clear (or another way to put > it would be that "many difficult details are hidden in Policy > calls"). > true :) > Then your next message: > > Jari Arkko wrote (24.6.): > > > > Additional comments on the state machine draft version 03 > > (http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-03.ps). > > Overall, I like the way that you have represented the passthrough > > and direct/AAA authenticators. The separation of the state machines > > to small pieces in nicely organized layers is very good design -- > > thanks! > > > > I do have some comments, though: > > > > 1) In the overview figure in Section 6.2, if I have understood > > correctly the two authenticator state machines have been > > instantiated with a different EapBackend value. Perhaps > > this could be shown in the figure. > > OK. > > > 2) It would be very useful to have the same kind of > > variable and interface descriptions following the passthrough > > and backend state machines as were given for the authenticator. > > Agreed. Will be added. > > > 3) I don't understand why Policy.update needs to be called > > in the AAA_FAILURE state of the passthrough state machine. > > If this happen, we fail completely, right? > > Yes, we fail, but before the authenticator state machine reaches > the FAILURE state, it calls Policy.isSatisfied() and > Policy.getNextMethod(). The Policy.update call just informs > the policy so it knows to return the correct values (FALSE and NONE). > > > 4) Similarly, I'm not sure I understand what the policy updates > > do in AAA_REJECT and AAA_ACCEPT. Can you clarify? > > Same as above. > > > 5) In state AAA_REQUEST, maybe change > > if (isIdentity(eapRespData)) > > to > > if (respId == currentId) > > unless I'm missing something... > > Here "identity" actually refers to contents of Identity Response, > not ID number field. (Yes, you're right, we need a list of > variables/procedures for these :-) > > > 6) The passthrough state machine does not appear to contain > > all processing required by RFC 2869bis. For instance, > > Section 2.6.3 about conflicting messages is not described. > > This may be fine, but at least there should be an > > explanation of the scope of the state machine. > > I think the backend authenticator+adapter can't ever send conflicting > messages (EAP Success inside Access-Reject or vice versa). Do you > think the pass-through authenticator+forwarder needs something > special for this? > seems like it might be possible but would be an error by a method? Perhaps I am missing something? > > 7) References need to be split to normative and non-normative. > > I'd say 2284bis and 2869bis are normative along with RFC 2119. > > IEEE is non-normative. > > Ok (but see below; we might want to make IEEE normative). > I am not sure what normative means, but I like IEEE being normative if possible. > > > > 8) Are these all references? I suspect at least the keying > > framework needs to be referenced. > > Yes, we actually mention the keying framework in the text, > so we should add a reference. > > > 9) The format used for describing the state machine and > > the actions. Do you have a possibility for feeding this > > into a state machine tool for analysis? > > > > Also, http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt > > mentions that you can use languages such as C. However, the IESG > > statement said that it must be clear whether you just use > > some pseudo code that just looks like C or the language itself. > > I think we have the former case. This should be stated. > > > > Finally, the IESG statement requires a normative reference > > to the used language or format. In this case I don't think > > we have it, or? If not, maybe we should be more strict in > > defining the language used for the actions, say with BNF, > > including semantics defined in English? > > No, we don't have any analysis tool for this (also, it's not clear > what results any tool could give for these diagrams alone?). > > The pseudocode is defined in 802.1X-2001 Maybe we should just add > a normative reference there, and remove Section 3.1 (so we don't > have to copy the pseudo-code definition as well)? > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Thu Jun 26 22:04:03 2003 From: aboba@internaut.com (Bernard Aboba) Date: Thu, 26 Jun 2003 14:04:03 -0700 (PDT) Subject: [eap] Strawman Agenda for EAP WG at IETF 57 Message-ID: Find enclosed a strawman agenda for the EAP WG meetings at IETF 57. Additions/corrections welcome. Extensible Authentication Protocol WG (eap) CHAIR: Bernard Aboba Jari Arkko AGENDA: Monday, July 14 at 1530-1730 =============================== Preliminaries (20 minutes) Bluesheets Minute Takers Agenda Bash Document Status Liason Statements RFC 2284bis (20 minutes), Henrik Levkowetz http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt EAP State Machine (20 minutes), Pasi Eronen http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-03.txt EAP Compound Binding (20 minutes), Jose Puthenkulam http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-02.txt Methods EAP SIM (10 minutes), J. Salowey http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-10.txt EAP AKA (10 minutes), J. Arkko http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-09.txt EAP SIM Security Analysis (20 minutes), Sarvar Patel http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf Thursday, July 17 at 1300-1500 =============================== EAP Client Side Transport (10 minutes), B. Boursetty http://www.ietf.org/internet-drafts/draft-boursetty-eap-cst-00.txt EAP Keying Framework (30 minutes), Bernard Aboba http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-07.txt Use of EAP Keying for DHCP Bootstrap (10 minutes), H. Tschofenig http://www.ietf.org/internet-drafts/draft-tschofenig-pana-bootstrap-rfc3118-00.txt Methods (cont'd) EAP LDAP (10 minutes), H. Mancini http://www.drizzle.com/~aboba/EAP/draft-mancini-pppext-eap-ldap-00.txt EAP Support in Smartcard (10 minutes), P. Urien http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-01.txt http://www.ietf.org/internet-drafts/draft-urien-eap-ssc-00.txt PEAP Version 2 (10 minutes), Ashwin Palekar http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-06.txt EAP Archie (10 minutes), Jesse Walker http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-01.txt From simon@instant802.com Fri Jun 27 22:57:29 2003 From: simon@instant802.com (Simon Barber) Date: Fri, 27 Jun 2003 14:57:29 -0700 Subject: [eap] Re: AUP Message-ID: Under the 802.11 1999 standard the user can send the EAPoL-Start to the AP before authentication or association. (Data frames sent from a client to an AP - and not further on to the distribution system are class 1 frames and can be sent at any time including before association). Does anyone have any idea how many clients and APs support this correctly? Perhaps it should be added to the Wi-Fi tests. Simon -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: Thursday, June 05, 2003 9:24 PM To: eap@frascone.com Subject: [eap] Re: AUP > >a) Since the AUP needs to be displayed regardless of the=20 > >authentication scheme chosen (open, WEP, WPA, RSN), it seems like=20 > >this needs to occur prior to EAP authentication. In the December 2002 > >NIST review, we recommended addition of an Information Element in the > >Beacon and Probe Response to handle this. > > Having done AUPs back at Chrysler in the mid-90s (and so I kick myself > on this too), it takes much more than a flag. I was thinking of an IE containing a string. Example: "This is a private network; if you are not authorized DISCONNECT NOW". The advantage of doing this in the Beacon or Probe Response is that the AUP gets to be communicated *before* the user attempts authentication. This is important because the act of attempted authentication itself can be construed as an attempted breakin. > >b) If it is desired to transmit a displayable message to the user,=20 > >the EAP-Request/Identity can be used for this purpose. > > This is how I see it. Either here or in the EAPoL-Start. Here it=20 > provides more functionality; AUP is then provided to all applications=20 > of EAP. Yes. With the limitation that the user may already have associated by the time the message is delivered. > Just some descriptive text about how to implement AUP in your EAP=20 > peers by its inclusion in the EAP-Req/Ident. Yes. We need some additional text anyway (to document existing usage of the EAP-Request/Identity field. I'll submit an issue. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From aboba@internaut.com Sat Jun 28 04:57:13 2003 From: aboba@internaut.com (Bernard Aboba) Date: Fri, 27 Jun 2003 20:57:13 -0700 (PDT) Subject: [eap] Re: AUP In-Reply-To: References: Message-ID: > Under the 802.11 1999 standard the user can send the EAPoL-Start to the > AP before authentication or association. Yes, this would be a class 1 frame sent in state 1. The state machine diagram talks about this being allowed. However, elsewhere in 802.11-1999 I believe that it talks about use of this with IBSS. My understanding is that class 1 data frames in state 1 are inconsistently supported today. It is something that might be worth a request for interpretation. From jari.arkko@piuha.net Sun Jun 29 08:45:05 2003 From: jari.arkko@piuha.net (Jari Arkko) Date: Sun, 29 Jun 2003 10:45:05 +0300 Subject: [eap] review of sm-03: authenticator In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BB44@esebe023.ntc.nokia.com> References: <052E0C61B69C3741AFA5FE88ACC775A608BB44@esebe023.ntc.nokia.com> Message-ID: <3EFE9901.1080208@piuha.net> Pasi.Eronen@nokia.com wrote: >>3) I'd rather not see a "..." in the calculateTimeout >> argument list. Can we be more specific? See also >> item 1 above. > > > 2284bis is quite vague on this. I guess we could specify > RFC2988 style behavior here: add two new variables > (eapSRTT, eapRTTVAR) that are set by the lower layer, > and give them to calculateTimeout. Would this be better? I wonder if it would be possible to leave all the vagueness in the "calculateTimeout" function, but specify the input to this function completely? >>4) I'm not sure if the m.buildSuccFail in the diagram >> (state METHOD) and 2284bis Section 4.2 requirements >> are aligned. The latter seems to require that after >> a method specific indication, we still must send >> a Success or Failure. But maybe I'm just confused >> by what "m.buildSuccFail" means since I haven't >> read the passthrough part of the document yet. > > > m.buildSuccFail actually just takes the Success/Failure packet > from the Access-Accept/Reject message. Maybe we should rename it > to something more understandable (m.getSuccFail) or at least > document it better... Ok. >>5) Similarly, I'm not sure the state machine prevents >> the sending of a canned Success. These seem to be >> forbidden by 2284bis Section 4.2. > > > You're right, it does not prevent this: if Policy.isSatisfied() > always returns TRUE, the authenticator just sends a "canned" > EAP Success packet. > > (There are other things Policy shouldn't do, e.g. sequences, > contradict method-specific result indications, etc.) I think there's two correct ways of handling this: either the 2284bis requirements are coded to the state machines (which may increase their size). Or we explicitly specify that the policy object must take care of the 2284bis requirements X, Y, and Z. > - Add statement saying "All boolean variables are initialized > to FALSE before the state machine execution begins." > I would really prefer this option. Ok. The nature of the variables should be made very clear in the document, it is OK for the lower layer to set a variable to FALSE and the higher layer to TRUE. So you may explain that initialization part also as something that happens at the lower layer. >>10) Why not use the same substructure in 5.2 as is used >> in 5.1? Variables from method->eap layer, eap layer-> >> method, etc. Then you could also group 5.4 contents into >> its appropriate place in 5.1/5.2/5.3. > > > Most of 5.2 is just descriptive text, which is more difficult to > group. Also, the interface to the lower layer is quite well-defined, > but the interface to methods isn't that clear (or another way to put > it would be that "many difficult details are hidden in Policy > calls"). I think its fine to have descriptive text. But I still think interface to the methods would be clearer, if you listed and classified all variables, constants, function calls.. and included the descriptive text. >>3) I don't understand why Policy.update needs to be called >> in the AAA_FAILURE state of the passthrough state machine. >> If this happen, we fail completely, right? > > > Yes, we fail, but before the authenticator state machine reaches > the FAILURE state, it calls Policy.isSatisfied() and > Policy.getNextMethod(). The Policy.update call just informs > the policy so it knows to return the correct values (FALSE and NONE). Ok. Maybe it would be better to have separate calls for the different aspects of policy, such as method selection and success/failure determination. >>5) In state AAA_REQUEST, maybe change >> if (isIdentity(eapRespData)) >> to >> if (respId == currentId) >> unless I'm missing something... > > > Here "identity" actually refers to contents of Identity Response, > not ID number field. (Yes, you're right, we need a list of > variables/procedures for these :-) Ok. >>6) The passthrough state machine does not appear to contain >> all processing required by RFC 2869bis. For instance, >> Section 2.6.3 about conflicting messages is not described. >> This may be fine, but at least there should be an >> explanation of the scope of the state machine. > > > I think the backend authenticator+adapter can't ever send conflicting > messages (EAP Success inside Access-Reject or vice versa). Do you > think the pass-through authenticator+forwarder needs something > special for this? I think so, because RFC 2869bis did not assume the backend always sent correct messages. It is true that put together, your state machine components will work flawlessly. But still, our protocol specifications are expected to work even with non-perfect components, and that's why 2869bis had such safety checks. > No, we don't have any analysis tool for this (also, it's not clear > what results any tool could give for these diagrams alone?). Yes, if we don't have a tool then I guess we can't do much about it. (A tool might reveal issues such as undefined variables, spelling errors, inconsistent formulas, missing events etc. even if it didn't "understand" the state machine in any deeper sense.) > The pseudocode is defined in 802.1X-2001 Maybe we should just add > a normative reference there, and remove Section 3.1 (so we don't > have to copy the pseudo-code definition as well)? Sounds good! --Jari From aboba@internaut.com Mon Jun 30 15:11:10 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 30 Jun 2003 07:11:10 -0700 (PDT) Subject: [eap] WIRE1x - free software of 802.1x supplicant] (fwd) Message-ID: ---------- Forwarded message ---------- Date: Mon, 30 Jun 2003 15:18:26 +0800 From: Yi-Wen Liu To: aaa@ietf.org Subject: [Aaa] WIRE1x - free software of 802.1x supplicant] We are pleased to announce the release of WIRE1x Version 0.1. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/ What is WIRE1x? The WIRE1x is an implementation of IEEE 802.1x client (supplicant) developed by the Wireless Internet Research & Engineering (WIRE) Lab. The IEEE 802.1x standard defines a port-based network access control to authenticate and authorize devices interconnected by various IEEE 802 LANs. IEEE 802.11i also incorporates 802.1x as its authentication solution for 802.11 wireless LANs. The implementation of WIRE1x is based on the Open1x. Open1x supports MacOS X, FreeBSD, OpenBSD, and Linux. Many users at National Tsing Hua University however are using MS Windows. They need a 802.1x client software to access to the campus wireless LANs. We therefore develop the WIRE1x to support various versions of MS Windows. Currently, the WIRE1x supports Windows XP (without service pack and with service pack 1) and Windows 2000. It provides EAP MD5-Challenge. It works with freeRADIUS. It now supports several WLAN cards including Avaya, 3com, PCI, and ZyXel cards. We will upgrade the program to support more WLAN cards, more authentication mechanisms, and more (especially earlier) versions of MS Windows. Both source code and executable code can be downloaded from http://wire.cs.nthu.edu.tw/wire1x/. From aboba@internaut.com Mon Jun 30 15:15:18 2003 From: aboba@internaut.com (Bernard Aboba) Date: Mon, 30 Jun 2003 07:15:18 -0700 (PDT) Subject: [eap] Strawman Agenda for EAP WG at IETF 57 In-Reply-To: References: Message-ID: > Perhaps we could fit the EAP SIM security analysis > discussion into a 20-minute slot on Monday, including > Sarvar's presentation and ours? Sure. This was on the agenda for Monday anyway.