Analysis of Industrial Protocols Cuellar, Tschofenig Siemens

1. Analysis of Industrial ProtocolsCuellar, TschofenigSiemens

2. GSM Context:Standardisation Committees for Internet Protocols W3C OMA html xml IETF HTTP TCP UDP IP 3GPP IEEE 802.11 They are all doing a good job, but ....

3. They need help • Even using perfect cryptographic algorithms • they may be used in insecure ways... • Errors in security are very costly: • Updates are costing hundreds of millions, e.g. WLAN/WEP • Other protocols are delayed by years, e.g. Mobile-IP, Geopriv • Eroding confidence in Internet Security and e-commerce • Security protocol design is very difficult, needs • abundance of caution, • experienced cryptographers and security protocol designers • and fast, scalable, and usableprotocol analysis tools! This is where AVISPA is making the difference

4. Project Objectives • Develop a rich specification language for formalising industrial strength security protocols and their properties. • Advance state-of-the-art analysis techniques to scale up to this complexity. • Develop the AVISPA tool based on these techniques. • Tune and assess the AVISPA tool on a large collection of practically relevant, industrial protocols. • Migrate this technology to developers and standardisation organisations.

5. Coverage of the AVISPA Protocol Candidates The IETF, IEEE, 3GPP, OMA etc. need tools that cover a wide range of protocols and security properties: • 11 different areas (in 33 groups) • 5 layers • 20+ security goals (as understood at IETF, 3GPP, OMA, etc)

6. Areas • Infrastructure (DHCP, DNS, BGP, stime) • Network Access (WLAN, Pana) • Mobility (Mobile IP, HIP, Seamoby) • VoIP, messaging, presence (SIP, ITU-T H530, impp, simple) • Internet Security (IKE, IKEv2, UMTS-AKA, TLS, Kerberos, EAP & EAP Methoden, OTP, Sacred, ssh, telnet,...) • Privacy (pseudonym agreement protocols) • AAA, Identity Management, Single Sign On (Liberty Alliance) • Security for QoS and NAT/FW signaling, etc. (NSIS) • Broadcast/Multicast Authentication (TESLA) • E-Commerce (Payment) • Perhaps: Secure Download, Content protection (DRM)

7. SET Kerberos TLS IPsec-IKE WLAN-Wep Layers Application impp impp Middleware SIP /http SIP /http tcp / udp tcp / udp Transport Layer ip ip Network Layer Ethernet Ethernet Data Link Layer Physical Layer Host Access Point, Gateway or Host

8. Security Goals • Authentication + Secrecy (unicast + multicast) • Peer Entity , Data Origin, Implicit Destination Authn, Replay Protection • Key Agreement Properties • Key authentication (implicit key authentication) • Key confirmation (Key Proof of Possession) • Fresh Key Derivation (key freshness) • “Anonymity” (aka passive user identity confidentiality) • Identity Protection against Eavesdroppers • Non-repudiation • Proof of Origin • Proof of Delivery All of them reduce to classical authentication + secrecy properties

9. Security Goals • Authentication + Secrecy (unicast + multicast) • Authorisation (by a Trusted Third Party) • Key Agreement Properties • Perfect Forward Secrecy (PFS) • Secure capabilities negotiation (Resistance against Downgrading and Negotiation Attacks) • “Anonymity” • Identity Protection against Peer • Non-repudiation • Proof of Origin • Proof of Delivery • “Accountability” • Limited DoS Resistance • Sender Invariance • Safety Temporal Property In some cases they reduce to classical authentication + secrecy properties, but other properties may also be necessary.

10. Security Goals • Authentication + Secrecy (unicast + multicast) • Authorisation (by a Trusted Third Party) • Key Agreement Properties • Perfect Forward Secrecy (PFS) • Secure capabilities negotiation (Resistance against Downgrading and Negotiation Attacks) • “Anonymity” • Identity Protection against Peer • Non-repudiation • Proof of Origin • Proof of Delivery • “Accountability” • Limited DoS Resistance • Sender Invariance • Safety Temporal Property • Session Formation • Consistent View (synchronization) • Key naming

11. Coverage of established IETF Security Specifications AVISPA covers 86% (24 of the 28) of the Security Protocols listed in RFC 2316,RFC 3631, Auth-mech (plus very current ones) Total of more than 90 protocols

12. New Problems offer new Challenges • Internet offers agent many identities • user, ip, mac, tcp port, ... What is “A”, “ID_A”? • Location of adversaries • over the air • “safer” routes • Many types of DoS attacks • flodding, bombing, starving, disrupting • New types of security goals • DoS • key control, perfect forward secrecy, ... • layered properties • if attacker <weak> then guarantee <DoS resilience+confidentiality+integrity+…> • if attacker <strong> then guarantee <at least confidentiality+integrity>

13. Conclusions • The standardisation organisations need us: • Avoid delays in the standardisation process • Avoid errors in deployed standards • Help to restore the trust on e-commerce, privacy • Automatic tools are needed • Fast evaluation of alternatives • Our candidates cover: • all 5 IP layers • most (11) IP Areas • almost all security goals • 86% of the “recommended” IETF security Protocols • further information on http://www.tschofenig.com/avispa/ • We still have many challenges ahead of us!