Thoughts on KeySec

1
Thoughts on KeySec

• John Viega
• viega_at_securesoftware.com

2
Review of phases

• In Orlando, seemed to agree on .af phases
• Discovery (insecure)
• Authentication
• Authorization
• Key Management

3
Authentication issues

• Where does the cipher suite get negotiated?
• along with any other options
• Have to be very careful with message design in
  authentication phase
• Authorization phase no real handle on reqs
• To what degree are we specifying this, or is it
  for vendors?
• Proposed solution
• Carefully design into authentication protocol.

4
Authentication issues

• What 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 reconnects
• Can 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)

5
Fast reconnects

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

6
Authentication issues

• When 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 time
• In the two-party case, we can leave it
  unspecified
• SNMP, enter into console, or whatever the vendor
  likes
• This way, very lightweight and easier to make
  robust
• Central management is an issue here

7
We should not use EAP

• Even w/o methods, EAP is large and complex
• Will implementations really be robust?
• How often will there be a failure?
• Is this a DoS risk?
• No one could ever put this in hardware
• EAP is designed for a different environment
• Designed for dial-up to modem pool
• Popular methods fail on shared media (prone to
  misuse)
• Even today, the slant is customer interfacing
• customer interfacing vs. infrastructure ports

8
More EAP issues

• pass-through model is not ideal
• EAP effectively has both parties auth to AAA
  server
• Hardware should directly auth with HELP from AAA
• Does not support dual pass-through
  (switch-to-switch case)
• Realistic, but will generally both backend to
  same server
• No support for trusted third parties, either!
• It makes key management decisions for us
• An artifact of an ad hoc design
• Ensuring conformance will add complexity

9
AAA servers

• Do we care about specifying pass-through?
• Let a vendor worry about it if they really want
  it
• Trusted-third party model is more useful
• TTP, 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

10
Some authentication recommendations

• Keep it simple
• No EAP
• No pluggable methods
• Leverage the mandatory cipher suite
• We should only support fast reconnect
  authentication
• It may be useful to support a TTP protocol for
  centralized management

11
Towards a protocol

• Many ways to do fast reconnects
• Just pick up the old connection where you left
  off
• Use the old key to create a new key, and replace
  the old key
• Use one key long-term, just to generate transient
  keys
• Third solution makes key management much, much
  easier

12
Preliminaries

• A and B share S (long-term secret)
• A and B each maintain two counters
• Last 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 key
• Necessary but hopefully rare key-lifetime issue
• Call additional information O
• What else should go in here?
• Cipher suite?

13
Partial protocol

• A sends identities of A B, key ID and GCM(AB,
  O)
• A increments key ID
• B validates the MAC
• B ensures key ID of A is higher than the previous
  (successful) key ID of A
• B uses specified key to generate authentication
  output
• Key for authorization discussion
• Key for use in .ae
• B Beginning authorization signals valid
  authentication.
• Might need to finish cipher-suite negotiation
  here.

14
Issues

• What happens if an attacker doesnt allow B to
  respond?
• A will eventually run out of nonces
• Fall-back to a challenge-response protocol
• If 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
  form
• B 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

15
Key Management, etc.

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