Thoughts on KeySec
John Viega
viega@securesoftware.com
Review of phases
• In Orlando, seemed to agree on .af phases:
–
–
–
–
Discovery (insecure)
Authentication
Authorization
Key Management
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 req’s
– To what degree are we specifying this, or is it for
vendors?
• Proposed solution:
– Carefully design into authentication protocol.
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 we’ve 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)
Fast reconnects
• Initial authentication decisions usually made
with help of some authority (e.g., PKI, Radius
server)
• Authority’s 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 it’s lifetime
ends, and can leverage it to choose a
replacement before that happens
Authentication issues
• When *shouldn’t* we use a fast reconnect?
• Authorization can still occur after a fast
reconnect.
• Only time we can’t 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
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
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 (switchto-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
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 doesn’t even need to talk to the TTP to
determine the key A got, just A’s identity
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
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
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, I’d 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?
Partial protocol
•
•
•
•
A sends identities of A& B, key ID and GCM(A&B, 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.
Issues
• What happens if an attacker doesn’t 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 A’s 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 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