Subject: [eap] Proposed Resolution of Issue 218...

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Feb 2004 22:58:00 -0800 (PST)

I went over the TLS handshakes again, and it turns out that TLS doesn't
really support protected result indications in either the client
authentication handshake or the resume handshake.

How about this?

"7.16 Protected Result Indications

Protected result indications address some denial-of-service
vulnerabilities with Success and Failure packets, which
are neither acknowledged nor integrity protected.
In addition, result indications provide additional immunity
against packet loss where EAP is run over lower layers which
support neither retransmission nor sychronization of the
authentication state, such as via a secure association
handshake [IEEE802.11i].

While result indications may enable synchronization of the authentication
result between the peer and server, this does not guarantee that the peer
and authenticator will be synchronized in terms of their authorization
or that timeouts will not occur.  For example, the EAP server may not
be aware of an authorization decision made by a AAA proxy; the AAA
server may check authorization only after authentication has
completed successfully, only to discover  that authorization
cannot be granted; or the AAA server may grant access
but the authenticator may be unable to provide it due to a temporary
lack of resources.  In these situations, synchronization may only be
achieved via lower layer result indications.

Protected result indications are not required to protect
against rogue authenticators.  Within a mutually authenticating
method, requiring that the server authenticate to the peer
before the peer will accept a Success packet prevents an
attacker from acting as a rogue authenticator.

However, it is possible for an attacker to forge a Success packet
after the server has authenticated to the peer, but before the
peer has authenticated to the server.  If the peer were to
accept the forged Success packet and attempt to access the
network when it had not yet successfully authenticated to
the server, denial of service attacks could be mounted against
the peer.  After such an attack, if the lower layer supports
failure indications, the authenticator can synchronize state
with the peer by providing a lower layer failure
indication. See Section 7.12 for details.

If a server were to authenticate the peer and send a Success packet
prior to determining whether the peer has authenticated the
authenticator, an idle timeout can occur if the authenticator is not
authenticated by the peer. Where supported by the lower layer, an
authenticator sensing the absence of the peer can free resources.

Result indications help avoid some of these issues. In a method supporting
result indications, a peer that has authenticated the server does not
consider the authentication successful until it receives an indication
that the server successfully authenticated it.  Similarly, a server
that has successfully authenticated the peer does not consider the
authentication successful until it receives an indication
that the peer has authenticated the server.

In order to avoid synchronization problems, prior to sending
a success result indication, it is desirable for the sender to
verify that sufficient authorization exists for granting access,
though as discussed below this is not always possible.

Success indications may be explicit or implicit.  For example, where a
method supports error messages, an implicit success indication may be
defined as the reception of a specific message without a preceding error
message.

Failures are typically indicated explicitly.  As described in Section 4.2,
a peer silently discards a Failure packet received at a point where  the
method does not explicitly permit this to be sent. For example, a method
providing its own error messages might require the peer to receive an
an error message prior to accepting a Failure packet.

Per-packet authentication, integrity and replay protection of result
indications protects against spoofing.  Since protected result
indications require use of a key for per-packet authentication and
integrity protection, methods supporting protected result indications MUST
also support the "key derivation", "mutual authentication" "integrity
protection" and "replay protection" claims.

EAP methods can typically provide protected result indications only
in some circumstances.  For example, errors can occur prior to key
derivation, and so it may not be possible to protect all failure
indications.  It is also possible that result indications may
not be supported in both directions or that synchronization may
not be achieved in all modes of operation.

For example, within EAP-TLS [RFC2716],  in the client
authentication handshake the server authenticates the
peer, but does not receive a protected indication of whether the peer
has authenticated it.  In contrast,  the peer authenticates the server and
is aware of whether the server has authenticated it.  In the session
resumption handshake, the peer authenticates the server, but does
not receive a protected indication of whether the server has
authenticated it.  In this mode, the server authenticates the peer and
is aware of whether the peer has authenticated it."

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 Feb 2004 16:35:27 +0200

> authentication handshake or the resume handshake.

Uh oh...

> In addition, result indications provide additional immunity

s/immunity/protection/

> is aware of whether the peer has authenticated it."

The text is fine. But I have a higher-level question to you, given
the many things we learned about EAP-TLS and the different aspects
of PRIs in general. Are we still happy having the feature listed
in 2284bis?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Feb 2004 07:54:21 -0800 (PST)

> of PRIs in general. Are we still happy having the feature listed

PRIs do provide some minor DoS protection.  The lion's share of
responsibility for DoS resilience still remains with the method, though.
Perhaps 7.16 could make this more clear.

There probably are some media in which PRIs might provide useful
functionality, but 802.11 isn't one of them.  For example, without
retransmissions or a 4-way handshake, the protection against packet loss
might come in handy. But 802.11 already has that so PRIs add no value
there.

Overall, I'm concerned that the over-zealous may require PRIs as 802.11
did.  Perhaps the right answer is to propose movement of the PRI
definition to the terminology section, and take it out of security claims.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 Feb 2004 18:35:21 +0200

> definition to the terminology section, and take it out of security claims.

That would work for me. Others?

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 13 Feb 2004 08:45:01 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jari Arkko
> Sent: Friday, February 13, 2004 8:35 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] Proposed Resolution of Issue 218...
> 
> 
> Bernard Aboba wrote:
> >>The text is fine. But I have a higher-level question to 
> you, given the 
> >>many things we learned about EAP-TLS and the different 
> aspects of PRIs 
> >>in general. Are we still happy having the feature listed in 2284bis?
> > 
> > 
> > responsibility for DoS resilience still remains with the method, 
> > though. Perhaps 7.16 could make this more clear.
> > 
> > retransmissions or a 4-way handshake, the protection against packet 
> > loss might come in handy. But 802.11 already has that so 
> PRIs add no 
> > value there.
> > 
> > Overall, I'm concerned that the over-zealous may require PRIs as 
> > 802.11 did.  Perhaps the right answer is to propose movement of the 
> > PRI definition to the terminology section, and take it out 
> of security 
> > claims.
> 
Me too.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Feb 2004 23:25:59 -0800

> >might come in handy. But 802.11 already has that so PRIs add no value

I think that retransmissions or a 4-way handshake does not really
compensate the lack of PRIs in EAP methods.  Without PRIs in EAP
methods, the EAP peer still relies on (unprotected)
EAP-Success/Failure to determine whether it can go forward to the next
step at the lower-layer (e.g., a 4-way handshake).  In IEEE 802.11i,
if the EAP peer receives an EAP-Failure that is sent by an attacker
before receiving an EAP-Success from the real authenticator, does the
supplicant accept the first EAPOL-Key message sent by the
authenticator?  If it accepts the EAPOK-Key message, what the received
EAP-Failure means?  If it does not accept the EAPOL-Key message, it
means that a DoS attack is successful.

> That would work for me. Others?

If my observation above is correct, the PRI definition should be in
security claims.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Feb 2004 11:00:39 -0800 (PST)

> step at the lower-layer (e.g., a 4-way handshake).

Actually, it is not necessary to implement PRIs as we have defined them to
get this protection.  The definition we have discussed required
synchronization of both sides;  however, addressing the spoofing problem
only requires the server to send a PRI, not the client.  This is made
clear in Section 4.2.

> In IEEE 802.11i,
> authenticator?

It depends on whether the EAP-Failure can be sent at that point in the
method or not.  A method might not provide synchronization, but that
doesn't mean it has to accept a Failure or Success sent at any point.
Hopefully this is made clear in Section 4.2 and 7.16.

> If it accepts the EAPOK-Key message, what the received

It could silently discard the Failure without having to implement PRIs.
As an example, it is possible that a method supports sending a PRI from server
to client, but not from client to server.  This would not meet the
definition of PRIs we have discussed, but it would protect against
spoofing of Failure packets.

> If my observation above is correct, the PRI definition should be in

Right now, the definition requires support for *both* synchronization and
Success/Failure spoofing. The former is not required to ensure the latter.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Feb 2004 11:42:52 -0800 (PST)

How about the following clarifications?

7.16 Protected Result Indications

Protected result indications address some denial-of-service
vulnerabilities with Success and Failure packets, which
are neither acknowledged nor integrity protected.
In addition, result indications provide additional protection
against loss of Success and Failure packets where EAP is run
over lower layers which do not support retransmission or
synchronization of the authentication state, such as via a
secure association protocol [IEEE802.11i].

the server, a denial of service attack could be mounted against

To protect against forgery of Success or Failure packets, it is
necessary for a method to support protected result
indications sent by the server to the peer.  Supporting
protected result indications sent by the peer to the server
provides additional denial-of-service and synchronization
protection.

In a method supporting result indications sent in both directions,
a peer that has authenticated the server does not consider the
authentication successful until it receives an indication
that the server successfully authenticated it.  Similarly, a server
that has successfully authenticated the peer does not consider the
authentication successful until it receives an indication
that the peer has authenticated the server.

Success indications may be explicit or implicit.  For example, where a
method supports error messages, an implicit success indication may be
defined as the reception of a specific message without a preceding error
message. Failures are typically indicated explicitly.  As described in
Section 4.2, a peer silently discards a Failure packet received at a point
where  the method does not explicitly permit this to be sent. For example,
a method providing its own error messages might require the peer to
receive an error message prior to accepting a Failure packet.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Feb 2004 00:28:27 -0800

> only requires the server to send a PRI, not the client.  This is made

I would mention in this case that the client must have sent its PRI to
the server before the server sends its PRI to the client.  The
EAP-Response sent in response to the server PRI serves as an
acknowledgment for the PRI and no other message (including a NAK) is
allowed to be sent from the client.  I would also mention that an
acknowledgement for a PRI does not need to be protected unless it
carries additional information that can change the receiver's behavior
some other way.

> Hopefully this is made clear in Section 4.2 and 7.16.

I would suggest having a clear distinction between a PRI and its
acknowledgment.  If we make such distinction, full authentication in
EAP-TLS provides PRI (session resumption case still does not
provide PRI, though.)

> Success/Failure spoofing. The former is not required to ensure the latter.

I believe that the former is required to ensure the latter.
Otherwise, the definition is not still clear.  I still think the PRI
definition should be in security claims.

Yoshihiro Ohba

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 13 Feb 2004 12:28:10 -0800

> On Behalf Of Bernard Aboba
> Sent: Friday, February 13, 2004 11:01 AM
> To: Yoshihiro Ohba
> Cc: Jari Arkko; [email-masked]
> Actually, it is not necessary to implement PRIs as we have 
> defined them to get this protection.  The definition we have 
> discussed required synchronization of both sides;  however, 
> addressing the spoofing problem only requires the server to 
> send a PRI, not the client.  This is made clear in Section 4.2.
> 
PRI is independent of state synchronization.  It is possible in a poorly
designed method to have PRI and fail to synchronize state.

> It depends on whether the EAP-Failure can be sent at that 
> point in the method or not.  A method might not provide 
> synchronization, but that doesn't mean it has to accept a 
> Failure or Success sent at any point. Hopefully this is made 
> clear in Section 4.2 and 7.16.
> 
> > If it accepts the EAPOK-Key message, what the received EAP-Failure 
> > means?  If it does not accept the EAPOL-Key message, it 
> means that a 
> It could silently discard the Failure without having to 
> implement PRIs. As an example, it is possible that a method 
> supports sending a PRI from server to client, but not from 
> client to server.  This would not meet the definition of PRIs 
> we have discussed, but it would protect against spoofing of 
> Failure packets.
> 
> Right now, the definition requires support for *both* 
> synchronization and Success/Failure spoofing. The former is 
> not required to ensure the latter.

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 13 Feb 2004 12:30:35 -0800

> Sent: Friday, February 13, 2004 11:43 AM
> To: Yoshihiro Ohba
> Cc: [email-masked]
> vulnerabilities with Success and Failure packets, which are 
> neither acknowledged nor integrity protected. In addition, 
> result indications provide additional protection against loss 
> of Success and Failure packets where EAP is run over lower 
> layers which do not support retransmission or synchronization 
> of the authentication state, such as via a secure association 
> protocol [IEEE802.11i].
> 
> against rogue authenticators.  Within a mutually 
> authenticating method, requiring that the server authenticate 
> to the peer before the peer will accept a Success packet 
> prevents an attacker from acting as a rogue authenticator.
> 
> However, it is possible for an attacker to forge a Success 
> packet after the server has authenticated to the peer, but 
> before the peer has authenticated to the server.  If the peer 
> were to accept the forged Success packet and attempt to 
> access the network when it had not yet successfully 
> authenticated to the server, a denial of service attack could 
> be mounted against the peer.  After such an attack, if the 
> lower layer supports failure indications, the authenticator 
> can synchronize state with the peer by providing a lower 
> layer failure indication. See Section 7.12 for details.
> 
> To protect against forgery of Success or Failure packets, it 
> is necessary for a method to support protected result 
> provides additional denial-of-service and synchronization protection.
> 
[Joe] I think we need to make sure we agree what synchronization means
in this context.  This is not the same as the synchronization of state
discussed on the 802.11 req thread.  Protected result indications do not
necessarily gaurantee this. 

> If a server were to authenticate the peer and send a Success 
> packet prior to determining whether the peer has 
> authenticated the authenticator, an idle timeout can occur if 
> the authenticator is not authenticated by the peer.  Where 
> supported by the lower layer, an authenticator sensing the 
> absence of the peer can free resources.
> 
[Joe] It is also possible for a lower layer to provide protection of the
sueccess packet.

> In a method supporting result indications sent in both 
> directions, a peer that has authenticated the server does not 
> consider the authentication successful until it receives an 
> indication that the server successfully authenticated it.  
> Similarly, a server that has successfully authenticated the 
> peer does not consider the authentication successful until it 
> receives an indication that the peer has authenticated the server.
> 
> a success result indication, it is desirable for the sender 
> to verify that sufficient authorization exists for granting 
> access, though as discussed below this is not always possible.
> 
> While result indications may enable synchronization of the 
> authentication result between the peer and server, this does 
> not guarantee that the peer and authenticator will be 
> synchronized in terms of their authorization or that timeouts 
> will not occur.  For example, the EAP server may not be aware 
> of an authorization decision made by a AAA proxy; the AAA 
> cannot be granted; or the AAA server may grant access but the 
> authenticator may be unable to provide it due to a temporary 
> lack of resources.  In these situations, synchronization may 
> only be achieved via lower layer result indications.
> 
> Success indications may be explicit or implicit.  For 
> example, where a method supports error messages, an implicit 
> success indication may be defined as the reception of a 
> specific message without a preceding error message. Failures 
> are typically indicated explicitly.  As described in Section 
> 4.2, a peer silently discards a Failure packet received at a 
> point where  the method does not explicitly permit this to be 
> sent. For example, a method providing its own error messages 
> might require the peer to receive an error message prior to 
> accepting a Failure packet.
> 
> Per-packet authentication, integrity and replay protection of 
> result indications protects against spoofing.  Since 
> protected result indications require use of a key for 
> per-packet authentication and integrity protection, methods 
> supporting protected result indications MUST also support the 
> "key derivation", "mutual authentication" "integrity 
> EAP methods can typically provide protected result 
> indications only in some circumstances.  For example, errors 
> can occur prior to key derivation, and so it may not be 
> possible to protect all failure indications.  It is also 
> possible that result indications may not be supported in both 
> directions or that synchronization may not be achieved in all 
> modes of operation.
> 
[Joe] The use of the word synchronization may not be what you want to
use here, can we replace it with result indicators in both cases?

> authentication handshake the server authenticates the peer, 
> but does not receive a protected indication of whether the 
> peer has authenticated it.  In contrast,  the peer 
> authenticates the server and is aware of whether the server 
> has authenticated it.  In the session resumption handshake, 
> the peer authenticates the server, but does not receive a 
> protected indication of whether the server has authenticated 
> it.  In this mode, the server authenticates the peer and is 
> aware of whether the peer has authenticated it."

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Feb 2004 01:20:58 -0800

> designed method to have PRI and fail to synchronize state.

I agree.  If we make a dintinction between PRI and its acknowledgment,
we can say that EAP-TLS full authentication provides PRIs but it is
still possible to fail to synchronize state.  For example, if an
attacker sends (unprotected) EAP-Response/EAP-TLS with an empty
payload as an acknowledgemnt for a server TLS finished message, and if
the server TLS finished message is unfortunately lost while the server
receives the acknowledgment, then synchronization between EAP peer and
server will be lost.

On the other hand, I think *protected* state synchronization (after
establishment of an MK, of course) can cover PRI in the sense that
acknowledment for PRI is also protected.

Yoshihiro Ohba

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 13 Feb 2004 16:52:18 -0800

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Friday, February 13, 2004 1:21 AM
> To: Joseph Salowey
> Cc: 'Bernard Aboba'; 'Yoshihiro Ohba'; 'Jari Arkko'; [email-masked]
> > PRI is independent of state synchronization.  It is possible in a 
> > poorly designed method to have PRI and fail to synchronize state.
> 
> I agree.  If we make a dintinction between PRI and its 
> acknowledgment, we can say that EAP-TLS full authentication 
> provides PRIs but it is still possible to fail to synchronize 
> state.  For example, if an attacker sends (unprotected) 
> EAP-Response/EAP-TLS with an empty payload as an 
> acknowledgemnt for a server TLS finished message, and if the 
> server TLS finished message is unfortunately lost while the 
> server receives the acknowledgment, then synchronization 
> between EAP peer and server will be lost.
> 

[Joe] I believe syncrhonization of state is a different concept than
what you describe.  Synchronization of state means that both peer and
server have the same notion of internal state (authenticated identities,
versions, crypto params etc.).  If the two parties do not share the same
notion then the protocol must fail to produce useful key material which
will cause subsequent lower layer communication to fail.

Protected result indicators is targetted at a different problem that has
more to do with DOS.  I believe this problem is better handled at a
lower layer. The lower layer can synchronize the use of encryption keys,
authorization and access which are outside of EAP. 

These two problems are separate and it is possible to solve one without
solving the other.

> On the other hand, I think *protected* state synchronization 
> (after establishment of an MK, of course) can cover PRI in 
> the sense that acknowledment for PRI is also protected.
> 
> Yoshihiro Ohba
> 
> 
> 
> > 
> > 
> > > > In IEEE 802.11i,
> EAP-Failure
> > > > If my observation above is correct, the PRI definition 
> should be 
> > > > in
> > > > security claims.
> > > 
> > > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
> > > 
> > 
> > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
>

---

From: Jari Arkko <[email-masked]>
Date: Sat, 14 Feb 2004 02:58:24 +0200

> means that a DoS attack is successful.

I agree with the above, but I also agree with Joe that this type
of protection is better handled at a lower layer. As you know,
PANA, for instance, can provide some protection of the Success
packets.

And you could consider the 4-way handshake one form of such
protection. The good thing about the protection from the lower
layer is that you actually know the whole story, e.g., what
AAA proxies have decided. Lower layer may not be able to
provide protection for a Failure, but OTOH such protection is
generally not possible in EAP layer either. Or at least it
is limited to authz, not auth failures.

--jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 14 Feb 2004 02:58:33 +0200

This is a friendly reminder that the I-D submission deadline is
near, and if we want to get RFC2284bis approved soon, we need
to submit it by sunday evening or thereabouts.

So lets try to close this one as soon as possible...

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Feb 2004 17:35:51 -0800

> will cause subsequent lower layer communication to fail.

I don't understand how your notion of synchronization of state is
different from my example above.  In the above example, the peer and
the server clearly fail to have the same notion of internal state,
i.e., the server thinks that the method completes successfully while
the peer is waiting for the server PRI until it times out...

> These two problems are separate and it is possible to solve one without

This is true.  State synchronization does not require PRI, and PRI
does not require state synchronization.  However, state
synchronization is generally required for any protocol to work at
least when there is no attack, and thus not a particular issue for
RFC2284bis.  On the other hand, I believe *protected* synchronization
is more than (unprotected) state synchronization and hard to provide.
But once it is provided, it covers PRI.  This is my analysis of the
discussion.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Feb 2004 17:52:01 -0800

> is limited to authz, not auth failures.

It is true that neither PRI nor protected state synchronization in EAP
methods solves the problem with AAA proxy.  Lower-layer should do
something to deal with the AAA proxy case.  However, this does not
mean PRI and protected state synchronization are useless.  It seems to
me that protected state synchronization in EAP method is as important
as protected state synchronization at lower-layer.  For example, yes,
PANA does provide some protection of the Success packets, but it is
possible that PANA does not even reach some state to receive a
protected Success packet if the EAP method fails to synchronize state
due to some spoofed EAP message sent from an off-path attacker.

On the other hand, I come to think that PRI is less useful than
protected state synchronization.  Thus I now agree with removing PRI
from security claims.  In addition, protected state synchronization is
hard to provide (perhaps IKE-class security is needed), and it is even
difficult to have a clear definition on protected state
synchronization at this time of moment of before I-D submission
deadline, so I would not request to add protected state
synchronization in security claims either.

Yoshihiro Ohba

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 13 Feb 2004 19:32:33 -0800 (PST)

> from security claims.

OK.  Here is a modified proposed resolution of Issue 218, taking this into
account:

Delete the definition of "Protected Result Indications" from Section
7.2.1.

Add the following definition to Section 1.2:

"Result indications
       A method provides result indications if after the
       method's last message is sent and received:

       1) The peer is aware of whether it has authenticated the
          server, as well as whether the server has authenticated it.

       2) The server is aware of whether it has authenticated the
          peer, as well as whether the peer has authenticated it.

In the case where successful authentication is sufficient
to authorize access then the peer and authenticator will
also know if the other party is willing to provide or
accept access. This may not always be the case. An
authenticated peer may be denied access due to lack of
authorization (e.g. session limit) or other reasons. Since
the EAP exchange is run between the peer and the server,
other nodes (such as AAA proxies) may also affect the
authorization decision. This is discussed in more detail
in Section 7.16."

Change Section 7.16 to:

Within EAP, Success and Failure packets are neither
acknowledged nor integrity protected.  Result indications
improve resilience to loss of Success and Failure packets
where EAP is run over lower layers which do not support
retransmission or synchronization of the authentication
state, such as via a secure association protocol [IEEE802.11i].

Depending on the method and circumstances, result
indications can be spoofable by an attacker.  A method is
said to provide protected result indications if it supports
result indications as well as the "integrity protection"
and "replay protection" claims.  A method supporting
protected result indications MUST indicate which
result indications are protected, and which are not.

In a method supporting result indications,

Protected result indications address some denial-of-service
vulnerabilities due to spoofing of Success and Failure
packets, though not all. EAP methods can typically provide
protected result indications only in some circumstances.
For example, errors can occur prior to key derivation, and
so it may not be possible to protect all failure
indications. It is also possible that result indications may
not be supported in both directions or that synchronization may
not be achieved in all modes of operation.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 13 Feb 2004 18:46:36 -0800

I am fine with the entire text.

Thanks very much.

Yoshihiro Ohba

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 14 Feb 2004 16:22:56 +0100

In the most recently proposed text:

> state, such as via a secure association protocol [IEEE802.11i].

The last 3 lines here can give the impression that all secure
association protocols have the characteristic that they do not support
retransmission or synchronization of authentication state.  Maybe change
"via a secure" to "via the IEEE 802.11i secure"?

	Henrik

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 14 Feb 2004 08:43:56 -0800 (PST)

How about this?

Within EAP, Success and Failure packets are neither
acknowledged nor integrity protected.  Result indications
improve resilience to loss of Success and Failure packets
when EAP is run over lower layers which do not support
retransmission or synchronization of the authentication
state.  In media such as IEEE 802.11, which provides
for retransmission, as well as synchronization of
authentication state via the 4-way handshake defined
in [IEEE802.11i], additional resilience is typically of
marginal benefit.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sat, 14 Feb 2004 18:36:32 +0200

> in [IEEE802.11i], additional resilience is typically of

Ok.

I'm now happy with all the proposed resolutions of the
issues we had.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 14 Feb 2004 08:59:35 -0800 (PST)

> I'm now happy with all the proposed resolutions of the

Excellent.  I think we are now ready to submit an RFC 2284bis-08
reflecting these resolutions.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 14 Feb 2004 22:02:23 +0100

> in [IEEE802.11i], additional resilience is typically of

Looks good, works for me.

	Henrik