are used in SIP today in addition to the Request-URI i.e., inclusion in addresses-of-record, contact addresses (the contents of contact headers, including those of register methods), and route headers. In each instance, the SIP URI scheme allows these existing fields to designate secure resources. The manner in which a SIP URI is dereferenced in any of these contexts has its own security properties which are detailed elsewhere [17]. The use of SIP in particular entails that mutual TLS authentication should be employed, and the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.6 Cer- tificates received in the authentication process should be validated with root certificates held by the client. Failure to validate a certificate should result in the failure of the request. Note that in the SIP URI scheme, transport is independent of TLS, and thus 'sip:anike@tut.com;transport=tcp' and 'sip:anike@tut.com;transport=sctp' are both valid (although note that UDP is not a valid transport for SIP). The use of 'transport=tls' has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. Users that distribute a SIP URI as an address-of-record may elect to operate devices that refuse requests over insecure transports. 22.3.4.2.2.2 HTTP authentication SIP provides a challenge capability, based on HTTP authentication, which relies on the 401 and 407 response codes as well as header fields for carrying challenges and credentials. Without significant modification, the reuse of the HTTP digest authentication scheme in SIP allows for replay protection and one-way authentication. 22.3.4.2.2.3 HTTP digest One of the primary limitations in using HTTP digest in SIP is that the integrity mechanisms in digest do not work very well for SIP. Specifically, they offer protection of the Request-URI and the method of a message, but not for any of the header fields that UAs would most likely wish to secure. The existing replay protection mechanisms described in RFC 2617 also have some l