1. Symbolic Simulation of Tunneling Protocols Carl A. Gunter, Matthew Jacobs, Gaurav Shah, Mark-Oliver Stehr (UIUC), and Alwyn Goodloe Alwyn Goodloe HCES 2004

2. Overview Motivating problem from wireless security. Solution by composing secure tunnels. Software engineering and modeling. Future plans.

3. Wireless Security Why is wireless security any different from wired security? Resource constraints. Resource constraints. Increased risk to confidentiality. Increased risk to confidentiality. Value of the network link. Value of the network link.

4. Wireless Security Efforts Layer 1 (Physical) Spread spectrum Spread spectrum Layer 2 (Link) 802.11x – 802.11(b) WEP, 802.11(g) 802.11x – 802.11(b) WEP, 802.11(g) CDMA 2000 CDMA 2000 GPRS GPRS

5. GPRS

6. Network Layer Wireless Security We propose that security be addressed at the network layer. Advantages Independent of underlying link layer. Independent of underlying link layer. Overcomes many of the problems of layer 2 solutions. Overcomes many of the problems of layer 2 solutions. Leverages extensive experience, s/w, and h/w support from Ipsec for VPNs. Leverages extensive experience, s/w, and h/w support from Ipsec for VPNs.Disadvantage Need set up protocols. Need set up protocols.

7. Protocols for Tunnel Composition We have been investigating protocols for composing IPSec security tunnels. Given a scenario we ask: What tunnels should we establish What tunnels should we establish What properties should these tunnels have. What properties should these tunnels have. Develop protocols that compose these tunnels into a satisfactory solution. Lots of messy details to consider in order to get the composition to work. Lots of messy details to consider in order to get the composition to work.

8. Toward Network Layer Security Suppose we have three parties: client, server, network access server (NAS). The client wishes to securely access the server. We will assume that the client has a relationship with the NAS and the server, but the NAS does not have a relationship to the server. The Client will have to authenticate itself to both the NAS and the server. The Client will have to authenticate itself to both the NAS and the server.

9. Network Layer Wireless Security

10. Problem Similar problem to GPRS above. The NAS does not protect the client from attacking incoming traffic. Being forced to pay for service you never used is worse than denial of service.

11. How About a Firewall

12. Why Not a Firewall A stateful firewall can be programmed to allow only traffic from the address to which a connection has been made. The firewall can not see the contents of the IPSec traffic. Resulting in minimum protection.

13. L3A Protocol Principles The user’s traffic should travel in DOS resistant IPSec tunnels. These IPSec tunnels should be set up using DOS resistant protocols. The NAS should ensure that when the accounting system logs traffic as being from a user it is actually from that user. Authenticate incoming traffic. Authenticate incoming traffic.

14. L3A Architecture

15. L3A Protocol Components L3A protocol that sets up the six tunnels. SIKE Key Exchange protocol (X509 + DOS protection). Very simple. Does not use two party key generation. Very simple. Does not use two party key generation. No guarantee of perfect forward secrecy. No guarantee of perfect forward secrecy. Assumes existence of public key infrastructure. Assumes existence of public key infrastructure.

16. L3A Protocol Overview Client NAS Server

17. Key Exchange SIKE A B rA, SPI(n,0) rA,rB, SPI(n,m), certB, cookieA certA,cookieA, DA, Ps(a,DA) Where DA = [rA, IPB, SPI(n,m)] Where CookieA = VersionSecret | Hash([rA,rB,IPA, SPI(n,m)],Secret) DB, Ps(b,DB) Where DB = [rB, IPA, rA, SPI(n,m), Pe(A, K)]

18. Methodology An English language description resembling an IETF RFC is produced. A formal specification is written in Maude. Systems are modeled using membership equational logic and rewriting logic. Systems are modeled using membership equational logic and rewriting logic. Symbolic simulation has been our main debugging aid. We feel the design is now relatively stable. We feel the design is now relatively stable.

19. Maude Model of L3A Our Maude model seeks to apply good SE techniques to modeling the L3A protocol. Our Maude model seeks to apply good SE techniques to modeling the L3A protocol. Documentation and proper configuration control. Documentation and proper configuration control. Accent is on verifying design. Component interaction was our primary concern. Modeled the various components and layers. IP, IPSec, L3A, ….. IP, IPSec, L3A, ….. Symbolic simulation highlights the unexpected interactions.

20. Overview of Module Interaction L3A PKI SIKE IP SEC IP setkey

21. Security Assoc StateMessage IP SECSecurity Policy SIKE PKI L3A Abstract L3A L3a Test Abstract L3A Test Concrete SIKE Test IP Routing Table IP Message Setkey

22. Modeling Uncovered Problems Problems arose from interactions among the components. Numerous iterations were required to resolve problems resulting from when the IP Sec databases are updated. Numerous iterations were required to resolve problems resulting from when the IP Sec databases are updated. When things are not done right packets can slip into partially setup tunnels. When things are not done right packets can slip into partially setup tunnels.

23. We Didn’t Model Timeouts and resends. Lost Messages. Periodic updates to the secret used to generate the cookie. Fragmentation. Can be the source of DOS attacks. Can be the source of DOS attacks. UDP layer. Ports not mentioned at all in the model. Attacks. Formally verify SIKE/L3A. TBD.

24. Implementation Platform. X86 running FreeBSD. C, Python, and TLS crypto libraries. Radius server to be used for accounting. Radius server to be used for accounting. Will demonstrate that our protocol can be implemented using available technology. We will seek to validate the implementation against the Maude model. The protocol is very deterministic. The protocol is very deterministic. Should be able to match a run of the simulation against a run of the actual protocol modulo some specific field values. Should be able to match a run of the simulation against a run of the actual protocol modulo some specific field values. The process for less deterministic protocols is more challenging. The process for less deterministic protocols is more challenging.

25. Future Work Continue work on composition of security tunnels. Perform formal verification of SIKE. We assert that the composition of DOS resistant tunnels is DOS resistant. Existing formal methods lack the tools to reason about DOS. We plan on working toward filling this void in the formal methods toolkit.