SAML assisted Diffie-Hellman MIKEY

1. SAML assisted Diffie-HellmanMIKEY IETF 64 MSEC Nov 8, 2005 Robert Moskowitz

2. Requirements to think about • Provides mutual authentication of the parties. • Both parties are actively involved in session key generation. • Is able to provide full perfect forward secrecy (PFS). • Supports distribution of group session keys. • Provides liveliness test when the UA does not have a reliable clock. • Supports limited UAs.

3. Observations • Items 2 and 3 are naturally provided by a Diffie-Hellman exchange. • Item 1 can be provided by a SAML attribute cert of the UAs ID and DH key • signed by the UA’s SIP server. • An optional second round trip extension to MIKEY, encrypted with the Diffie-Hellman derived session key can provide items 4, 5, and 6. • All of these components together create a relatively easy to deploy secure VoIP environment.

4. Scenarios for MIKEY • peer-to-peer • simple one-to-many • small-sized groups • If we design the MIKEY exchange to first create a peer-to-peer session key that can be extended to securely transmit another key, • the one-to-many and small groups exchanges are simply handled as special cases of the peer-to-peer exchange.

5. Trusted UA Credentials • For any successful MIKEY exchange, the parties SHOULD have trusted credentials. • These credentials SHOULD contain: • UA Identity • DH Public key • Proof of Trust • Time range for trusting credential

6. Low Latency and Computational overhead • MIKEY has to occur after call 'pickup' and before talking. • Latency here would be very apparent to the users. • Thus a MIKEY exchange SHOULD be completed in one round trip. • Additonal round trips should be optional for additional features.

7. Low Latency and Computational overhead • A hidden latency cost is credential validation. • If the UA received its SAML certificate from its domain's SIP server • it is trusting the server implicitly • thus it can extend that trust to relying on it to validate the other party's SAML certificate. • This not only eliminates the hidden validation latency, but also its computational cost to the UA.

8. Low Latency and Computational overhead • A common practice in generating a DH session key is to use the DH key in a keyed hash over random nonces and other data: • TGK is HMACx(RAND1|RAND2) where x = g(xi* xr) • This construct allows for a long-lived Diffie-Hellman key pair • as it is never used to encrypt any transmitted data • rather to generate the actual key.

9. Low Latency and Computational overhead • Consider Diffie-Hellman key size • Recommendation is 4096 bits to equal 128 bits for AES key • This will be too expensive for many SIP phones • Use ECC Diffie-Hellman? • Use optional smaller Diffie-Hellman key size • 512 bits • SIP phone could have mechanism to get new key periodically from PC or PDA • Remember Diffie-Hellman key is used in an HMAC to produce session key.

10. Next • Generate interest • Finish the Internet Draft • Used as the source for much of this presentation! • Get ‘buy in’ from SIP server vendors and SIP phone vendors

11. What about Legal Intercept • If both parties are registered to the same SIP domain • The SIP server can LIE and generate 2 SAML certs to place itself as the Man-in-the-Middle • If the parties are in different domains • The SIP servers can COLLUDE • Each generating 2nd SAML certs • Allowing either of both servers to be the Man-in-the-middle

12. What about security risks • See prior slide! • SIP phone MIGHT get its SAML cert for a 3rd party that will not participate in a Diffie-Hellman attack

13. Questions?