IETF 71 SIPPING WG meeting

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)