Ieee 802. 1af Discussion of



Yüklə 450 b.
tarix08.01.2019
ölçüsü450 b.


IEEE 802.1af


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

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





Dostları ilə paylaş:


Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2019
rəhbərliyinə müraciət

    Ana səhifə