eap Mailing List: Protected Result Indications (again)

[Tschofenig Hannes (hannes.tschofenig]

Hi all, 

i took a look at 'protected result indication' mailing list discussion. you
seem to have discussed a number of issues: 

- Authorization failures
  It was raised that it is possible that authorization failure can be sent
although authentication was  successful. Typically, this message is
transmitted from the server to the peer. It might be good to have a  more
fine-grain differentiation between the different authorization failures.

- Synchronization problems
  Allowing the peer to observe whether the protocol run was successfully
verified at the server
  (or even vice versa)
  in some cases it might even be necessary to provide key confirmation to
ensure that the parties correctly  executed the protocol exchange. 

A specifical case of the synchronization problem could be caused with some
methods. If we would establish an  eap-sa which is used between the eap peer
and the eap server then "re-keying" issues would also play a role.  For some
EAP methods the eap-sa is simply deleted after the protocol exchange. 

- DoS attacks
  DoS attacks is a basically a broader category of the synchronization
problems. Synchronization problems can  also be caused by means which are
not attacks

In general, it is helpful to differentiate between different error cases.
Some error cases cannot be protected  and hence they should not be used to
take an action. This is not unique for EAP but can be observed in many
other protocols. 

Let us consider an eap method (which i am currently working on) based on ISO
Symmetric Key Two-Pass Mutual  Authentication. This discussion is more
focused on DoS protection rather than on an authorizatio failure. 

   EAP Peer                          EAP Server
   ========                          ==========

            <--- EAP-Request/EAP-Type=EAP-XXX
    (EAP server to EAP peer authentication+key establishment)


            EAP-Response/EAP-Type=EAP-XXX --->
    (EAP peer to EAP server authentication+key establishment)            
                                
            <--- EAP-Success/Failure

              Figure 1: Example protocol exchange

 
Now there are the following cases:

a) the EAP-Response message gets lost

in this case the EAP-Request message will be retransmitted. 

b) an adversary modifies the second message and injects a bogus
EAP-Success/Failure 

The EAP peer and the EAP server do not share a common view about the
protocol execution
in this case the EAP peer believes that the protocol was excuted

Please note that an EAP peer might not process the EAP-Success/Failure since
it is not protected. 

By "process" I mean that the message does not lead to an action since it is
an unreliable trigger. 

c) an adversary modifies the EAP-Success/Failure message

If the EAP peer does not process the message then it is difficult for the
peer to find out whether the server  was able to authenticate the peer. 

If the EAP peer processes the message (although it is not protected) then an
adversary might cause incorrect  actions to be triggered. an EAP-Success
might be modified into an EAP-Failure. 

            <--- EAP-Request/EAP-Type=EAP-XXX
    (EAP server to EAP peer authentication+key establishment)


            EAP-Response/EAP-Type=EAP-XXX --->
    (EAP peer to EAP server authentication+key establishment)            
                                

            <--- EAP-Request/EAP-Type=EAP-XXX
    (confirmation)


            EAP-Response/EAP-Type=EAP-XXX --->
    (dummy)            

            <--- EAP-Success/Failure

              Figure 2: Protected result indication (additional roundtrip)

A modified EAP-Success/Failure should not be considered since it provides no
value. the dummy message is  irrelevant and should not be taken into account
except as a reliability mechanism that the message was  processed. 
in some cases it is not possible to protect the confirmation message since
it also serves as an error message.  hence an adversary could forge this
message to indicate an error. it then sends a dummy message to the server
and gets an EAP-Success/Failure message in response. the state between the
EAP server and the peer is  out-of-synch.

The same effect can be caused by using a 'regular authenticated' message
instead of the dummy message. If the  adversay modifies message #4 of Figure
2 then it could cause the server to believe that something is wrong.  

            <--- EAP-Request/EAP-Type=EAP-XXX
    (EAP server to EAP peer authentication+key establishment)


            EAP-Response/EAP-Type=EAP-XXX --->
    (EAP peer to EAP server authentication+key establishment)            
                                

            <--- Protected EAP-Success/Failure 

             Figure 3: Protected result indication (optimized)

The message flow described in Figure 2 can be optimized with the message
flow in Figure 3. 

            <--- EAP-Request/EAP-Type=EAP-XXX
    (EAP server to EAP peer authentication+key establishment)


            EAP-Response/EAP-Type=EAP-XXX --->
    (EAP peer to EAP server authentication+key establishment)            
                                

            <--- Protected EAP-Success/Failure (out-of-band; not the same
end points) 

           Figure 4: Protected result indication (out-of-band)

Instead of providing protection within the EAP method itself for the
EAP-Success/Failure message it is also  possible to protect the last (or a
few) EAP payloads based on the master session key carried from the EAP
server to the Authenticator. For example, PANA protects the final
EAP-Success/Failure message carried within  PANA. IKEv2, for example,
protects the entire EAP exchange and therefore also the EAP-Success/Failure
message. 

Please note that the end points of an out-of-band protection might not be
the same in all cases. In  particular, if the EAP server is not co-located
with the Authenticator which is typically the case. 

Whenever a failure case has to be handled it is possible that an adversary
injects an error message to make  the EAP peer to believe that something
went wrong. 

My conclusion from this is: 

DoS attacks are very hard (if not impossible) to prevent. 

To me the synchronization problems look very similar to the 'two army
problem'. you can find a brief  description at the following web page:
http://www.eeng.may.ie/~tward/transportl/sld027.htm

Furthermore, to describe the problem in more detail it is necessary to
consider the different error cases. In  which case is an error message
protected and what information about the error is forwarded to the EAP peer.

Particularly, Bernard seems to propose a mechanism for providing information
about authorization failures in a  protected fashion from the EAP server to
the EAP peer. 

Due to its messaging behavior EAP is already quite heavy. Hence, it does not
seem to be good to add yet  another roundtrip. 

ciao
hannes

I would like to thank Dirk and Yoshi for their patience discussing various
issues with me. 

btw, you can easily construct a dos attack with eap-archie. 

----- EAP-Archie


   EAP Peer                          EAP Server
   ========                          ==========
                                <--- EAP-Request/EAP-Type=Archie
                                      (AuthID | SessionID)
   EAP-Response/EAP-Type=Archie --->
    (SessionID | PeerID | NonceP |
     Binding | MAC1)            
                                <--- EAP-Request/EAP-Type=Archie
                                      (SessionID | NonceA | Binding |
                                        MAC2)
   EAP-Response/EAP-Type=Archie --->
    (SessionID | MAC3)

            Figure 5.  The EAP-Archie Message Flow


assume that an adversary modified or dropped the last message. it does not
matter whether the EAP peer  "trusts" an eap success message (injected by
the adversary) or not. with message (4) the EAP peer believes  that the
protocol exchange was successfully finished. The EAP server, however, will
fail to correctly process  the message and will not ship the session key to
the Authenticator (via the AAA infrastructure).