Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST Analysis of Industrial Protocols Cuellar, Tschofenig Siemens

1 AVISPAIETF - saagSeoul, March, 2004 Context: Standardisation Committees for Internet Protocols W3C IETF 3GPP IP TCPUDP htmlxml HTTP GSM OMA They are all doing a good job, but.... IEEE

2 AVISPAIETF - saagSeoul, March, 2004 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 usable protocol analysis tools! This is where AVISPA is making the difference

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

4 AVISPAIETF - saagSeoul, March, 2004 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)

5 AVISPAIETF - saagSeoul, March, 2004 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)

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

7 AVISPAIETF - saagSeoul, March, 2004 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

8 AVISPAIETF - saagSeoul, March, 2004 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.

9 AVISPAIETF - saagSeoul, March, 2004 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

10 AVISPAIETF - saagSeoul, March, 2004 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

11 AVISPAIETF - saagSeoul, March, 2004 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 then guarantee

12 AVISPAIETF - saagSeoul, March, 2004 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 We still have many challenges ahead of us!

13 AVISPAIETF - saagSeoul, March, 2004 Verification has been used already in Standardization H.530 MS SNHE ADR ADS(AV 1,.. AV n ) UAR(chall) UAS(resp) LUR SynchronFailure UMTS-AKA