Discussion of KaY Key Exchange and Management Interface to SecY IEEE 802.1af Discussion of KaY Key Exchange and Management Interface to SecY Jim Burns May 20, 2004 Barcelona, Spain jeb@mtghouse.com

SecY/KaY Interface Overview MK (Master Key - pairwise) KaY Key Management (.1af) LMI SAKs .1af Key Exchange Protocol MK to SAK Key Derivation Process SecY (.1ae) SAKs

.1ae Terminology MK is 1 to 1 SC SA SAK SAK SAK SAK is 1 to N … SA SAK

Assumptions If pre-shared master key is deployed out-of-band then key management can operate without authentication protocol. Authorization shall operate following key exchange and creation of the secure channel. Master Keys have Time & Msg-count life times Key-exchange exchanges only one (1) one-way SAK, so two key exchanges must occur between two (2) peers to achieve symmetric connection. I discuss only the .ae/.af interface, I do not discuss specific key management protocol here (I assume there is some method of deriving SAKs from MK)

LMI Communication Communication between SecY and KaY is indirect via LMI LMI is modeled as data structures not as functions. Writing certain data may cause actions at the SecY or KaY Reading data causes no action

LMI: from SecY to KaY Connectivity Capabilities Supported Cipher Suites Supported txEncodingSA - which SA to use for transmit encoding. txEncipheringSA - which SA to use for transmit enciphering (optional). State of each SC State of each SA NextPN of each SA

LMI: from KaY to SecY Connectivity to use Cipher Suite To Use Indication whether All neighbors are SecYs Association Number for each SA (?) Secure Association Key for each SA MUST generate SAK (whether valid or not. An invalid SAK should be a random number…) Request to install/remove/use/don’t-use an SC Request to install/uninstall SAK for each SA

LMI: from ??? To KaY Limit to number of allowed RX SC Desired/required authorization level

LMI Key Management Interface - SecY/KaY Type Element R/W R Enum ConnectivityCapabilitiesSupported - multipoint or point-to-point ConnecitivityCapabilityInUse - current connectivity Int[] CipherSuitesSupported - Cipher Suites supported by SecY Int CipherSuiteInUse - Current Cipher Suite In Use Boolean NeighborsAllSecYs --- MK[sci] Pairwise Master Keys - pairwise key (1-to-1), provisioned via some mechanism (SNMPv3, EAP, Kerberos, out-of-band, etc) - with lifetimes TXSC - Secure Channel for transmitting to ALL peers in CA txEncodingSA txEncipheringSA SCI - Secure Channel Identifier (SCI=MAC+PortNumber) State - current state of this SC {Unused, NotInCA, InCA} Cmd - command to carry out on this CA {Use, AddToCA, RemoveFromCA, stopUsing} SA[0] - Secure Association AN - Association Number (SAI=SCI+AN) SAK - Security Association Key nextPN - next Packet Number State - current state of this SA {Unused, Install, Installed} Cmd - command to carry out on this SA {InstallKey, UninstallKey} SA[1]… SA[2]… SA[3]… RXSC[0] - Secure Channel for receiving from ONE peer in CA << same fields as TXSC except txEncodingSA and txEncipheringSA >> RXSC[1]… RXSC[n]…

Start up… New common port becomes available SecY & KaY instantiated for common port CA created with last saved value (could be an initial out-of-band provisioned value) MK and KGK restored with lifetimes. Announcement occurs, creating peer list TX SC and RX SC created for each peer in peer list. SCs created either via key exchange (if MK available for peer) or authentication (if no MK) Each key exchange results in SAK that is stored in SA. When all peers have SC with SAK, the SAK for the TX SC is stored ins its SA.

Events That Cause Action New common port available KaY instantiated LMI provisioned with last stored CA including Pairwise MKs Empty peer list Send announcement frame (rate limited to 1 per second) Peer station in peer list with no matching SC Create SC with no SA AddToCA SC with no matching peer in peer list RemoveFromCA SC with no active SA Create SA with null key values (completely random) InstallKey

Events That Cause Action (2) SA with null key that we do not have peer MK for Carry out authentication with peer - peer MK created SA with null key that we do have peer MK for Carry out key exchange with peer to obtain SAK InstallKey All peers in peer list have SAs with installed keys but no SA with installed key for TX SC with a valid nextPN Create SA with TX SAK All peers in peer list do NOT have installed SAs but TX SC has installed SA UninstallKey of SA for TX SC (Symmetry broken)

Events That Cause Action (3) Peer MK lifetime expired Remove peer MK stopUsing SC for peer Peer MK changed New RX SA created (as result of key exchange initiated by another system) installKey

Events That Cause Action (4) New rx SA from station we already have rx SA with Create SA in unused SA InstallKey for SA UninstallKey for old SA 2 seconds after receiving a frame with new SA NextPN of installed TX SA is ‘close’ to exhaustion - Generate new SAK Carry out authentication and/or key exchange with each peer to send them new SAK Need to not make this a special case… tie into other events.

Events That Cause Action (5) Authorization level not at expected/required level Need new LMI variable to allow higher layer to define level Attempt to achieve authorization level via Authorization New authentication

LAN-level Events Local station start Local station stop New Common Port available Local station stop Common port not available Peer Station enters CA (KaY discovers new station) Peer in peer list with no SA Peer Station leaves CA gracefully (?) SA with no matching peer in peer list Peer Station leaves CA ungracefully (?)

LAN-level events (2) CA becomes non-transitive or non-symmetric Uninstall Key of SA for TX SA MAC_Operational set to false by SecY No action(?) Choice of available cipher suites is changed by management, removing currently used cipher suite

Questions… Whose job to ensure symmetric and transitive attributes of CA are not violated? Which keys will have lifetimes? SAK -- PN limits lifetime, nothing else needed MK -- lifetime limits in time/frames-sent set during authorization If a receiving SA is approaching the limit of its packet number should we attempt to initiate new SA creation? Or is it always the owner of the TX SA that creates a new SA? How to detect non-SecY neighbors? Announce, and Announce again upon receipt of peer’s Announce Make changes to CA persistent with every change?

Next Steps Further define variables need to be LMI (beyond those for SecY) Create draft of the SecY state machine Define how we will reference variables for LMI For each event create actual state machine like conditions and actions using variables defined for LMI Ensure all events needed for SecY are represented.