1 / 8

Issues with HTTP Authentication for SIP

Issues with HTTP Authentication for SIP. Hisham Khartabil SIP WG IETF 59, Seoul hisham.khartabi@nokia.com. Analysis: HTTP Authentication for SIP. draft-khartabil-sip-auth-analysis-00 The document analyses HTTP Authentication for SIP and discusses some implementation issues

neldar
Download Presentation

Issues with HTTP Authentication for SIP

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. Issues with HTTP Authentication for SIP Hisham Khartabil SIP WG IETF 59, Seoul hisham.khartabi@nokia.com

  2. 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. Realm: nokia.com Alice Realm: nokia.com INVITE 407 ACK INVITE INVITE 407 407 ACK ACK The realm Issue (1)

  4. Realm: nokia.com Alice Realm: nokia.com INVITE 407 ACK INVITE INVITE 407 407 ACK ACK 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 1st 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.

  5. Realm: nokia.com Alice Realm: nokia.com INVITE 407 ACK INVITE INVITE 407 407 ACK ACK 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.

  6. Realm: nokia.com Realm: nokia.com Alice Realm: nokia.com INVITE INVITE INVITE 407 ACK 407 ACK 407 ACK INVITE INVITE INVITE The realm Issue (3)

  7. Realm: nokia.com Realm: nokia.com Alice Realm: nokia.com INVITE INVITE INVITE 407 ACK 407 ACK 407 ACK INVITE INVITE INVITE 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.

  8. 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.

More Related