Security Knowledge Should be Embedded Inside the Protocol RFCs

1. Security Knowledge Should be Embedded Inside the Protocol RFCs The corresponding implementations should come out robust even if the implementers blindly follow the RFC protocol specification Venkat Pothamsetty(with contributions from Prabhaker Mateti and Saadat Malik)

2. Why Should Security be Embedded into Protocol Specifications • The Types of Security Vulnerabilities have Remained more or less the Same the Past Few Years • The Attack Techniques (and consequently the Types of Security Measures) are Limited • Depending on implementers for protection is not practical • Security Considerations across RFCs are In-consistent • Security constraints can potentially be embedded into RFCs with minimal changes to present policies and procedures

3. The Types of Security Vulnerabilities have Remained more or less the Same the Past Few Years* • Vulnerabilities arising from not checking packet content –Implementation crashed when it encountered a packet with zero as the field content • Vulnerabilities arising from not checking packet size - crashed when it received big_sized/small_sized/zero_length packet • Vulnerabilities arising from not limiting the packet rates - Implementation crashed when it received a "flood" of packets • Vulnerabilities arising from not limiting the number of pay load attributes – Implementation crashed when large number of attributes are received • Vulnerabilities arising from not checking the packet sequence - Implementation hung when it did not received a packet late or did not receive a packet or received a wrong sequence of packet or multiple copies of a packet • Vulnerabilities arising from interpretation of terms - Implementation hung when it received an IP with a 0.0.0.0 address • Vulnerabilities arising from in-correct field parsing sequence – Implementation crashed when a field was not checked before starting to parse the rest of the packet * Above information is the result of analyzing over a 1000 publicly known vulnerabilities from various sources [“A Vulnerability Taxonomy for Internet Protocols”, published 2004]

4. The Attack Techniques (and consequently the Types of Security Measures) are Limited • Malformed – Constrain the specification with pre-post conditions • Flooding – Limit the packet rates for each packet or each state • Spoofing/sniffing – Force every specification to use security techniques (authentication, confidentiality) • Replay, reuse, out of sequence – Force every state to accept a specific sequence • Ambiguous terms – Explain the terms used with mathematical means • A complete list is published in the paper, “A Case for Attack Intelligent Specifications”, published 2005

5. RFC implementations Need to be Protected from this well-defined and well-contained Set of Attacks Adopting security measures against this set of attacks will take care of a large percentage of security issues we see today

6. Security Considerations across RFCs are In-consistent • Security considerations sections do not consistently • Methodically consider all attack scenarios • Propose specific solutions to threats identified • Security consideration sections claim, with out clear justification, that “the RFC brings no additional threats”

7. Embedding Protection within the RFC Protocol Specifications is the Best Possible Solution • Depending on implementers for protection is not practical; • Training the protocol developers to write secure code is hard • The implementation is only as secure as the implementer • With protection embedded, the implementers can be made “accountable for the security” of the implementation; they have to be contractually obligated to follow the specification. • The solution is scalable; there are a lot fewer specification writers than there are implementers. • The solution is effective; it ‘nips the evil in the bud’, stops the vulnerabilities even if the application code is not so robust.

8. One (rather extreme) Way of Implementing this Proposed Solution Specification of a RADIUS Server do wait-for(current-requests, empty-bag, "!="); object p: IP-UDP-packet := remove-a-packet(current-requests); if is-IP-UDP-RADIUS-packet(p) and is-Access-Request(p) and is-valid-client(p) and is-channel-encrypted(p) and is-valid-packetrate(packet_history) and is-not-duplicate-request(p) --> object r: IP-UDP-RADIUS-packet := compute-response(p); send-packet(r); servers-past += [p, r]; fi od

9. One (rather extreme) way of Implementing this Proposed solution(continued) Specifying the Structure of a RADIUS Packet model RADIUS-packet is composite ( code, identifier: byte, length: short, authenticator: Authenticator, attribute-bytes: seq byte,) such that for all r: RADIUS-packet ( r.code: {1 .. 5, 11 .. 13, 255}, r.length == 20 + \#attribute-bytes <= 4096, r.length <= r.sizeof, valid-attribute-bytes(r))

10. Some of the Issues That Still Need to be Addressed in This Model • Some of the specifications could be very platform dependent • But some packets are always malicious packets • Hard to change the existing culture and processes of RFC writing • The embedded security constraints could be made to require minimal changes • The process is not tested thoroughly • We could start out with a few RFCs..

11. Meyer's Seven Sins of the Specifier • Noise: • The presence in the text of an element that does not carry information relevant to any feature of the problem. Variants: redundancy; remorse. • Silence: • The existence of a feature of the problem that is not covered by any element of the text. • Over specification: • The presence in the text of an element that corresponds not to a feature of the problem but to features of a possible solution. • Contradiction: • The presence in the text of two or more elements that define a feature of the system in an incompatible way. • Ambiguity: • The presence in the text of an element that makes it possible to interpret a feature of the problem in at least two different ways. • Forward reference: • The presence in the text of an element that uses features of the problem not defined until later in the text. • Wishful thinking: • The presence in the text of an element that defines a feature of the problem in such a way that a candidate solution cannot realistically be validated with respect to this feature.