Thoughts on KeySec

1. Thoughts on KeySec John Viega viega@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 req’s • 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 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)

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

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

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 doesn’t even need to talk to the TTP to determine the key A got, just A’s 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, 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?

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

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

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