SAML assisted Diffie-Hellman MIKEY

1
SAML assisted Diffie-HellmanMIKEY

• IETF 64 MSEC
• Nov 8, 2005
• Robert Moskowitz

2
Requirements to think about

1. Provides mutual authentication of the parties.
2. Both parties are actively involved in session key
   generation.
3. Is able to provide full perfect forward secrecy
   (PFS).
4. Supports distribution of group session keys.
5. Provides liveliness test when the UA does not
   have a reliable clock.
6. 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 UAs 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(RAND1RAND2) 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?