Ieee 802. 1af Discussion of

IEEE 802.1af

• Discussion of

• KaY Key Exchange and Management Interface to SecY

SecY/KaY Interface Overview

.1ae Terminology

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

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
• 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)

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

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

• 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

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

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.