1 / 8

IETF 71 SIPPING WG meeting

IETF 71 SIPPING WG meeting. draft-ietf-sipping-pai-update-00. Changes from draft-elwell-sipping-update-pai-02. More text on motivation for PAI in responses Reworded in many places to express in terms of Trust Domain

halla-moss
Download Presentation

IETF 71 SIPPING WG meeting

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. IETF 71 SIPPING WG meeting draft-ietf-sipping-pai-update-00

  2. Changes from draft-elwell-sipping-update-pai-02 • More text on motivation for PAI in responses • Reworded in many places to express in terms of Trust Domain • References to the security requirements of RFC 3325 for connections between nodes within a Trust Domain • P-Preferred-Identity allowed in additional request methods and in responses • Many minor changes

  3. Open issue 1 • Whether to allow P-Asserted-Identity in a REGISTER request, between an edge proxy that authenticates the UA and a registrar • Only feedback was in favour • Propose to allow this

  4. Open issue 2 • Whether to allow P-Asserted-Identity in any mid-dialog request (including PRACK, INFO, BYE...) rather than just UPDATE • Viewed another way: what is meaning of a mid-dialog request that omits PAI? • source of request unchanged (UAC authenticated again)? • source of unchanged (not necessarily authenticated again)? • no deduction can be made about the source of the request? • The last of these seems the safest (implying that all requests should be allowed to contain PAI) – but a suggestion on list that this could depend on spec(T) • Conclusion seems to be to allow in all requests

  5. Open issue 3 • Are there any use cases that justify the use of P-Preferred-Identity in an UPDATE request? • The conditions under which an UPDATE request needs to include P-Asserted-Identity are generally associated with B2BUAs and Gateways, which normally would be treated as being within the Trust Domain and would use PAI • No real interest on list – but could allow just for completeness (does no harm)

  6. Open issue 4 • Should we be precise (at least in the normative section) as to the conditions under which a proxy may assert an identity in the response? • e.g., only if the proxy has TLS connectivity with the originator of the response and has previously authenticated the connected entity (e.g., using SIP digest authentication at registration time)) • are there any other acceptable conditions? • or do we need to leave it open?

  7. Open issue 4 (continued) • RFC 3325 is not precise even for requests – just says UAC must have been authenticated • This is in line with “applicability statement” in section 1 of RFC 3325, which includes the statement: • “The means by which the network determines the identity to assert is outside the scope of this document (though it commonly entails some form of authentication).” • Question has been asked whether to have explicit text saying whether the applicability statement in RFC 3325 still holds or the draft updates it somehow

  8. Open issue 4 (continued) • Propose to say that applicability statement in RFC 3325 still holds and keep open the means of authenticating the UAS (keeping TLS example)

More Related