1. Security Vulnerabilities in Protocols
Dr. Greg Shannon
Security Standards Manager
Lucent Technologies

2. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
Thesis
Standards bodies have a unique ability and responsibility to address security vulnerabilities in protocols.
There are immediate and relatively simple actions standards bodies can take to improve the security of all protocols currently being standardized.
ITU-T Workshop on Security - Seoul (Korea), May 2002

3. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
Outline
Security Vulnerability Basics
Types & Examples of Security Vulnerabilities in Protocols
Recommendations for Standards Bodies
ITU-T Workshop on Security - Seoul (Korea), May 2002

4. What Is a Security Vulnerability?
A security vulnerability is: A flaw or weakness in a system’s design, implementation or operation that could be exploited to violate the system’s security (RFC 2828).
A security vulnerability is not: a risk, a threat, or an attack.
ITU-T Workshop on Security - Seoul (Korea), May 2002

5. Vulnerabilities, Threats and Risks
A security vulnerability combined with a security threat creates a security risk.
Vulnerability + Threat  Risk
Example:
Overflow Bug
+ Hacker Knowledge & Tools & Access
 Risk of Webserver Attack
ITU-T Workshop on Security - Seoul (Korea), May 2002

6. The High-Impact of Protocol Security Vulnerabilities
Threats change, but security vulnerabilities exist throughout the life of a protocol.
With standardized protocols, protocol-based security risks can be very large – global in scale.
ITU-T Workshop on Security - Seoul (Korea), May 2002

7. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
Outline
Security Vulnerability Basics
Types & Examples of Security Vulnerabilities in Protocols
Recommendations for Standards Bodies
ITU-T Workshop on Security - Seoul (Korea), May 2002

8. Protocol Security Vulnerability Types
Threat Model
New threats from those originally considered.
SS7
Design & Specification
Errors make the protocol inherently vulnerable.
BGP
Implementations
Errors create unexpected vulnerabilities.
SNMP, ASN.1, BER
Usage & Configuration
Improper usage opens or magnifies security vulnerabilities.
802.11b, BGP
ITU-T Workshop on Security - Seoul (Korea), May 2002

9. A Simple Protocol Vulnerability Model
Security
Vulnerabilities
Security
Threats
Security
Risks
Hackers
Insiders
Terrorists
Vandals
Organized crime
State sponsored
Data loss
Data corruption
Privacy loss
Fraud
Down-time
Public loss of confidence
Confusion
Threat Model + 
Design & Specification
Implementation
Operations & Configuration
ITU-T Workshop on Security - Seoul (Korea), May 2002

10. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
New Threat Model SS7
Old Model
Designed for a closed network of well-known service providers of fixed services.
No interface to IP-based networks.
Software extensively tested.
New Model
Rogue providers may be malicious.
Software and protocols for new services may be poorly tested or a poor fit with SS7.
Network convergence puts IP interfaces on SS7-capable elements.
ITU-T Workshop on Security - Seoul (Korea), May 2002

11. Design & Specification Errors BGP (RFC1771)
Design implies an ASN of 0 is illegal.
Specification allows 0 (and 65535).
What happens when an ASN of 0 is advertised?
Different implementations probably handle this differently.
Such protocol inconsistencies are at the root of many attacks on specific implementations.
ITU-T Workshop on Security - Seoul (Korea), May 2002

12. Implementation Errors SNMP, ASN.1, BER
SNMP security depends on proper parsing of ASN.1 and BER.
Some ASN.1 and BER parsers are not robust and make mistakes or allow buffer overflows.
Limited specifics on SNMP error handling lead to unpredictable behaviors across implementations.
ITU-T Workshop on Security - Seoul (Korea), May 2002

13. Usage or Configuration Errors 802.11b, BGP
In b, a stream cipher is misused so that there is very little privacy protection.
802.11b operators often turn off even the basic security features.
BGP operators turn off the authentication mechanisms. Errors and rogue messages can then easily propagate through core networks.
ITU-T Workshop on Security - Seoul (Korea), May 2002

14. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
Lessons Learned
Standards bodies have accepted protocols with serious vulnerabilities.
Security depends on the whole protocol.
Protocol vulnerabilities last a long time.
Threats change over time.
Implicit assumptions are often violated.
Application layer protocols also have security vulnerabilities.
Inattention to security issues creates vulnerable protocols.
ITU-T Workshop on Security - Seoul (Korea), May 2002

15. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
Outline
Security Vulnerability Basics
Types & Examples of Security Vulnerabilities in Protocols
Recommendations for Standards Bodies
ITU-T Workshop on Security - Seoul (Korea), May 2002

16. Recommendations for Discussion
Openly discuss with security experts the security algorithms and mechanisms used in protocols.
Establish simple but effective security guidelines for protocol authors.
Initiate a systematic root-cause study of protocol vulnerabilities.
ITU-T Workshop on Security - Seoul (Korea), May 2002

17. Open Security Discussions
The security community has learned that two elements improve security:
Exposure of the details to a wide audience
Time to analyze and discuss the details.
Secrecy does not improve security.
Standards bodies should promote:
Open discussion of security algorithms and mechanisms.
Engagement with security experts on every standard.
ITU-T Workshop on Security - Seoul (Korea), May 2002

18. Security Guidelines for Protocol Authors
Early attention to security is best.
Guidelines provide a way to quickly improve the process.
Standards bodies should issue guidelines in four areas for all protocol authors:
Specify Threat Models
Protocol Designs & Specifications
Secure Implementation Issues
Operational & Configuration Issues
ITU-T Workshop on Security - Seoul (Korea), May 2002

19. Example Protocol Guidelines I
Threat Model
What is the initial model?
What are the security assumptions?
What is the trust model?
Design & Specification
Address unexpected messages.
Anticipate DoS attacks.
Limit data in debugging messages.
Fully specify state machines
ITU-T Workshop on Security - Seoul (Korea), May 2002

20. Example Protocol Guidelines II
Implementation
Fully specify error handling for malformed or unexpected messages.
Separate processing for signaling and traffic when possible.
Operations & Configuration
How robust is the protocol when all security features are turned off?
Provide guidelines to vendors and operators for new protocol versions.
ITU-T Workshop on Security - Seoul (Korea), May 2002

21. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
Root-Cause Analysis
Incident analysis usually focuses on threat reduction and prosecution.
The root cause(s) of an enabling vulnerability are usually not found.
Standards bodies should:
Systematically analyze the root causes of serious protocol vulnerabilities.
Understand how their decisions and processes produce security vulnerabilities.
ITU-T Workshop on Security - Seoul (Korea), May 2002

22. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
Summary
Security vulnerabilities in important protocols have created serious security risks that were avoidable.
Standards bodies should:
Promote open security discussions.
Provide protocol security guidelines.
Identify root causes of vulnerabilities.
ITU-T Workshop on Security - Seoul (Korea), May 2002

23. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
Contact Information Dr. Greg Shannon
Please contact me about:
Other work in this area
Further discussion of this material
Examples of protocol vulnerabilities
Phone:
Mail: 6100 East Broad Street, Columbus, Ohio, 43212, USA
ITU-T Workshop on Security - Seoul (Korea), May 2002

24. ITU-T Workshop on Security - Seoul (Korea), 13-14 May 2002
Acronyms & References
802.11b – IEEE Wireless Local Area Network Standard
BGP – Border Gateway Protocol Version
DoS - Denial of Service (attack)
IETF – Internet Engineering Task Force
IEEE - Institute of Electronic and Electrical Engineers
IP – Internet Protocol
MPLS – Multi-protocol Label Switching
SNMP – Simple Network Management Protocol
SS7 – Signaling System #7
IETF ID draft-rescorla-sec-cons-05.txt, Guidelines for Writing RFC Text on Security Considerations
IETF RFC #2828, Internet Security Glossary
Lorenz, Moore, Manes, Hale, Shenoi. “Securing SS7 Telecommunications Networks.” Proceedings of the 2001 IEEE Workshop on Information Assurance and Security.
Sharp. Principles of Protocol Design. Prentice Hall, 1995.
ITU-T Workshop on Security - Seoul (Korea), May 2002