1. SAML assisted Diffie-Hellman MIKEY
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?