Security%20Knowledge%20Should%20be%20Embedded%20Inside%20the%20Protocol%20RFCs

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(curren
  t-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) --gt
  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 lt 4096,
• r.length lt 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.