Thoughts on KeySec John Viega

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 (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

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