Enhanced Digest (draft-undery-sip-auth-00.txt) Sanjoy Sen, Nortel Networks James Undery, Ubiquity Vesa Torvinen, Ericsson

What’s new in the draft? *-Authentication-Info header –Added “realm” and made generic Integrity protection –Complete one-hop message integrity Compute checksum with all headers (w/ credential = 0) + body –Compute checksum with negotiated headers New ‘header-options’ parameter in digest challenge & response

What’s new in the draft? Bid-down attack detection –Prefixes (auth algorithms & auth types) attached to the nonce UAS-Proxy Authentication & message integrity check –3 new generic headers & 1 new response code: UAS-Authenticate: UAS challenges Proxy –Issue: Targeting the Proxy UAS-Authorization: Proxy provides credentials UAS-Authentication-Info: mutual authentication of response 492 error code: Proxy Authorization required Which of these new features are useful? Proposal: Keep *-Authentication-Info realm & Bid-down detection More discussions on Integrity & Proxy Authentication

Issues raised at IETF 53 Inadequate threat analysis in the draft Some potential threats: –Offline Dictionary attacks –People are bad at choosing/remembering a strong shared secret Both of these attacks can be mitigated by making the user choose strong passwords and use of ‘cnonce’ parameter. The problem with passwords is orthogonal to these enhancements Proxy Authentication –Multiple headers defined to authenticate Proxies –Multi-proxy authentication using a single 492 Should we issue multiple 492 challenges? –Targeting proxies (most of the times you wouldn’t know whom to target) Use Via header stripping & modified transaction ID. The latter idea is already in the draft. Needs transaction-stateful proxies

E-2-M Authentication Question: Is Proxy authentication (multi-hop away) required? RFC 3261 recommends TLS for adjacent Proxy authentication & Proxy-Proxy authentication However, –This doesn’t work for Proxies multiple hops away –All IP Phones are not expected to change overnight to support TLS/TCP. IPSec is also not applicable for the multi-hop case S/MIME is not suitable for E-M multi-hop server authentication, but is definitely a better candidate for integrity The stateful Proxy authentication using enhanced Digest with improved targeting mechanism may be useful for this case

Next Steps Continue this work? –Flesh out the useful pieces –What is missing? –More use cases?