Hi I see that our milestones still contain a DANE with IPsec document, although the WG has not yet discussed or adopted such a document.
There is one proposed document (draft-osterweil-dane-ipsec). That one ties DANE to opportunistic encryption. While interesting, I think we need a far more basic document. This is what I would like to propose. IPsec as defined in RFC 4301 has a static configuration. Specifically, there is a data structure called PAD (peer authorization database). This structure contains a list of peers authorized to communicate with this IPsec entity, and for each such peer the following: - protocol and method for authentication - authentication data - constraints on the types and values of IKE IDs sent. - location, such as IP address (or DNS name). For example, we might have a peer that will use IKE with certificates to authenticate, its certificate will have an alternate name that says “vpngw”, It will send an ID payload that says “VPN Gateway” and it’s located at 192.0.2.5. What I can see DANE doing is reducing many of those fields in the PAD to a single field: and FQDN. So a PAD record for a peer when DANE is used will have: - protocol and method (IKE with DANE) - FQDN: as in vpngw.example.com <http://vpngw.example.com/> The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP address and a DANE record. The DANE record can be used to identify the certificate or raw public key used in IKE. And the document can specify what the ID payload looks like: in all likelihood the FQDN itself is a good idea. Similar to the way a TLS client gives the TLS server a hint of identity using SNI, IKE has an IDr payload in the IKE_AUTH request which should perform a similar function. What do people think? Yoav
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
