Presentation on theme: "IETF 71 SIPPING WG meeting draft-ietf-sipping-pai-update-00."— Presentation transcript:
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 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
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
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
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)
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?
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
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)
Your consent to our cookies if you continue to use this website.