1. 1 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential Issues with HTTP Authentication for SIP Hisham Khartabil SIP WG IETF 59, Seoul hisham.khartabi@nokia.com

2. 2 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential Analysis: HTTP Authentication for SIP draft-khartabil-sip-auth-analysis-00 The document analyses HTTP Authentication for SIP and discusses some implementation issues Some solutions are proposed

3. 3 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential The realm Issue (1) INVITE 407 ACK Realm: nokia.com Alice 407 INVITE ACK

4. 4 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential The realm Issue (1) Issue: how does the UAC know, when the second proxy challenges, that it is not the first proxy re-challenging because the credentials provided to it were wrong? Proposals: Mandate that the proxy places stale=false when it is re- challenging due to wrong credentials. This means stale=false is different that stale not present at all. The UAC replaces the provided proxy-authorization header with a new one. Mandate that the proxy does not change the nonce when it is re-challenging due to wrong credentials. The UAC replaces the provided proxy-authorization header with a new one. Mandate that the 1 st proxy challenges with a qop param. Also mandate that it also sends an Authentication-info header when there is a challenge by a downstream proxy with the same realm. INVITE 407 ACK Realm: nokia.com Alice 407 INVITE ACK

5. 5 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential The realm Issue (2) Issue: Section 22.3 of RFC 3261 says: "When multiple proxies are used in a chain, a Proxy- Authorization header field value MUST NOT be consumed by any proxy whose realm does not match the "realm" parameter specified in that value". In the second INVITE, there are 2 Proxy- Authorization headers. Which one does it consume? It does not know since examining the realm is not enough Proposals: Need to specify that a proxy examines all digest response matching the realm AS WELL AS THE NONCE. INVITE 407 ACK Realm: nokia.com Alice 407 INVITE ACK

6. 6 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential The realm Issue (3) INVITE Realm: nokia.com Alice Realm: nokia.com INVITE 407 ACK 407 ACK 407 ACK INVITE

7. 7 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential The realm Issue (3) Issue: When receiving the second INVITE, how does a challenging proxy, that the request has been forked, to know, by just examining the realm, that this is a digest response to a challenge it issued? Proposals: Need to specify that a proxy examines all digest response matching the realm AS WELL AS THE NONCE. INVITE Realm: nokia.com Alice Realm: nokia.com INVITE 407 ACK 407 ACK 407 ACK INVITE

8. 8 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential Use of 401 and 407 Responses The use of 401 and 407 must be more normative. Text should read: A UAS that require authentication MUST use 401 in a response and MUST challenge with a www-authenticate header. Registrars and redirect servers MUST use 401 and www-authenticate header. Proxies MUST use 407 and proxy-authenticate header.