1 / 13

SIP-SAML assisted Diffie-Hellman MIKEY

SIP-SAML assisted Diffie-Hellman MIKEY. IETF 65 MSEC Mar 21, 2006 Robert Moskowitz. Requirements to think about For SRTP keying. Provides mutual authentication of the call parties. Both parties are actively involved in session key generation.

keziah
Download Presentation

SIP-SAML assisted Diffie-Hellman MIKEY

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.

E N D

Presentation Transcript


  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?

More Related