Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
Good points! I can't speak for the draft authors here, but my understanding and expectation was, in part in response to the concerns with tls-sni mitigated by tls-alpn, to ensure there's a strong binding from the request to the response, and that the binding is unambiguous. What I mean by that is that in the case of tls-sni, there wasn't a strong binding between the host name of the challenge certificate and the host name that the certificate would be issued for (the .invalid problem). TLS-ALPN resolves this by introducing the ALPN identifier as the protocol signal, and thus ensures a strong binding between the SNI name and the final certificate - ensuring it's unambiguous as to what host name will be challenged for. As you note, TLS prohibits the use of the IP address in SNI, and thus makes it difficult to have a strong binding between the name that the certificate will be issued for and the challenge certificate. This leaves two options: introduce an alternative way to encode the challenged-for IP in the request (which the draft does) or omit it entirely (as I believe you're proposing). If we go with the former approach, encoding it in the request, than servers that are dispatching the request can ensure that it's only dispatched to the entity responsible for the IP address encoded. If we go with the latter approach, then servers would need to ensure that the SNI-less responses can only be provided on the particular party authorized for that IP address. The latter only becomes a consideration if multiple IPs are terminated at the same TLS layer, and that TLS termination layer doesn't consider the destination IP when dispatching certificates. If we were to omit the binding, it'd likely be worthy of a security consideration to specify guidance as to how to do so safely / considerations that should be done before enabling TLS-ALPN in the context of IP. Alternatively, if we assume they took the necessary steps for TLS-ALPN, then encoding the domain in the SNI allows the existing dispatch protection mechanisms to work will continue to work. That's, at least, how I've viewed it :) On Mon, Apr 22, 2019 at 9:21 PM Corey Bonnell wrote: > Hi Ryan, > I suppose I should have framed my email a bit more generally as opposed to > focusing specifically on the security aspects. More broadly, I'm having a > hard time coming up with a reason why the SNI extension must be included at > all for IP address challenges. In the normal TLS connection flow, a > connection by direct IP address (not hostname) would not include the SNI > extension at all, so mandating the use of the .arpa domain in the SNI is > inconsistent with normal TLS processing. This inconsistency is compounded > when you consider that the self-signed cert for the challenge encodes the > IP address as an iPAddress SAN (and not the .arpa dNSName). I could also > see someone being confused upon reading the spec and thinking that a DNS > A/ record lookup against the in-addr/ipv6.arpa domain must be performed > and that the challenge TLS connection is to be done against the resolved IP > address. > > I believe it would be more consistent with normal TLS processing and less > confusing to prohibit the use of SNI altogether for IP address validations. > However, I'd greatly appreciate any explanations as to why it is preferable > to include the SNI extension. > > Thanks, > Corey > > -- > *From:* Ryan Sleevi > *Sent:* Wednesday, April 17, 2019 1:05 AM > *To:* Corey Bonnell > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] SNI extension for tls-alpn-01 challenge in > draft-ietf-acme-ip-05 > > > > On Tue, Apr 16, 2019 at 9:55 PM Corey Bonnell > wrote: > > Hello, > > Draft-ietf-acme-ip-05 specifies that for the tls-alpn-01 challenge, an > SNI value with the in-addr/ipv6.arpa domain name corresponding to the > iPAddress being validated MUST be specified. I have a concern that this > requirement suffers the same problem that rendered tls-sni-01 insecure: > namely, an arbitrary user on a shared hosting provider could upload an > arbitrary certificate for the required .ip-addr/ipv6.arpa domain, thus > circumventing any security provided by the mandatory SNI extension. > > The mandatory ALPN extension prevents this from being exploited to obtain > fraudulent certificates, but given how trivially the SNI requirement can be > defeated in the same manner as for tls-sni-01, I don’t believe that > requiring SNI provides any security value and is not necessary. If the > intent for requiring the SNI extension is to convey to the TLS server that > an IP address is being validated, couldn’t that similarly be accomplished > by *not* specifying any SNI extension at all? Tls-apln-01 (for dNSNames) > requires that a SNI value be specified, so TLS servers could differentiate > between challenge requests for dNSNames and iPAddress based on the presence > (or absence) of the SNI extension. > > > I’m not sure I follow the attack scenario you’re describing
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
Ryan Sleevi wrote: > The latter only becomes a consideration if multiple IPs are terminated > at the same TLS layer, and that TLS termination layer doesn't consider > the destination IP when dispatching certificates. If we were to omit I am curious to understand the use case for offboard TLS termination by IP address.That would seem to involve some kind of layer-3 (destination) NAT. Given that TLS would forbid SNI being present in that case, how would such a offboard TLS termination work? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
Given that TLS would forbid SNI being present in that case, how would such a offboard TLS termination work? Probably violating the RFC? "We're not the protocol police" ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
On Tue, Apr 23, 2019 at 2:28 PM Michael Richardson wrote: > > Ryan Sleevi wrote: > > The latter only becomes a consideration if multiple IPs are > terminated > > at the same TLS layer, and that TLS termination layer doesn't > consider > > the destination IP when dispatching certificates. If we were to omit > > I am curious to understand the use case for offboard TLS termination by IP > address.That would seem to involve some kind of layer-3 (destination) > NAT. > Given that TLS would forbid SNI being present in that case, how would such > a > offboard TLS termination work? > Right. I wasn't trying to suggest that such servers intended to be responding on 'bare' IP addresses, merely that they were capable of doing so (by virtue of the SNI absence). As commonly configured by a TLS server, all IPs would merely be dispatched to a common 'default' host implementation, *unless* the server used some out-of-band signaling method to determine the 'original' IP. In the cloud provider model, this might be multiple physical IPs all dispatched to a same internal system. The internal system ACLs based on hostname (the original issue with the tls-sni proposal), and thus may not have ACLs on the 'bare hostname' form. Let's say I have 'good.example' (Customer A) resolving to 10.0.0.2, 'evil.example' (Customer B) resolving to 10.0.0.3, and whenever you connect, TLS termination is dispatched to an internal service on 10.0.0.1. Now, the system can already dispatched based on hostname, ensuring that good.example sessions are served Customer A's response, and evil.example sessions are served Customer B's response. The issue is whose response is served when there is no SNI? Under a TLS-ALPN (no-ip) model, there's no restrictions or requirements there; you could serve Customer A, customer B, or neither - and none would undermine the security of TLS-ALPN (as a validation method) or of the security properties you're trying for. In a world where IPs were possible to be validated using TLS-ALPN, and the information omitted from the request, if evil.example/Customer B can serve a certificate that confirms the response for 10.0.0.2, then they could get a certificate for Customer A's IP. In a world where we include the to-be-validated IP in the request, and the Cloud Provider is observing the security invariants required for TLS-ALPN (that any hostnames to be validated have been successfully authenticated as belonging to the customer in question), then Customer B would have to demonstrate control, to the provider, over 2.0.0.10.in-addr.arpa in order to get such a certificate. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
Salz, Rich wrote: mcr> Given that TLS would forbid SNI being present in that case, how mcr> would such a offboard TLS termination work? rsalz> Probably violating the RFC? "We're not the protocol police" Okay, then just put the SNI for the challenge too :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
Ryan Sleevi wrote: > Now, the system can already dispatched based on hostname, ensuring that > good.example sessions are served Customer A's response, and > evil.example sessions are served Customer B's response. The issue is > whose response is served when there is no SNI? Under a TLS-ALPN (no-ip) > model, there's no restrictions or requirements there; you could serve > Customer A, customer B, or neither - and none would undermine the > security of TLS-ALPN (as a validation method) or of the security > properties you're trying for. okay, I'm with you so far. > In a world where IPs were possible to be validated using TLS-ALPN, and > the information omitted from the request, if evil.example/Customer B > can serve a certificate that confirms the response for 10.0.0.2, then > they could get a certificate for Customer A's IP. To do this requires that the cloud provider make a clear decision about what they are going to do with SNI-less requests above.I feel that the cloud provider did something wrong here. > In a world where we include the to-be-validated IP in the request, and > the Cloud Provider is observing the security invariants required for > TLS-ALPN (that any hostnames to be validated have been successfully > authenticated as belonging to the customer in question), then Customer > B would have to demonstrate control, to the provider, over > 2.0.0.10.in-addr.arpa in order to get such a certificate. I see. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
On Tue, Apr 23, 2019 at 4:28 PM Michael Richardson wrote: > > In a world where IPs were possible to be validated using TLS-ALPN, > and > > the information omitted from the request, if evil.example/Customer B > > can serve a certificate that confirms the response for 10.0.0.2, then > > they could get a certificate for Customer A's IP. > > To do this requires that the cloud provider make a clear decision about > what > they are going to do with SNI-less requests above.I feel that the cloud > provider did something wrong here. That's a not-unreasonable position to take, generally speaking, but it's not an invariant that the TLS-ALPN method stated needed to be met. For example, we 'could' just as well introduce yet-another-ALPN method to indicate it's being used to validate an IP address, rather than a domain, and then we can totally omit the IP address (encoded or otherwise) from the TLS handshake, on the assumption that the Service Provider must be responsible for determining the authorization scope. The use of a new ALPN value would be explicit signalling by said Cloud Provider that they're aware of the semantics and the security properties that need to be observed. Fundamentally, TLS-SNI had problems because it relied on implicit/out-of-band state to bind the request to the response (in this case, the binding between the .acme.invalid namespace and the actual customer namespace). As a result, the TLS terminator was not able to dispatch or ACL appropriately. The 'main' contribution of TLS-ALPN was to make the server explicitly signal support for the method, rather than implicitly signal. We could have left the SNI domain as .acme.invalid and still achieved the same security properties - however, moving it to use the 'actual' name, and only dispatch on ALPN, simply made it easier for Cloud Providers to implement safely and securely. That same logic applies here - we 'could' use a distinct ALPN method, in which case, omitting the IP is fine. However, including the IP (albeit, encoded) makes it easier to reason about, dispatch, and less likely to result in implementation flaws, and in particular, given that the draft is reusing the ALPN tag of TLS-ALPN, observes the semantics and security properties required of servers that 'speak' TLS-ALPN. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
Ryan Sleevi wrote: > That same logic applies here - we 'could' use a distinct ALPN method, > in which case, omitting the IP is fine. However, including the IP > (albeit, encoded) makes it easier to reason about, dispatch, and less > likely to result in implementation flaws, and in particular, given that > the draft is reusing the ALPN tag of TLS-ALPN, observes the semantics > and security properties required of servers that 'speak' TLS-ALPN. I ommited your great explanation of the situation. *I* think that certificates bound to IP addresses are useful for things like server management systems (Dell DRACs, HP iLO, IBM RSA..). As such, there are no cloud issues involved. A second use case is for end-systems to get certificates for use in things like TLS ClientCertificates. I can see my desktop or appliances doing this given that they might have a stable IPv6 addresses. Few users would have stable, public IPv4 today though. ACME could still be used to talk to internal CAs though. You have a different use case, and I still don't understand it. Maybe the document needs an applicability statement. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
On Tue, Apr 23, 2019 at 5:18 PM Michael Richardson wrote: > I ommited your great explanation of the situation. > *I* think that certificates bound to IP addresses are useful for things > like > server management systems (Dell DRACs, HP iLO, IBM RSA..). As such, there > are no cloud issues involved. I’m a bit confused by understanding how this bit fits into the discussion. Is the concern that the draft-acme-ip would not work for these cases, and/or that the choice and use of TLS-ALPN (or another identifier) would preclude addressing these use cases? It seems that the applicability of the protocol satisfies all of these use cases, including internal CAs. Have I overlooked a concern with respect to SNI and ALPN? > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Use cases / trust model for device certs
Hi Rifaat, Inline. From: Rifaat Shekh-Yusef Sent: 17 April 2019 20:37 To: Richard Barnes Cc: IETF ACME ; Owen Friel (ofriel) Subject: Re: Use cases / trust model for device certs Hi Richard, I was not aware of the ANIMA work before the meeting in Prague, so I will definitely look into that in details. One use case that I have in mind is a way to make sure that a specific device can only be used by a specific party. If you rely on RP to request identities for the device, then any party that has a valid ACME account can use any device. [ofriel] This is one of the use cases that BRSKI enables. Read the sections relating to Ownership Tracker. For example, if party A purchased a device from the vendor, and party B gets a hold of that device, then there is nothing that prevents party B from getting a valid ACME certificate for that device. [ofriel] With strict ownership tracking, BRSKI is flexible enough to prevent devices from bootstrapping against a network without proof of ownership. If instead you reply on a token from the Device Authority, then the CA will only issue a certificate to a specific party and specific device. [ofriel] The Device Authority appears to perform a similar function to the MASA audit log function. The Client (i.e. customer.com) can claim devices from the DA (via some sales channel/integration API), the DA issues JWTs indicating that the device is claimed by a specific Client, and ACME checks that the requesting Client matches that in the JWT which the DA has logged. The BRSKI MASA service audit logs every single domain that a device has registered against, and does not preclude Registrars claiming devices/proving ownership via some sales channel integration/API. It appears that this proposal is trying to address similar issues as BRSKI. Regards, Rifaat On Wed, Apr 17, 2019 at 1:09 PM Richard Barnes mailto:r...@ipv.sx>> wrote: Hey Rifaat, Owen and I were chatting about ACME and device certs this morning, and it seemed like it might be useful to rekindle discussion on the topic here on the ACME list. I'd like to push a little more on the trust model here. Just to establish some terminology: - Device: Uses certificates to authenticate identifiers - Vendor: Makes the device that will get the end certificate - Customer: Buys the device from the vendor and operates it - CA: Validates identifiers and issues certificates - Relying Party: Uses certificates to verify authentication for identifiers - Device Identity: MAC address or similar In the flows Owen and I have been discussing (more based on ANIMA/BRSKI), the model is basically broken in two, with the customer in the middle: 1. The customer validates devices' device identity as part of the ANIMA flow, based on the customer trusting the vendor, and assigns the device a domain name 2. The customer uses ACME to issue domain name certificates (the CA is unaware of the device identity) That all pretty much just works with BRSKI and ACME as they are today. But it presumes that the RP is authenticating the device by domain name, as is prevalent in most uses of TLS today. In contrast, it seems like your draft presumes that the RP needs to know the device identity; it's not satisfied by a domain name alone. Can you elaborate a bit more on what scenarios you have in mind for this? If all you care about is the customer tracking things, then the model above is sufficient; the customer can simply assign domain names that encode the device identity however it likes. Thanks, --Richard ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
mcr> I ommited your great explanation of the situation. *I* think that mcr> certificates bound to IP addresses are useful for things like server mcr> management systems (Dell DRACs, HP iLO, IBM RSA..). As such, there are mcr> no cloud issues involved. Ryan Sleevi wrote: > I’m a bit confused by understanding how this bit fits into the > discussion. > Is the concern that the draft-acme-ip would not work for these cases, > and/or that the choice and use of TLS-ALPN (or another identifier) > would preclude addressing these use cases? I think your inclusion of TLS-ALPN (which would be new code, vs a few extra scripts, I think) makes the solution more complex that it needs to be, in order to address a use case which I've not been convinced is real. > It seems that the applicability of the protocol satisfies all of these > use cases, including internal CAs. Have I overlooked a concern with > respect to SNI and ALPN? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05
On Tue, Apr 23, 2019 at 10:03 PM Michael Richardson wrote: > > mcr> I ommited your great explanation of the situation. *I* think > that > mcr> certificates bound to IP addresses are useful for things like > server > mcr> management systems (Dell DRACs, HP iLO, IBM RSA..). As such, > there are > mcr> no cloud issues involved. > > Ryan Sleevi wrote: > > I’m a bit confused by understanding how this bit fits into the > > discussion. > > > Is the concern that the draft-acme-ip would not work for these cases, > > and/or that the choice and use of TLS-ALPN (or another identifier) > > would preclude addressing these use cases? > > I think your inclusion of TLS-ALPN (which would be new code, vs a few > extra scripts, I think) makes the solution more complex that it needs to > be, > in order to address a use case which I've not been convinced is real. > I think I'm still confused, then, as it seems this thread has forked from what it was originally discussing. Corey's original question was in the context of including or omitting the SNI - but it seemed uncontroversial that the protocol itself would continue to be signaled via the ALPN method. To omit that signaling would be to fundamentally invite security disaster. However, it seems that's precisely your concern - that independent of the SNI inclusion or omission, it would seem there is concern about requiring the use of ALPN. Is that a correct understanding? If not, it would help if you might clearly state which parts of the draft you find problematic, as I am still missing how this ties into the concerns Corey was raising originally. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
