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

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

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
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]…

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
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
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 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 (?)

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

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.