1 / 15

Thoughts on KeySec

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

Télécharger la présentation

Thoughts on KeySec

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.


Presentation Transcript

  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

More Related