Syslog-Sign and Syslog-Auth

1
Syslog-Sign and Syslog-Auth

• John Kelsey
• Counterpane Internet Security
• kelsey_at_counterpane.com
• IETF Secure Syslog Working Group--Dec 2000

2
Overview of Presentation

• Syslog-Sign
• Introduction and Overview of Syslog-Sign
• Terms and Important Ideas
• Signature and Certificate Block Formats
• Processing
• Conclusions
• Syslog-Auth

3
Introduction Context

• Syslog widely used for security-relevant data.
• Syslog sends data over network unprotected, over
  UDP.
• Some configurations permit only one-way
  communications.
• Want to make drop-in security with minimal impact
  on installations.

4
Introduction What We Want From Syslog-Sign

• Goals
• Support transmission and storage security
• Support offline review of logs online review
  possible but more computationally expensive.
• Build system using only valid syslog messages
  whole system in-band. (Use syslog for
  transport.)
• Provide some support for key management.
• Allow different signature schemes and hash
  functions.

5
Security Goals

• Origin Authentication
• Message Integrity
• Replay Detection
• Message Sequencing
• Gap Detection
• End up with authenticated log file or
  authenticated log data.
• Make security properties of log data explicit!

6
What's Not Possible?

• We can't ensure that all messages will arrive
• If you need reliable delivery, use TCP
• We can't ensure that compromised collector won't
  delete inconvenient messages
• Could use hash-network or cryptographic audit log
  to protect against this
• We can't ensure that sending device wasn't
  compromised

7
Overview of Syslog-Sign

• Three kinds of messages
• Normal messages
• Signature blocks
• Certificate blocks
• Normal messages sent unchanged
• Each signature block signs N messages
• Contains hashes of N messages
• Don't need all N messages to verify signature
• Sent as a syslog message

8
Messages as Sent

• Message 0
• Message 1
• Message 2
• Message 3
• Signature Block 0-3
• Message 4
• Message 5
• Message 6
• Message 7
• Signature Block 4-7

9
Signature Blocks and Messages as Sent
10
Messages as Received--Out of Order

• Message 1
• Message 0
• Message 2
• Message 4
• Signature Block 0-3
• Message 5
• Message 3
• Message 6
• Message 7
• Signature Block 4-7

11
Signature Blocks and Messages As Received--out of
order messages
12
Out-of-Order Messages/Blocks

• We have to link messages back to their block.
• Offline, this is easily done in two passes
• Build hash table of messages by hash value
• Go through signature blocks, pull messages from
  hash table as needed.
• Online, it can be done, but is more expensive
• Like handling a replay window

13
Messages as Received A Big Mess

• Message 3
• Message 1
• Message 4
• Message 3
• Signature Block 0-3
• Message 0
• Message 7
• Message 5
• Garbled Message
• Signature Block 4-7

14
Receiver Side Missing, Duplicate, and Garbled
Messages
15
Missing or Garbled/Altered Messages

• Signature block has hash with no matching
  message
• Treat it as a missing message
• Message with no matching hash in nearby signature
  block
• Discard
• May be garbled message
• May be old replayed message

16
Duplicate Messages

• Two messages with same hash for one spot in
  signature block
• Only one message included for that spot
• Same hash value in many spots in signature block
• No problem -- include same message text in
  authenticated log multiple times.

17
Some Terminology

• Some terminology
• Device -- the machine generating and sending out
  the log messages.
• Relay -- a machine that receives and forwards log
  messages
• Collector -- the final receiver of messages
• Reviewer -- someone offline, reviewing logs from
  the collector

18
Important Concepts Signature Group

• Device may send different messages to many
  collectors
• Signature Group is group of messages ALWAYS sent
  to same collector
• We don't specify how this is done--sysadmin's job
  to make sure logs in same signature group go to
  same place
• One signature group per collector?
• One signature group per priority value?

19
Important Concepts Reboot Sessions and Session
IDs

• Syslog has no inherent notion of a session
• A syslog-sign session
• From reboot to reboot
• Anytime device loses context
• Session ID must be unique for given device!
• Currently must be superincreasing
• Probably add pseudorandom session IDs

20
Message Index Numbers

• Within a signature group, each message can be
  given a number
• Number of messages sent before this message in
  this signature group.
• Header of signature block makes it easy to
  determine this number for all authenticated
  messages.
• Note Messages themselves don't carry number.

21
Syslog-Sign Messages

• Three kinds of messages sent
• Raw syslog messages, never altered
• Signature blocks, w/ enough information to verify
  syslog messages sent.
• Certificate blocks
• Sending device has tunable redundancy parameter
• Note change in how redundancy works

22
Signature Blocks--Structure

• Cookie
• Version
• Break into protocol, hash, signature versions
• Session ID
• Signature Group
• Global Block Counter
• First Message Number (in Signature Group)
• Count
• Message Hashes
• Signature

23
Signature Blocks--Fields

• Cookie
• Identifies message as signature block
• Fixed string "_at_sigSIG"
• Accidental/malicious collisions possible--must
  verify signature to be sure.

24
Signature Blocks--Fields

• Version
• CHANGED from previous note sent out
• 12 bit protocol version
• 12 bit hash version
• 12 bit signature version
• Each encoded as two bytes in base-64
• Version 1,1,1 this protocol, SHA1, DSA (with
  1024-bit p, 160-bit q)

25
Signature Blocks, Cont'd

• Session ID
• Each time Device reboots/loses context, start new
  session
• Session ID guaranteed never to decrease
• 48 bit field encoded as eight bytes.
• Possible to use variant scheme with session ID
  pseudorandom 96-bit value.
• A device MUST NOT ever use the same session ID
  twice!

26
Signature Blocks, Cont'd

• Signature Group
• Device may route different messages to different
  collectors
• Messages in same signature group must go to same
  place.
• Necessary because messages and signature block
  have to show up at same place.
• Note Nothing is added to messages to denote
  signature group must be inferred from context.
• 12 bit field encoded in two bytes.

27
Signature Blocks, Cont'd

• Global Block Counter
• Puts all signature blocks in order of
  transmission.
• 48 bits encoded as eight bytes.
• First Message Number
• unique message number (within signature group and
  session ID) of the first message whose hash
  appears in hash block.
• 48 bits encoded as eight bytes.

28
Signature Block, Cont'd

• Count
• Number of messages whose hashes appear.
• 6 bit value encoded as one byte.
• Message Hashes
• Sequence of message hashes
• Each hash value encoded separately in base-64
• Hash length effectively specified in Version
  field.

29
Signature Block, Cont'd

• Signature
• Digital signature on all previous fields in
  signature blocks.
• Hash, signature scheme, and signature
  encoding/padding used determined by Version
  field.
• Raw signature encoded in base-64.

30
Notes Variable Length Fields

• Signature Block fits in 1024 bytes printable
  ASCII.
• Version specifies size of hash and signatures.
• Count specifies number of hashes included.

31
Notes Redundancy

• Syslog over UDP is unreliable signature blocks
  may get lost.
• Redundancy tunable by sending device
• Signature blocks cover every N messages
• Can store and resend signature block multiple
  times to get redundancy
• Collector just discards redundant messages

32
Missing Signature Blocks

• If we don't receive a signature block
• N messages aren't able to be verified.
• Shows up as a gap in the authenticated logs.
• No problems authenticating later signature blocks.

33
Certificate Blocks

• Goal move a certificate, public key, or key
  fingerprint to receiver.
• Certificate chains can be very long.
• At session startup
• Build full payload block
• Split into M certificate blocks
• Send certificate blocks as syslog messages

34
Certificate Blocks, Cont'd

• Payload Block --Built at session startup
• Version
• Session ID
• IP Address of Sending Device
• Key Blob Type
• Key Blob

35
Certificate Blocks, Cont'd

• Version and Session ID exactly like those in
  signature blocks
• IP Address of Device (128 bits to support IPv6)
• Key Blob Type (Should add more)
• 'C' PKIX certificate
• 'F' key fingerprint using hash function
• 'R' raw public key
• 'U' user-specific block

36
Certificate Blocks, Cont'd

• Key Blob
• Raw certificate, key fingerprint, key, or user
  field.
• Base 64 encoded.
• Maximum of 232 bytes in principle
• Minimum of 1 byte in principle

37
Certificate Blocks, Cont'd

• Once we have payload, certificate blocks send it
  out in syslog message sized pieces.
• Certificate blocks include information to help
  with reassembly
• Redundancy supported in sending certificate blocks

38
Certificate Blocks, Cont'd

• Building Certificate Block
• Cookie
• Version
• Signature Group
• Total Payload Length
• Index into Payload
• Fragment Length
• Payload Fragment
• Signature

39
Certificate Blocks, Cont'd

• Cookie
• identify message as certificate block
• "_at_sigCer"
• Collisions possible--must check signature
• Version and Signature Group
• Just like same fields in signature blocks
• Total Payload Length
• Total length of payload block
• 32 bits encoded as six bytes

40
Certificate Blocks, Cont'd

• Index into Payload
• Which byte of payload block does this fragment
  start on?
• 32-bit field encoded as six bytes.
• Fragment Length
• Length of this fragment in bytes
• 12-bit field encoded as two bytes
• Payload Fragment
• Block of bytes as indicated above.

41
Certificate Blocks, Cont'd

• Signature (added)
• Just like signature blocks
• Necessary because of possibility of spoofed fake
  certificate blocks

42
Certificate Blocks, Cont'd

• Transmission and Redundancy
• Whole payload block sent to each signature group
  at session startup
• Depending on redundancy parameter, resent
  periodically during session.
• NOTE At session startup, we can generate all
  certificate blocks and store them.
• Is this an unreasonable requirement?

43
Offline Review

• Make one raw log file from one device's sent
  messages with same session ID.
• First Pass Store normal messages in hash table
• Second Pass Verify signature blocks, for each
  hash value, pull message in from hash table.
• End up with authenticated sequence of log
  messages.

44
Online Review

• Keep "replay window" of last KN messages in
  binary tree or hash table.
• As message rolls out of window, remove from
  tree/table.
• Pull messages with desired hashes out when
  signature blocks are processed.
• Process signature blocks in middle of replay
  window.
• CAVEAT I haven't implemented this.

45
Summary Syslog-Sign Plusses

• Minimal impact
• Use syslog for transport
• New software on device
• Software for online or offline review of logs
• Meets all original security goals
• Yields clear set of security claims about log
  messages
• Plays well with syslog-reliable
• Together, can provide strong storage security
• Clean, efficient design for offline analysis

46
Syslog-Sign Minuses

• Online analysis more complex and expensive
• Clearly possible
• May require change to how messages are routed to
  collectors
• (to keep signature groups together)
• Requires some available memory on sending device

47
Syslog-Auth Syslog-Sign

• I did syslog-auth first
• Much more complicated protocol
• Some of that will change
• Can't cover most options here
• Main Differences
• Key management assumptions
• Many more configuration options supported
• Append authentication information to message
• Online analysis emphasized

48
Syslog-Auth and Syslog-Sign

• Syslog-Sign assumed
• Public key or endpoints share keys.
• Only sending device syslog-sign aware.
• Probably use offline analysis
• Syslog-Auth makes different assumptions
• Secret keys shared by adjacent machines
• (e.g., Device-gtRelay, Relay-gtCollector)
• Some relays syslog-auth aware, some not.
• Online analysis

49
Overview of Syslog-Auth

• Original sending device appends authentication
  block to all outgoing messages
• Relays append second authentication block
• Additional hops relays remove previous relay's
  authentication block, replace with own.

50
(No Transcript)
51
Relays update outside authentication blocks based
on shared keys with next-hop node
52
Syslog-Auth Key Concepts

• Message may go over secure and insecure hops.
• Relays keep track of security properties of
  messages they forward, note in authentication
  block.
• Emphasis on online analsyis
• Core Difference Syslog-auth assumes very
  different key management scheme
• Note Syslog-Auth is likely to change in near
  future

53
Authentication Blocks Format

• Transmission MAC block
• Storage MAC block
• Forwarding block
• Dest. Msg. Counter
• Global Msg. Counter
• Reboot session ID
• Flags
• Version
• Cookie

54
Auth Block Format

• NOTE We parse auth block from end of message
  backward.
• Version and flags determines which fields are
  present, length of variable-length fields
• If there are two authentication blocks, outside
  block authenticates (message-text,first-authentic
  ation-block)

55
Authentication Block--Components

• Transmission MAC Block
• MAC Key ID
• MAC over whole message, including authentication
  block, with Transmission MAC filled in with
  zeros.
• Storage MAC Block (optional)
• MAC Key ID
• MAC over whole message, incl. Auth block, with
  both MACs filled in with zeros.

56
Authentication Block--Components

• Forwarding Block
• Described below
• Only appears when message is forwarded
• Dest. Msg. Counter
• Optional
• Keeps count of log messages sent to each
  recipient in this session.
• 48 bits encoded as eight bytes

57
Authentication Block--Components

• Global Msg. Counter
• Count of all log messages sent by this machine
  during this session
• 48 bits encoded as eight bytes
• Reboot session ID
• Unique ID for this reboot session
• Can be 48 bits or 96 bits, depending on how
  generated
• Length specified in flags.

58
Auth Block ComponentSession IDs

• Can be superincreasing'' like those described
  in syslog-sign
• Can be pseudorandom
• 96 bits
• To generate, keep running hash for first N
  messages, then use low 96 bits of result as
  session ID.
• Problem Devices that send the same message all
  the time.
• Problem Replay detection requires storing all
  previous session IDs

59
Session IDs Cont'd

• Devices that use pseudorandom session ID start
  without unique session ID
• Temporary session ID
• Flag bits
• Not Replay Resistant
• Some devices may be stuck with only this
  "temporary session ID"
• Some devices may keep fixed ID because they never
  lose context.

60
Authentication Block--Components

• Flags
• Which optional fields are present
• What size variable-length fields will take
• Security properties known about this message
• Version
• Effectively specifies algorithms.
• Cookie
• "authAUTH"

61
Forwarding Block

• Only included in outer authentication block
• Fields
• Flags (will probably move to auth block flags)
• Secure Path
• Replay Resistant
• IP Address of Entry Point
• Will extend to 128 bits to support IPv6.
• Hop Count

62
How it Works Device-gtCollector

• Device and Collector share key.
• MAC gives
• Message integrity
• origin authentication
• Unique Session ID and Global Msg Counter gives
  replay and gap detection.
• Online analysis easy

63
How It Works Forwarded Messages

• Device-gtRelay-gt-gtCollector
• Each "hop" involves keys and context shared
  between sender and receiver.
• Shared key
• Ability to recognize replayed session IDs
• Ability to recognize replayed message IDs

64
Forwarded Messages Status Flags

• This relay knows
• Whether it can detect replays of this message
• Whether this message came over a secure path
• Whether it can detect gaps in this message
• Previous sender embeds answers to above questions
  in authentication block
• This relay ANDs its answers with those in old
  authentication block, puts in new authentication
  block

65
Forwarded Messages Cont'd

• Device -gt Relay1 -gt Relay2 -gtCollector
• Suppose Relay1 just started session, using
  temporary session ID (not replay resistant)
• Relay1 sets Replay Vulnerable flag in
  authentication block
• Relay2 sets same flag tells Collector that
  message may be replay

66
Why Sticky Flags Matter

• Device -gt Relay1 -gt Relay2 -gt Collector
• Suppose Device is old-style, messages aren't
  protected until Relay1
• If we don't tell Collector, it will assume all
  these messages from Relay2 are authenticated.
• This is worse than no cryptography--user of logs
  can't tell what is really authenticated and
  what's not.

67
More Sticky Flags

• Device -gt Relay1 -gt Relay2 -gt Collector
• Device -gt Relay1 uses syslog-auth over UDP
• Relay1 -gt Relay2 -gt Collector uses
  syslog-reliable over TCP/BEEP/SSL
• How does collector know
• Are all messages present, or may some have been
  lost?
• Were these messages all encrypted end to end
• Answer he can't know without some kind of status
  flags from message

68
Syslog-AuthPlusses and Minuses

• Plusses
• Easy to do online verification of logs
• Sticky flags
• Support for lower-level key management
• Minuses
• Very complicated spec (will get simpler)
• No support for public key or higher level key
  management
• Requires changing software on every relay and
  collector

69
Future of Syslog-Auth

• The whole system has too many options
• Probably try to move toward Syslog-sign
• May try to merge the two.
• If we keep syslog-auth
• Probably start using signature groups
• Make final collector responsible for replay
  detection/gap detection from device.
• Simplify options
• Clean up spec tremendously.