IEEE 802.1af

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

2. 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

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

4. 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)

5. 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

6. 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

7. 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

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

9. LMI Key Management Interface - SecY/KaY

10. 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.

11. 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

12. 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 • InstallKey • All peers in peer list do NOT have installed SAs but TX SC has installed SA • UninstallKey of SA for TX SC (Symmetry broken)

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

14. 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.

15. 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

16. LAN-level Events • Local station start • 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 (?) • SA with no matching peer in peer list

17. 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 • Uninstall Key of SA for TX SA

18. 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?

19. 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.