IEEE 802.1af Discussion of KaY Key Exchange and Management

advertisement
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)
LMI
KaY Key Management (.1af)
SAKs
SAKs
MK to SAK
Key Derivation
Process
SecY (.1ae)
.1af Key
Exchange Protocol
.1ae Terminology
MK is 1 to 1
SC SA
SAK
SAK
…
SAK
SA
SAK
SAK
SAK
SAK is 1 to N
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
SecY
KaY
Type
Element
R/W
R
R/W
R
R
---
R
R/W
R
R/W
R/W
R/W
Enum
Enum
Int[]
Int
Boolean
MK[sci]
R/W
R/W
R
R/W
R
R
R
R
R
R/W
Int
Int
Int[]
Enum
Enum
R
R
R/W
R/W
R
R/W
R/W
R
R
R/W
Int
Int[]
Int
Enum
Enum
ConnectivityCapabilitiesSupported - multipoint or point-to-point
ConnecitivityCapabilityInUse - current connectivity
CipherSuitesSupported - Cipher Suites supported by SecY
CipherSuiteInUse - Current Cipher Suite In Use
NeighborsAllSecYs
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
– 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.
Download