Embed Size (px)
Citation preview
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
