Subject: [eap] Re: issue 121: failed auth & succeeded authz?

From: [email-masked] ([email-masked])
Date: Mon, 2 Jun 2003 19:48:27 +0300

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: [email-masked] (Bernard Aboba)
Date: Mon, 2 Jun 2003 10:36:38 -0700 (PDT)

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.

packet (and MUST NOT silently discard either of them). In the event that
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: [email-masked] (Jari Arkko)
Date: Mon, 02 Jun 2003 21:35:47 +0300

> the final decision of the authenticator.

Ok.

> terminated (and any Success and Failure packets are silently

Ok. But shouldn't we mention mutual authentication failure in
the above?

> success indication, since it may be necessary to retransmit the last

Ok.

> disable the link to avoid lengthy timeouts in case the lost packet was

Ok.

> 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: [email-masked] (Bernard Aboba)
Date: Mon, 2 Jun 2003 11:15:09 -0700 (PDT)

> 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: [email-masked] (Joseph Salowey)
Date: Mon, 2 Jun 2003 11:42:12 -0700

> 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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Monday, June 02, 2003 10:37 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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.
> 
> 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 
> 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.
> 
> 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.
> 
> 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.
> 
> 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
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>