TCP-AO Key Management

1. TCP-AO Key Management Sandra Murphy sandy@tislabs.com, sandy@sparta.com

2. What TCP-MD5 Did Wrong • Uses an un-sophisticated MAC technique (suffix only) • No algorithm agility • … and uses MD5 • No KeyID – rekey during connection difficult • Options excluded

3. TCP-AO Goals • IETF standard authentication mechanism • Algorithm agility • Re-key during connection • Cover TCP options (optionally) • Miserly use of option bytes • No parameter representation in-stream • Compatible with TCP operation • Order independent; no TCP state machine changes • Use is independent between inbound/outbound • (Initial) coexistence with TCP-MD5 • But no upgrade to TCP-AO within connection

4. Key Management in TCP-AO • Key management is a separate protocol; not in-band because: • Option space has little room for negotiation • Removes need to deal with TCP retransmission, etc. • Key used determines algorithm and any needed parameters • Implies that parameter change induces key change • No KeyID required, but KeyID allowed in order to permit key overlap in re-key during connection

5. Key Establishment • A new key is established on each new connection attempt • A matter of intense discussion • BAD • Present operation uses manual keys – and will still be doing so when TCP-AO is deployed • Multiple connections during instability (links/neighbors) might run through the list of configured keys – making a bad situation worse • GOOD • While common advice is to randomize ports and ISN in the SYN, nothing in TCP at the receiver prevents/prohibits/detects re-use • So if keys are not changed for every connection, replay of an old SYN could restart connection or under the wrong conditions abort an existing connection • Must deal with operational concerns -- some way to produce “enough” manual keys?

6. Key Management Roles • Key Manager • Responsible for initial key establishment on connection startup, create/delete TSAD entry • TCP-AO choice could be application request or policy control • Responsible for re-keying and TSAD update • On external signal, policy, and/or communication from TSAD • TSAD (TCP Security Association Database) • Holds/archives key tuples for each direction of connection • TCP • Communicates with Key Manager on connection state change (at least on open and transition to Closed) • Communicates with TSAD to retrieve key tuples on segment transmission and receipt • Performs validation with keys retrieved

7. TSAD • Could be part of TCB, could be separate • Indexed by connection ID (“socket pair”) • Entry contains (separate for inbound/outbound): • Option exclusion list • Zero or more key tuples • Zero means TCP-AO not used • Each tuple includes KeyID(optional), MAC, key length, key • If there is no KeyID on any tuple, there is only one tuple • MAC type can be NONE (indicating no TCP-AO) • No overlap of KeyIDs (i.e., if parms change, key changes)

8. TCP Interactions with Key Mgmt • On OPEN (or LISTEN on SYN receipt?) • Request key establishment from Key Manager • On transition to CLOSED after CLOSE or ABORT call • Archive TSAD entry to cache (for later check for key reuse)

9. TCP Interactions with Key Mgmt • On segment transmit • Request tuple from TSAD (including # bytes to process) • If no TSAD entry, no key tuples or MAC of NONE, send w/o TCP-AO option • Otherwise, perform MAC and add TCP-AO • On segment receipt • Request tuple from TSAD (including # bytes to process) • Various considerations of tuple exists or not, MAC is NONE or not, TCP-AO is present or not, where most errors result in silent drop or silent accept • Validation failures are silently dropped (& indicated to TSAD?) • Process segment as usual (in window, etc.) • No pre-processing to avoid exhaustion from spoofed packets