SIP-SAML assisted Diffie-Hellman MIKEY

1. SIP-SAML assisted Diffie-HellmanMIKEY IETF 65 MSEC Mar 21, 2006 Robert Moskowitz

2. Requirements to think aboutFor SRTP keying • Provides mutual authentication of the call 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. • The important part of this presentation • An optional second round trip extension to MIKEY, encrypted with the Diffie-Hellman derived session key can provide items 4 and 5. • Perhaps item 5 (lack of reliable time clocks) may not be of practical concern • Locality of validation and D-H key sizes to address item 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 • draft-tschofenig-sip-saml-05.txt

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. • Additional 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 caller’s SAML certificate from its domain's SIP server • it trusts its 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. • Starting point • draft-ietf-sipping-certs-03

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. • NIST Special Publication 800-56A • Sec 6.3

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 • Or compute one overnight • 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 security risks • 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 • SIP phone MIGHT get its SAML cert for a 3rd party that will not participate in a Diffie-Hellman attack

13. Questions?