1 / 7

SIP Digest Access Authentication

SIP Digest Access Authentication. Rifaat Shekh-Yusef IETF 89, SIPCore WG, London March 6, 2014. Algorithms Agility. New Algorithms SHA-256 SHA-512/256 IANA Registry HTTP Digest Hash Algorithms Registry. “HTTP Digest Hash Algorithms” Registry.

masao
Download Presentation

SIP Digest Access Authentication

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. SIP Digest Access Authentication Rifaat Shekh-Yusef IETF 89, SIPCore WG, London March 6, 2014 Rifaat Shekh-Yusef - SIP Digest Auth

  2. Algorithms Agility • New Algorithms • SHA-256 • SHA-512/256 • IANA Registry • HTTP Digest Hash Algorithms Registry Rifaat Shekh-Yusef - SIP Digest Auth

  3. “HTTP Digest Hash Algorithms”Registry Hash AlgorithmDigest Size Preference Reference -------------- ----------- ---------- --------- MD5 32 1.0 RFC XXXX SHA-512-256 64 2.0 RFC XXXX SHA-256 64 3.0 RFC XXXX Update Policy: Specification Required Rifaat Shekh-Yusef - SIP Digest Auth

  4. Forking • Forking Proxy • Aggregates challenges into a single response. • Multiple challenges should be differentiated by the realm. • Multiple challenges might belong to the same realm. • Can these challenges use different algorithms? • UAC • Provides authorization for each realm using the top/preferred algorithm. Rifaat Shekh-Yusef - SIP Digest Auth

  5. Forking Backward Compatibility Rifaat Shekh-Yusef - SIP Digest Auth

  6. QoP Backward Compatibility • RFC3261, Section 22.4, bullet 8 Use of the "qop" parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; since RFC 2543 was based on RFC 2069, the "qop" parameter must unfortunately remain optional for clients and servers to receive. However, servers MUST always send a "qop" parameter in WWW-Authenticate and Proxy-Authenticate header field values. If a client receives a "qop" parameter in a challenge header field, it MUST send the "qop" parameter in any resulting authorization header field. • RFC2617 - H ( H(A1) | nonce | nc | cnonce | qop | H(A2) ) • RFC2069 - H ( H(A1) | nonce | H(A2) ) Rifaat Shekh-Yusef - SIP Digest Auth

  7. Feedback? • Forking • QoP Backward Compatibility • WG adoption Rifaat Shekh-Yusef - SIP Digest Auth

More Related