TCP-AO Key Management Sandra Murphy

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

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

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

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?

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

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)

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)

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