Thoughts on KeySec John Viega

  • Published on

  • View

  • Download

Embed Size (px)


  • Thoughts on KeySec John

  • Review of phasesIn Orlando, seemed to agree on .af phases:Discovery (insecure)AuthenticationAuthorizationKey Management

  • Authentication issuesWhere does the cipher suite get negotiated? along with any other optionsHave to be very careful with message design in authentication phaseAuthorization phase: no real handle on reqsTo what degree are we specifying this, or is it for vendors?Proposed solution:Carefully design into authentication protocol.

  • Authentication issuesWhat are the semantics for cipher suite negotiation?If we both support A and B, and prefer different algorithms, who wins? The initiator?Once weve authenticated a single time:We almost certainly want fast reconnectsCan someone change algorithms on a fast reconnect?I think this should be possible.Should fast reconnects occur even if the box was out of commission for 2 months (e.g., being repaired)

  • Fast reconnectsInitial authentication decisions usually made with help of some authority (e.g., PKI, Radius server)Authoritys endorsement is good for some period of validityOnce mutual identities are established, two parties generally share a symmetric keyWe can keep using this key until its lifetime ends, and can leverage it to choose a replacement before that happens

  • Authentication issuesWhen *shouldnt* we use a fast reconnect?Authorization can still occur after a fast reconnect.Only time we cant do a fast reconnect is when bootstrapping a connection for the first timeIn the two-party case, we can leave it unspecifiedSNMP, enter into console, or whatever the vendor likesThis way, very lightweight and easier to make robustCentral management is an issue here

  • We should not use EAPEven w/o methods, EAP is large and complexWill implementations really be robust?How often will there be a failure?Is this a DoS risk?No one could ever put this in hardwareEAP is designed for a different environmentDesigned for dial-up to modem poolPopular methods fail on shared media (prone to misuse)Even today, the slant is customer interfacingcustomer interfacing vs. infrastructure ports

  • More EAP issuespass-through model is not idealEAP effectively has both parties auth to AAA serverHardware should directly auth with HELP from AAADoes not support dual pass-through (switch-to-switch case)Realistic, but will generally both backend to same serverNo support for trusted third parties, either!It makes key management decisions for usAn artifact of an ad hoc designEnsuring conformance will add complexity

  • AAA serversDo we care about specifying pass-through?Let a vendor worry about it if they really want itTrusted-third party model is more usefulTTP, I am A and I want to connect to B. Give me a key for it.B doesnt even need to talk to the TTP to determine the key A got, just As identity

  • Some authentication recommendationsKeep it simpleNo EAPNo pluggable methodsLeverage the mandatory cipher suiteWe should only support fast reconnect authenticationIt may be useful to support a TTP protocol for centralized management

  • Towards a protocolMany ways to do fast reconnectsJust pick up the old connection where you left offUse the old key to create a new key, and replace the old keyUse one key long-term, just to generate transient keysThird solution makes key management much, much easier

  • PreliminariesA and B share S (long-term secret)A and B each maintain two countersLast key ID set by A, last key ID set by B (nonces)A can say, if this is successful, Id like to change our long-term keyNecessary but hopefully rare key-lifetime issueCall additional information OWhat else should go in here?Cipher suite?

  • Partial protocolA sends identities of A& B, key ID and GCM(A&B, O)A increments key IDB validates the MACB ensures key ID of A is higher than the previous (successful) key ID of AB uses specified key to generate authentication outputKey for authorization discussionKey for use in .aeB Beginning authorization signals valid authentication.Might need to finish cipher-suite negotiation here.

  • IssuesWhat happens if an attacker doesnt allow B to respond?A will eventually run out of noncesFall-back to a challenge-response protocolIf nonce is too low, B assumes it is randomly chosen (though it could be a replay) B chooses his own random nonce of a particular formB GCM-encrypts a new key and the nonce value it had stored. It authenticates As original packet as well.A validates the packet then tries to connect with new key.On failure, A discards new key.On success, A discards old key.B keeps old key until he is sure he and A agree on keys.What happens in race condition?Highest MAC address wins

  • Key Management, etc.Time to rekey? Redo the fast authentication protocolNeed to choose a new random key? Reserve a low key ID that B will reject (e.g., zero)Use a trusted third partyHave it be part of the other data


View more >