Re: [stir] Roman Danyliw's Discuss on draft-ietf-stir-passport-rcd-23: (with DISCUSS and COMMENT)

[Alec Fenichel <[e-mail]>]

Making an HTTP request to a URL provided by an untrusted party is SSRF. The question is, can it actually be exploited. The attacker won’t be able to read the contents of the response, so this can’t simply be used for bypassing access controls. GET requests SHOULD NOT cause a server to perform any action, but in practice sometimes they do. There is also a concern about denial of service attacks against internal systems even if they don’t perform server action from GET requests. 

To reduce the likelihood of SSRF attacks, we added the following to ATIS-1000074.v003 (new lines added for clarity and references numbers change to title). This is for x5u URLs, but the concept is the same here: 

The STI-VS shall not dereference URLs that use a scheme other than “https” or a port other than 443 or 8443. 
The STI-VS shall not dereference URLs that contain a userinfo subcomponent, query component, or fragment identifier component as described in RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. 
The STI-VS shall not dereference URLs if the host resolves to a special-purpose IP address described in RFC 6890, Special-Purpose IP Address Registries. 
The STI-VS shall not dereference URLs that appear to be part of a Server-Side Request Forgery (SSRF) attack. 
The STI-VS may make an HTTP HEAD request to check the Content-Type or other headers before making an HTTP GET request to dereference the URL. 

Port 8443 was allowed because a major carrier was using it before this text was written. We wouldn’t have allowed 8443 if not for this. 

There is a plan to add the following (or similar) in the future: 

The STI-VS shall not dereference URLs if the path does not end in “.pem”. 


For caching, we said: 

The STI-VS shall implement the cache behavior described in RFC 7234, Hypertext Transfer Protocol (HTTP/1.1): Caching. If the HTTP response does not include any recognized caching directives or indicates caching for less than 24 hours, then the STI-VS should cache the HTTP response for 24 hours. 




Because all of the above is in ATIS-1000074.v003, only the client side (STI-VS) behavior is described. The server side (STI-CR) is described in ATIS-1000080.v005 (new lines added for clarity): 

The STI-CR shall only accept HTTPS requests. 
The STI-CR shall listen for requests on port 443 or 8443. 
The STICR shall not use URLs that contain a userinfo subcomponent, query component, or fragment identifier component as described in RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. 
The STI-CR shall use URLs with a path that ends with “.pem”. 
The STI-CR shall implement the cache control behavior described in RFC 7234, Hypertext Transfer Protocol (HTTP/1.1): Caching. The STI-CR HTTP response shall include the “Cache-Control” header with a “public” cache directive, “immutable” cache directive (as described in RFC 8246, HTTP Immutable Responses), and “max-age” cache directive. The “max-age” cache directive shall contain a value of at least 86,400 seconds (24 hours). Additional non-conflicting cache directives may be included. 


Sincerely, 

Alec Fenichel 
Chief Technology Officer 
TransNexus <https://transnexus.com/> 
[e-mail] <mailto:[e-mail]> 



[phone] <tel:[phone]> 

From: stir <[e-mail]> on behalf of [e-mail] <[e-mail]>
Date: Monday, March 6, 2023 at 12:27
To: 'Chris Wendt' <[e-mail]>, 'Ben Campbell' <[e-mail]>
Cc: 'Roman Danyliw' <[e-mail]>, 'The IESG' <[e-mail]>, [e-mail] <[e-mail]>, 'STIR Chairs' <[e-mail]>, 'IETF STIR Mail List' <[e-mail]>, 'Russ Housley' <[e-mail]>
Subject: Re: [stir] Roman Danyliw's Discuss on draft-ietf-stir-passport-rcd-23: (with DISCUSS and COMMENT) 

I don’t know how much CID is in use, so I think you have to require HTTPS at least. 

I don’t have an opinion on whether you should specify “MUST be HTTPS or CID”. 

I remember that Alec Fenichel added some requirements to the ATIS-1000074 spec with regard to caching, port numbers for HTTPS and defense against SSRF. I don’t know if those would have been good to have also included the IETF RFC 8224 spec, but just want to mention that if there are similar performance and/or security considerations for CID, and you decide to include CID in this spec, you might want to see if there are any similar recommendations for CID as were available for HTTPS. 

Pierce 



From: stir <[e-mail]> On Behalf Of Chris Wendt
Sent: Sunday, March 5, 2023 9:03 AM
To: Ben Campbell <[e-mail]>
Cc: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>; [e-mail]; STIR Chairs <[e-mail]>; IETF STIR Mail List <[e-mail]>; Russ Housley <[e-mail]>
Subject: Re: [stir] Roman Danyliw's Discuss on draft-ietf-stir-passport-rcd-23: (with DISCUSS and COMMENT) 



Hi Ben, 


Yes, thanks for catching that, perhaps HTTPS or CID is best path. Curious for other opinions. 



-Chris 




On Mar 2, 2023, at 5:01 PM, Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote: 


(No hats) 


I have a context related comment on one item: 



Thanks! 



Ben. 




On Mar 1, 2023, at 12:02 PM, Chris Wendt <[e-mail] <mailto:[e-mail]>> wrote: 



[…] 







** 5.*. Inconsistent requirements for URIs

-- icn: appears to be any URI per Section 5.1.3. This would make gopher:// <gopher://>,
ftp:// <ftp://>, https:// all equally valid. These have different security
characteristics.

-- jcd: per Section 5.1.4 “is intended to directly match the Call-Info header
field value defined in [I-D.ietf-sipcore-callinfo-rcd].” Section 4 of that
document says it “MUST define the use HTTPS or a transport that can validate
the integrity of the source of the resource as well as the transport channel
through which the resource is retrieved”.

-- jcl: is an HTTPS URL (per Section 5.1.5)

Why are these different? Support different levels of transport security? 

You are correct, i fixed “icn” to specifically be an HTTPS URL vs generic URI. jcd is not a URI, it’s a directly included JSON jcard object in the “rcd" claim.







IIRC, a previous version did specify HTTPS URLs for “icn”, but we discussed the possibility that an icon could be imbedded in a body part of the SIP request and be referenced with a “cid” URL. I suppose that if that is true for “icn”, it is probably also true for “jcl”. 



That being said, I am not aware of anyone actually doing that (yet) will not object if we think it is better to limit it to HTTPS. (Or as a compromise, say it MUST be either HTTPS or CID?) 







[…]