Subject: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications

From: Eugène Adell <[email-masked]>
Date: Tue, 5 Apr 2022 12:52:06 +0200

Hello,

I've been working on two new RRTypes described by a Draft, and as
suggested by our magnificent, incredibly brilliant and handsome AD
Warren "ACE" Kumari, I am posting here this idea and the material I
have written so far (the draft itself, and RFC 6895 components).

Briefly, one RRType (CRC : Client Roaming Control) contains a
whitelist of networks allowing a company employees to connect to a
specific application. The second RRType (CRS : Client Roaming Support)
is on the application side and informs what kind of restrictions are
applied (by saying if CRC is mandatory, optional or ignored).
This is not expected to be deployed broadly and everywhere as it is
designed to secure Business-To-Business applications.

The material (text XML2RFC draft + RFC 6895 components) written is
both incorporated below to this email and attached, for practical
reasons.

Regards
E.A.

Internet Engineering Task Force                                 E. Adell
Internet-Draft                                              5 April 2022
Intended status: Informational
Expires: 7 October 2022

                         Client Roaming Control
                     draft-adell-client-roaming-00

Abstract

   This document specifies the Client Roaming Control (CRC) DNS Resource
   Record allowing an organization to better control the access to
   third-party applications over Internet.  The applications
   implementing an authorization mechanism to honor the CRC, publish on
   their side the Client Roaming Support (CRS) Resource Record to inform
   of this support.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 October 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Adell                    Expires 7 October 2022                 [Page 1]

Internet-Draft           Client Roaming Control               April 2022

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   3.  The CRC Resource Record . . . . . . . . . . . . . . . . . . .   4
     3.1.  RR name field . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  CRC RDATA Wire Format . . . . . . . . . . . . . . . . . .   4
     3.3.  CRC Presentation Format . . . . . . . . . . . . . . . . .   4
   4.  The CRS Resource Record . . . . . . . . . . . . . . . . . . .   5
     4.1.  CRS RDATA Wire Format . . . . . . . . . . . . . . . . . .   5
     4.2.  CRS Presentation Format . . . . . . . . . . . . . . . . .   5
   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Restricted Application  . . . . . . . . . . . . . . . . .   6
     5.2.  Controlled Application  . . . . . . . . . . . . . . . . .   7
     5.3.  Opened Application  . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.1.  DNS misconfiguration  . . . . . . . . . . . . . . . . . .   9
     7.2.  DNS Security  . . . . . . . . . . . . . . . . . . . . . .  10
     7.3.  Application Security  . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Illegitimate access to professional restricted applications over
   Internet is a permanent threat for organizations and their staff.
   Different methods can be used to impersonate a user access, and in
   some cases an organization also wants to better prevent its own staff
   to access a third-party application from a network which is not under
   its control.  On the contrary, an organization maybe wants to allow
   roaming then its users can access from different known places.

   The Client Roaming Control (CRC) DNS Resource Record (RR) acts as a
   White-List and informs a compatible application from which networks
   its users are allowed to connect, be it a limited list of networks or
   broadly without any restriction.

Adell                    Expires 7 October 2022                 [Page 2]

Internet-Draft           Client Roaming Control               April 2022

   At the application level, the identification of the user's
   organization domain can be based on an information carried during the
   authentication process, or a lookup on an information already known
   by the application.  In both cases this information lets the
   application relate the user to its organization unequivocally.
   Finally, the corresponding user's domain DNS will be requested with
   the application's FQDN and port, and the application will know
   whether an authorization is expected or not.  Some examples will be
   given in this document.

   The applications implementing this authorization control let the
   client organizations know this feature is available by using the
   Client Roaming Support (CRS) RR.  The data associated with this
   record indicates if the client's organization expected support of the
   CRC is mandatory, optional, or ignored.  This information stored in
   the CRS can be confirmed at the application level by a redundant
   data.  The way the application handles the authorization mechanism,
   by consulting the associated CRS record or not, is left to the
   implementor.

   Although this mechanism is designed for improving the security
   between different organizations, there is no objection to use it for
   a same organization playing both roles of client and application , as
   an alternative or additional layer to a solution already in place,
   such as a firewall for example.

2.  Conventions Used in This Document

   This specification uses definitions from Domain Name System
   [RFC1035], and readers unfamiliar with it can also check DNS
   Terminology [RFC8499].  The syntax specification uses the Augmented
   Backus-Naur Form (ABNF) notation as specified in [RFC5234], with some
   expressions being defined in "Uniform Resource Identifier (URI):
   Generic Syntax" [RFC3986] and "IP Version 6 Addressing Architecture"
   [RFC4291].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Adell                    Expires 7 October 2022                 [Page 3]

Internet-Draft           Client Roaming Control               April 2022

3.  The CRC Resource Record

   The CRC RR purpose is to provide a list of IP ranges authorized to
   use a particular application.  Each RR contains a list of either IPv4
   or IPv6 network address ranges.  These ranges MUST follow the CIDR
   notation.  A single CRC RR MAY contain ranges for different IP
   versions, but in the case of many ranges this can be difficult to
   read or maintain, so dedicating a record to each IP version or not is
   left to the administrator.  Multiple RRs MAY be defined for a given
   IP version.

3.1.  RR name field

   The CRC RR name field is composed of the third-party application
   domain, its port, followed by the fully qualified name inherent in
   this zone.  These three components are separated by the underscore
   character.

3.2.  CRC RDATA Wire Format

   The CRC RDATA wire format is encoded as follows:

       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                     CRC                       /
       /                                               /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   The CRC field contains a list of either IPv4 or IPv6 ranges separated
   by the comma character.

3.3.  CRC Presentation Format

   The presentation format of the CRC record is:

   CRC (ip4netlist [,ip6netlist]) / ([ip4netlist,] ip6netlist)

   ip4netlist = ip4net *(,ip4net)

   ip4net = IPv4address "/" ip4range

   ip4range = DIGIT / "1" DIGIT / "2" DIGIT / "3" DIGIT %x30-32

   ip6netlist = ip6net *(,ip6net)

   ip6net = (ipv6-address "/" prefix-length)

Adell                    Expires 7 October 2022                 [Page 4]

Internet-Draft           Client Roaming Control               April 2022

4.  The CRS Resource Record

   The CRS RR indicates which control is done on the client
   organizations, and thus which ones are authorized.  A requirement
   field is used for this purpose, it has one of the following values
   meaning when the checking is performed :

   *  "N" : Never, all organizations are authorized

   *  "A" : Always, only organizations with a CRC are authorized

   *  "O" : Optional, any organization CRC is honored, other
      organizations are authorized

   In addition to this value, an optional list of ports can be given.
   Indeed, multiple applications can be hosted on different ports under
   the same domain name, and an equivalent support was described for the
   CRC RR.  In case of different requirement values, it is RECOMMENDED
   to have one dedicated RR for each although one single RR with all the
   information is supported.  One particular port MUST NOT appear in
   more than one RR.  When no port is mentioned, only one RR MAY be
   declared and its requirement value covers all applications for this
   domain name.

   In the absence of such record, no roaming control is to be expected
   by the client, any of its CRC RRs will be ignored.  It is equivalent
   to a CRS requirement value indicating no control is performed.

4.1.  CRS RDATA Wire Format

   The CRS RDATA wire format is encoded as follows:

       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       /                     CRS                       /
       /                                               /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   The CRS field contains a list of requirements followed by their
   respective optional ports.

4.2.  CRS Presentation Format

   The presentation format of the CRS record is:

   CRS (single-rule / multiple-rules)

   single-rule = "R=" ("N" / "A" / "O") *(,port)

Adell                    Expires 7 October 2022                 [Page 5]

Internet-Draft           Client Roaming Control               April 2022

   multiple-rules = unit-rule 1*2(;unit-rule)

   unit-rule = "R=" ("N" / "A" / "O") 1*(,port)

   port = [1-9] *([DIGIT])

5.  Examples

   The following examples show some typical uses expected from this
   documentation.  Particularly, the intended behaviors for different
   CRC and CRS values are explained, while the user identification is
   done directly through carried data or a deduction process.

5.1.  Restricted Application

   In this example, an application is only opened to organizations
   publishing their respective allowed networks.  The requirement value
   of the CRS record equals "A", and any organization with an empty or
   missing CRC for this application will be denied access.

   The ftp.foo.com domain is dedicated to hosting an FTP application,
   which extracts the client's domain from the username used during the
   authentication process.  This information is then used for requesting
   the client CRC record and finally comparing its content with the
   client's IP.  The client organization bar.com allows its users from
   its own network 195.13.35.0/24 and from a cloud service located at
   91.220.43.0/24.  A second organization baz.com has no CRC record and
   its users are rejected.

   Application FQDN : ftp.foo.com
   Application CRS record : CRS R=A,21

   Client FQDN : bar.com
   Client organization CRC record : CRC
   ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24

   Client FQDN : baz.com
   No client organization CRC record

Adell                    Expires 7 October 2022                 [Page 6]

Internet-Draft           Client Roaming Control               April 2022

   Client DNS  Client FTP                Server FTP

                     FTP USER [email-masked]
               ----------------------------->
                            ...
                     FTP PASS ********
               ----------------------------->
          Query : CRC ftp.foo.com_21_bar.com
        <------------------------------------
          Answer : CRC ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24
        ------------------------------------>
                     FTP 230
              <------------------------------

                     FTP USER [email-masked]
               ----------------------------->
                            ...
                     FTP PASS ********
               ----------------------------->
          Query : CRC ftp.foo.com_21_baz.com
        <------------------------------------
          Answer : No such name (3)
        ------------------------------------>
                     FTP 430
              <------------------------------

5.2.  Controlled Application

   The foo.com domain hosts a Web application on port 443 using client
   certificates for authenticating its users.  The application extracts
   the client domains from the certificates, which are used to retrieve
   their CRC records.  Users from the bar.com organization are allowed
   only if they connect from an authorized network listed in the CRC
   record, while users from baz.com are always granted access since this
   one has no CRC declared.

   Application FQDN : foo.com
   Application CRS record : CRS R=A,443

   Client FQDN : bar.com
   Client organization CRC record : CRC
   ftp.foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24

   Client FQDN : baz.com
   No client organization CRC record

Adell                    Expires 7 October 2022                 [Page 7]

Internet-Draft           Client Roaming Control               April 2022

   Client DNS  Client browser                Web application

                             .....
                 Client certificate [email-masked]
               ----------------------------------->
          Query : CRC foo.com_443_bar.com
        <------------------------------------------
          Answer : CRC foo.com_443_bar.com,195.13.35.0/24,91.220.43.0/24
        ------------------------------------------>
                             .....
                     200 OK
               <-----------------------------------

                             .....
                 Client certificate [email-masked]
               ----------------------------------->
          Query : CRC foo.com_443_baz.com
        <------------------------------------------
          Answer : No such name (3)
        ------------------------------------------>
                             .....
                     200 OK
               <-----------------------------------

5.3.  Opened Application

   A company is testing the CRC and CRS behaviors before opening a new
   service to its customers.  Its first test described below consists in
   configuring both sides to be completely opened, likely before
   hardening the CRS, then the CRC, and testing again.

   The application.foo.com domain hosts a Web application on port 443
   where users are logged in by sending a numerical identifier and a
   password.  The application uses a dictionary data type to identify
   the user's domain.  The client.foo.com domain is temporarily using 2
   CRC records indicating a free access from anywhere.

   Application FQDN : application.foo.com
   Application CRS record : CRS R=N,443

   Client FQDN : client.foo.com
   Client organization CRC records : CRC
   application.foo.com_443_foo.com,0.0.0.0/24; CRC
   application.foo.com_443_foo.com,fe80::/10

Adell                    Expires 7 October 2022                 [Page 8]

Internet-Draft           Client Roaming Control               April 2022

   Client DNS  Client browser                Web application

                             .....
                 HTTP POST 123456/******
               ----------------------------------->
                     200 OK
               <-----------------------------------

6.  IANA Considerations

   According to Guidelines for Writing an IANA Considerations Section in
   RFCs [RFC8126] it is asked to IANA to add into the Resource Record
   (RR) TYPEs registry located at https://www.iana.org/assignments/dns-
   parameters/dns-parameters.xhtml#dns-parameters-4 the two entries CRC
   and CRS.

           +------+-------+------------------------+-----------+
           | TYPE | Value | Description            | Reference |
           +------+-------+------------------------+-----------+
           | CRC  | TBD1  | Client Roaming Control | this RFC  |
           +------+-------+------------------------+-----------+
           | CRS  | TBD2  | Client Roaming Support | this RFC  |
           +------+-------+------------------------+-----------+

                                  Table 1

7.  Security Considerations

   This section is meant to inform developers and users of the security
   implications of the CRC/CRS mechanism described by this document.
   While the CRS RR mostly plays an informative role, the CRC RR
   delivers important data which requires attention from the developers
   and administrators.  Some particular points are discussed here.

7.1.  DNS misconfiguration

   Any DNS CRS misconfiguration such as multiple records with different
   requirement values but with the same port value can get a client
   confused.  In this case the client does not know without testing the
   actual configuration, if its organization is protected against
   roaming, and contacting the application administrator to fix the
   situation is a possibility.

   While CRC misconfigurations are more or less leading to serious
   security problems, administrators need to pay attention when dealing
   with multiple networks or records.  Particularly, multiple records
   for the same network range or overlapping networks should be avoided.

Adell                    Expires 7 October 2022                 [Page 9]

Internet-Draft           Client Roaming Control               April 2022

7.2.  DNS Security

   Client and application administrators need to pay as much attention
   as they usually do when dealing with DNS management.  As the CRC
   records are supposed to be requested during an application
   authentication process, reflection attacks could be built to target a
   client organization, even one not hosting any CRC record at all.
   In a general manner, administrators may consider an adequate TTL
   setting to not overload client organizations, enable TCP as the
   preferred transport, or rely on DNSSEC to warrant data authenticity
   and integrity.

7.3.  Application Security

   The following points are of concern to developers:

   Encryption:
   Whenever possible, the application protocol should be encrypted to
   prevent eavesdropping and man-in-the-middle attacks.  It is a
   critical point for applications maintaining a user session with
   anything like a token or cookie, as it can lead to session hijacking
   as discussed below.

   Timing attack:
   All authentication systems need to be careful to not deliver any
   information derived from the computing time to a denied user, even
   the ones involving multiple factors or steps like the one described
   in this document.  In particular, the order in which these steps are
   executed and their respective implementations, need to defeat
   statistical hypotheses.

   Intermediate systems:
   Some applications are not directly Internet facing and cannot access
   to the real client's IP address without involving a mechanism to
   forward this IP at the application layer.  For example with HTTP, the
   common practice based on the non-standard X-Forwarded-For header, or
   its alternative standard Forwarded [RFC7239], are playing this role.
   Such practice requires a correct sanitizing of user data to avoid
   false injected IPs.

   Session hijacking:
   A well-known attack called Session Hijacking is not meant to be
   defeated by this document alone.  Application developers must ensure
   that any receveid session token, such as an HTTP Cookie, belongs to
   the same IP address than the one which started this session.

8.  References

Adell                    Expires 7 October 2022                [Page 10]

Internet-Draft           Client Roaming Control               April 2022

8.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC7239]  Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
              RFC 7239, DOI 10.17487/RFC7239, June 2014,
              <https://www.rfc-editor.org/info/rfc7239>.

   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

Author's Address

   Eugene Adell
   Email: [email-masked]

Adell                    Expires 7 October 2022                [Page 11]

RFC 6895 :
A. Submission Date:2002/04/05
B.1 Submission Type:  [X] New RRTYPE  [ ] Modification to RRTYPE
B.2 Kind of RR:  [X] Data RR  [ ] Meta-RR
C. Contact Information for submitter :
   Name: Eugene Adell               Email Address: [email-masked]
   International telephone number: +33699056914
   Other contact handles:
D. Motivation for the new RRTYPE application.
   Introduce a couple of RR types working together in order to better
secure remote access to partner applications
E. Description of the proposed RR type.
   CRC contains a limited list of authorized networks for a particular
application
F. What existing RRTYPE or RRTYPEs come closest to filling that need
and why are they unsatisfactory?
   TXT RRTYPE allows the storage of any text data but in practice is
usually associated with more or less fixed name or data which is not
what is needed here. A dedicated RRTYPE is easier to identify and
manage by a security team other than the usual DNS operator team.
G. What mnemonic is requested for the new RRTYPE (optional)?
   CRC
H. Does the requested RRTYPE make use of any existing IANA registry or
require the creation of a new IANA subregistry in DNS Parameters?
   It uses the existing Resource Record (RR) TYPEs registry
I. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being processed as an
unknown RRTYPE (see [RFC3597])?
   No
J. Comments:
   None

A. Submission Date:2002/04/05
B.1 Submission Type:  [X] New RRTYPE  [ ] Modification to RRTYPE
B.2 Kind of RR:  [X] Data RR  [ ] Meta-RR
C. Contact Information for submitter :
   Name: Eugene Adell               Email Address: [email-masked]
   International telephone number: +33699056914
   Other contact handles:
D. Motivation for the new RRTYPE application.
   Introduce a couple of RR types working together in order to better
secure remote access to partner applications
E. Description of the proposed RR type.
   CRS contains a requirement value and a list of ports indicating
what kind of authorization check is done during the application
authentication process
F. What existing RRTYPE or RRTYPEs come closest to filling that need
and why are they unsatisfactory?
   TXT RRTYPE allows the storage of any text data but in practice is
usually associated with more or less fixed name or data which is not
what is needed here. A dedicated RRTYPE is easier to identify and
manage by a security team other than the usual DNS operator team.
G. What mnemonic is requested for the new RRTYPE (optional)?
   CRS
H. Does the requested RRTYPE make use of any existing IANA registry or
require the creation of a new IANA subregistry in DNS Parameters?
   It uses the existing Resource Record (RR) TYPEs registry
I. Does the proposal require/expect any changes in DNS
servers/resolvers that prevent the new type from being processed as an
unknown RRTYPE (see [RFC3597])?
   No
J. Comments:
   None

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 8 Apr 2022 20:17:45 +0000

Hi Eugène, I read through the draft and have a few suggestions for you to consider:

1) The CRS and CRC RDATA fields have a lot in common with TXT records.  On one hand you might find some benefits from making these new RR types have the same parsing, wire format, and presentation format as TXT records.  But on the other hand, that probably limits the ability to perform syntax checking by an authoritative name server.  Maybe get some advice from DNS implementors on this topic.

2) You should use documentation domains (and addresses).  i.e., example.com instead of foo.com.

3) Your example records should appear just like they would in a zone file.  Maybe something like

   ftp.example.com. IN CRS R=A,21

4) Separation of components with underscore doesn’t seem right to me.  You give an example as “ftp.foo.com_21_bar.com”.  This creates an (invalid) second-level domain com_21_bar.com, unless I misunderstand?

5) Can you include an example of how the CRS record would be used?

DW

> On Apr 5, 2022, at 3:52 AM, Eugène Adell <[email-masked]> wrote:
> 
> Hello,
> 
>   Drafts is at https://secure-web.cisco.com/1UBqNqOD0_avjtr-YY-q-eOgfcaadfGerG9mW2JKKCseQ6aQaNm9QI-n8SuZkYw5t3JNht-Q9J7Rm-gnPlrXziremyFm_V8D8YJFTTFXgbwuIBkM31ZDkVZ0ju3DB6jaSp9Gvl-zasI8yMM5-y_L6zcd3pZpl12yx-Ce3cvOa78uMtfsHXHfqwi14IFXFgM4ewkKVmTEh-fRKoYNtQgjF4mYpOeWa6f3_GjEGk8dFhJF8Qp5l6krpaXilrI5-xbaK/https%3A%2F%2Fdatatracker.ietf.org%2Fdrafts%2Fcurrent%2F
> 
>   Provisions Relating to IETF Documents (https://secure-web.cisco.com/1pg6-wEhXfN-MwhlJ8h7eo-dAl8QdPmldrdMCuN3mEiaCnFsh9HG5WhXZw-WEUmYPUG_F8vGvkIMWnnM80xdkIwd-AdtVO6TCmShu7Bo_OylP4MgMT0Ut4BSdIqUb5Xlol0HIRKB7BmOs5qtg9JJGujEqkzltu9NlRMKSI1ObJUrEPBcSPTgygo2upt2hUiCWfhjnT327rbhdg4D3k4C4L6J-i0c7KJmkeyW0tOOw3djsz6RiFYqqLcmtiOqhPBH1/https%3A%2F%2Ftrustee.ietf.org%2F
>   (RR) TYPEs registry located at https://secure-web.cisco.com/1Jj52xRBw7c84a4iFd46OaUQbxDpAnbYC_GR0K7iUgFqK_Etzn6MXkOdkSk8OW4ud0zb-dGQ8CkpXTgl7bexGe4ZGkyN7y-sdmUFRfkXbY_pCvPsoq564DriiSyhScPnBt4dFctHrb_Lfvq1cO2DEo8eE84urRLOagx3RhYCTulRauRWFqGCu7NOXjJ2RQZvPmFbEJCFz91tD1UDtw5APZAX5CJMyb8WxLKtd9szyHdP6YryWeImRJ0joEubPY3X7/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fdns-
>              November 1987, <https://secure-web.cisco.com/1nfs5RO2YtQvqtJDoeTJk-QnqBPFQ3HGz6q_HgfaJ_vcrAt1WmKyJN0KB1l74bZyRECzGlPQLW71YuKs5NBOyS9MemQxTiVH5InL363097PHFR4e7OzF3-kk5Gu4dOBjZHas0Z9ZCcihPtZELkh90l1HV1LbcriIowdegPwNa_rFZkLDzvvnxxpe3idkMnQXKCCNhvxmKy5qiP2W2UMiUNk9SnvwKtlKk7kZ-VNOjOI4Bfcn1_-tp1_7Jn8P6lXC7/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc1035>.
> 
>              <https://secure-web.cisco.com/1ZQ7hLBYoCtlJ4QuyP0nAAOW6l2IHMxWWnHswjdijDSj4TGACFthOaBn5uJ5k53kNOXU2JCh5iBnIzTBQf2f20mesh2kpgIO1qoO-YRSVci74VHYA88YvGmlA9G5o0jiftts94bsjj4VQeY32J3ThiIcHibP0WV8PZomZ9v2LXybWkymUWp78h6hF8XjTodWSUf1yfHFSeNPt4La3OE2V60fGe5jjWWVLkxQWpFBu54F5-BIR8rUCVDJaljQ4TFhA/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc2119>.
> 
>              <https://secure-web.cisco.com/1rgLZq5bN54jDr34TGjfpMtGyv97g-f0F2KAQgY8NJT8Ot3cqzAyqnCGRGtKLtcaDZarn1C2sZ-P921R1SCoTGBjdlyhS6O117gce8g5ir6am0fny6gD-rdi6AcfMzjzag_4ynmufnGAETAwJ3iipcUo1Cdc9uAiD0SNnPRw5J6_xs5TCpNAotGmAssmtlfTIG6aMWwOT25gWJO7WQPiI6TI6TKedMTu-sAJLty6bookEHL4yTYg-W8pHaONZyeZD/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc3986>.
> 
>              2006, <https://secure-web.cisco.com/1v_viCQbZXurSnKFyMzXNLC851TzJM9CBnd5Q2QFy1eYFPpOlmBjRyKOzAk7rArdIkJh2hX9tYOZBmplz2FdgC_X9PDoWXojicRsj3k-CoPrTVEbBYgKcJqNP-eeEV3FBPdj21kPeueKi6uTTySSOD90W-jIkIyt5KoDFXTryNW5toR3hfSPJKHZS3QIJkulXuhwQhEv7TPjLvHfFH3CDrcXQ5J3PHyYX068YXhAIshD6EUuxRb1-_JpdgpSirxi9/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc4291>.
> 
>              <https://secure-web.cisco.com/1-XBxNJmROwGorSd9ZAYSzrsyQVY0ZqomKX8mtaCBwNjLB53l_aaKML4Q7PSYLWWjFpHo0VXdZ6Vwf0S0gNj38OPc2jPpOPQiABECimPX49rqOOhRqL55Cg4AWuqJd3qJHDin5QaUt2k3XkkpqcbnHwyMVCsbKDzj6mBMN2i9BdpTsPrazP_Y5FmXroihhpi-7Y2o5wt7IT4AWI_wTXbx5OAHdjOYHvdh2gf61DyjSY-FLGB-JQ5ISS22Li9O4VlM/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc5234>.
> 
>              May 2017, <https://secure-web.cisco.com/1PHauMnxLnH0uOzjjcwjU9WHYT_3GUCAyh940Le9MK3Hp-V80v1zMQf6kI6GD0Cg4GtrWUU8j_rT7SvIrphLdzCyy8XUgi3pk3PQRYuqKiJAg0pMLAsna8I27WTkdGFkDivJAUYgqgjXAe07VT26Sgsbea4CKdYm7QN5ZKe2Mjit8wTllP7j8oXGQQNmGLuJDSb_zj2z-QfViXoglUgaIuWhZu61kyV1v9i0PHKiOJMFBi8VFCs8DD4EBrZj0XwSX/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8174>.
> 
>              <https://secure-web.cisco.com/1fXDfMQlrAJUofHpSbsehGWh_ngm9xlL6YUBD9iQQ7lTVvxhk1Fi1NNCFu_8H_gVgCddHWUqmI1D9wfcjA0Ax8SB16K_kdDVHFLjKArgmaPUv6Rw9eq5njENYdEag-AgAWDlzqoFvD7EMkq-ZIdVHOic334MVnS9kwNlohOOTv59x941-34suDs6ScFw76a6-FG6YfVlaP1DRA7K3IJBzyLPtsBZO_bVG6hwJx53_64F851BLjNFHn-okGwfx8te9/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc7239>.
> 
>              January 2019, <https://secure-web.cisco.com/187BuRPcBLr9sSRMgxv5-DrygqomNG-K0jDfpF6FL-DSbsP8CE93gzczzdtZ9TscU37amqurrlUf8q9-UbzmOyBMzmsc52rcwpIMEZDPpMAaJACuNPbVhBwz9qas_7fNF7JSA4B4pjTMjk-seVd4R8KGDvEaPxg0KnKAhc6SOOvCFczE1Xr7XvnF-jSR-C_4Usk6FSnX4KTXjeo7YWIa1Rv_ovl3yQHfj-tnJh0D2KkJD5Jpt1QGd-Hu4v6yEhsr6/https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8499>.
> 
> Author's Address
> 
>   Eugene Adell
> <draft-adell-client-roaming-00.txt><RFC 6895 material.txt>_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://secure-web.cisco.com/19o-OO36Zn-GeLXOPXuSLMyoOaYBf1ckHPvQItfMU41GsWe5L5OsTZTx4CQoLHa5v19NT9Wb_qT8VNltP-qtHLMIQLmJzg8OgMZDca-ghzt5tm5knXB8dN05qqPjFYb7HRYRbSLhtBIDSiw-clQz1o-YgxSKlxHF14kxJt1YYJr4MGwClnqLICCnapNKTiuQaO0K6db34mwhzeNFbs4XrBV6AWXYueErPN9uojTLp7TBCSM5aBx3Cs7JRMxBdtW7z/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop

---

From: Mark Andrews <[email-masked]>
Date: Mon, 11 Apr 2022 17:57:53 +1000

I don’t see why APL (RFC 3123) can’t be used for CRC give you need to construct an
owner name anyway and have well known label to seperate the components of the name.
I see no reason to re-invent the wheel here.

would be

ftp.foo.com._21._crc.bar.com APL 1:195.13.35.0/24 1:91.220.43.0/24

> On 5 Apr 2022, at 20:52, Eugène Adell <[email-masked]> wrote:
> 
> Hello,
> 
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Apr 2022 10:43:54 +1000

> On 11 Apr 2022, at 17:57, Mark Andrews <[email-masked]> wrote:
> 

Additionally text is a really bad way to transmit IP address and prefixes
in the DNS.  DNS RRsets are resource constrained (maximum < 64k).  DNS caches
are resource constrained.  10-16 octets of text for an IPv4/24 vs 7 octets for APL.
An IPv4/8 is 9-11 vs 5 octets.  The :: improves this a little bit for IPv6 but in
general you will be dealing with /48’s or longer xxxx:xxxx:xxxx::/48 (19 octets)
vs 10 for APL.

> _______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Eugène Adell <[email-masked]>
Date: Tue, 12 Apr 2022 12:27:48 +0200

Hello,

thanks for your constructive comments. My answers are just below, with
an updated document (from Duane's remarks, Mark's ones will follow
later).

1.
Beyond the technical aspects, there are several different persons to
think about in our case : the DNS administrator obviously, the
decision maker buying (or not) a secured online service, and the CISO.
It looks more simple to have dedicated RR types to let them
communicate together, without any information distortion. It's
necessary to explain that the CRS record can play two roles : of
course being involved during the authorization mechanism, and as an
information for existing or potential customers checking this
mechanism support before subscribing to a new service. In that case,
any decision maker or CISO can check by himself without sorting all
the TXT records found.

@Mark : I am just discovering the APL RR now as I didn't notice it
when checking what could be reused. It fits the needs of the CRC, with
a different syntax, and likely it's still potentially easier to
identify when building an inventory of what CRC-CRS contracts an
organization has.

2.
I updated for compliance with RFC2606 & RFC5737

3.
Updated so

4.
After your comments and correcting a typo, it gives
ftp.example.com_21.example.net
Such domain name for sure doesn't exist and uses the underscore
character as separator. It has to be considered as storing data
establishing a kind of contract between the two organizations
involved.

5.
I give some explanation in the answer 1 but I will rephrase. The CRS
record can be used before subscribing to a service (typically any
storage/log system/SIEM) as an indicator that this service provides
the kind of authorization process described in the document. More
importantly, it can be checked by the application during the
authentication to know if the client CRC must be checked or not.
However, if an application doesn't want to rely on the CRS RR, it also
can use a parameter in its configuration file. Maybe adding a schema
would help ? At least, I tested all that prior to sending my first
email, with NSD and a modified Apache Tomcat, and I got the results I
wanted.

Internet Engineering Task Force                                 E. Adell
Internet-Draft                                             12 April 2022
Intended status: Informational
Expires: 14 October 2022

                         Client Roaming Control

Abstract

Status of This Memo

   This Internet-Draft will expire on 14 October 2022.

Copyright Notice

Adell                    Expires 14 October 2022                [Page 1]

Table of Contents

1.  Introduction

Adell                    Expires 14 October 2022                [Page 2]

Adell                    Expires 14 October 2022                [Page 3]

3.1.  RR name field

Adell                    Expires 14 October 2022                [Page 4]

Adell                    Expires 14 October 2022                [Page 5]

   port = [1-9] *([DIGIT])

5.  Examples

   The ftp.example.com domain is dedicated to hosting an FTP
   application, which extracts the client's domain from the username
   used during the authentication process.  This information is then
   used for requesting the client CRC record and finally comparing its
   content with the client's IP.  The client organization example.net
   allows its users from its own network 192.0.2.0/24 and from a cloud
   service located at 198.51.100.0/24.  A second organization
   example.org has no CRC record and its users are rejected.

   Application FQDN : ftp.example.com
   Application CRS record : ftp.example.com.  IN CRS R=A,21

   Client FQDN : example.net
   Client organization CRC record : ftp.example.com_21.example.net.  IN
   CRC 192.0.2.0/24,198.51.100.0/24

   Client FQDN : example.org
   No client organization CRC record

Adell                    Expires 14 October 2022                [Page 6]

                     FTP USER [email-masked]
               ----------------------------->
                            ...
                     FTP PASS ********
               ----------------------------->
          Query : CRC ftp.example.com_21.example.net
        <------------------------------------
          Answer : CRC ftp.example.com_21.example.net
192.0.2.0/24,198.51.100.0/24
        ------------------------------------>
                     FTP 230
              <------------------------------

                     FTP USER [email-masked]
          Query : CRC ftp.example.com_21.example.org

   The www.example.com domain hosts a Web application on port 443 using
   client certificates for authenticating its users.  The application
   extracts the client domains from the certificates, which are used to
   retrieve their CRC records.  Users from the example.net organization
   are allowed only if they connect from an authorized network listed in
   the CRC record, while users from example.org are always granted
   access since this one has no CRC declared.

   Application FQDN : www.example.com
   Application CRS record : www.example.com.  IN CRS R=O,443

   Client FQDN : example.net
   Client organization CRC record : www.example.com_443.example.net.  IN
   CRC 192.0.2.0/24,198.51.100.0/24

   Client FQDN : example.org
   No client organization CRC record

Adell                    Expires 14 October 2022                [Page 7]

                             .....
                 Client certificate [email-masked]
               ----------------------------------->
          Query : CRC www.example.com_443.example.net
        <------------------------------------------
          Answer : CRC www.example.com_443.example.net
192.0.2.0/24,198.51.100.0/24
        ------------------------------------------>
                             .....
                     200 OK
               <-----------------------------------

                             .....
                 Client certificate [email-masked]
               ----------------------------------->
          Query : CRC www.example.com_443.example.org
        <------------------------------------------
          Answer : No such name (3)
        ------------------------------------------>
                             .....
                     200 OK
               <-----------------------------------

5.3.  Opened Application

   The application.example.com domain hosts a Web application on port
   443 where users are logged in by sending a numerical identifier and a
   password.  The application uses a dictionary data type to identify
   the user's domain.  The client.example.net domain is temporarily
   using 2 CRC records indicating a free access from anywhere.

   Application FQDN : application.example.com
   Application CRS record : application.example.com.  IN CRS R=N,443

   Client FQDN : client.example.net
   Client organization CRC records :
   application.example.com_443.example.net.  IN CRC 0.0.0.0/24
   application.example.com_443.example.net.  IN CRC fe80::/10

Adell                    Expires 14 October 2022                [Page 8]

                             .....
                 HTTP POST 123456/******

6.  IANA Considerations

                                  Table 1

Adell                    Expires 14 October 2022                [Page 9]

7.2.  DNS Security

   Encryption:

   Timing attack:

   Intermediate systems:

   Session hijacking:

8.  References

Adell                    Expires 14 October 2022               [Page 10]

Author's Address

   Eugene Adell

Adell                    Expires 14 October 2022               [Page 11]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Apr 2022 08:28:06 -0400 (EDT)

> decision maker buying (or not) a secured online service, and the CISO.

Why should this information exchange happen via DNS?

> communicate together

It seems a REST API using some .well-known HTTPS link seems a better
fit ?

> establishing a kind of contract between the two organizations

It should have a dot in between, eg ftp.example.com._21.example.net.
Then, the underscore name should be uniquely identifying to split it
from other DNS records. eg _crs or something. Have a look at other
documents at https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

> the kind of authorization process described in the document.

I still wonder if DNS is really the right fit for this.

>   their side the Client Roaming Support (CRS) Resource Record to inform

There is a big overlap here with MUD, see https://datatracker.ietf.org/doc/html/rfc8520

It also seems the source of authorization depends on the DNS name, but
how do you ensure a device would not be lying about their name? Would
this only work on zones with static DNS entries? If so, how would that
scale?

What would be the mechanism to authorize the publishing of CRS/CRC
records, and why can that provisioning protocol not also be used
to query/signal this data?

Paul

---

From: Eugène Adell <[email-masked]>
Date: Tue, 12 Apr 2022 16:14:34 +0200

Hi Paul,

in the implementation I suggested, the new DNS RR types are not used
for making people (administrator, decision-maker, CISO) communicating
together but as an information source that is simple enough to be
understood by everyone without the need of filtering and sorting data.
I commented that to explain why new types are necessary, although CRC
can be replaced with APL.

Why use DNS at all ? Likely many server software can be modified to
use the implementation suggested, while creating dependencies to
another protocol not already supported by the server looks worse. For
example, it's maybe not a good idea to update an FTP or LDAP server to
support HTTP only to download a text file containing these networks
allowed. And they would probably still need to start by a DNS request
to find that file.

If the Client DNS (CRC) is lying or not configured as asked by the
CISO, the client organization might expose data and it's an internal
threat to this organization. If the server DNS (CRS) is lying, the
client organization might complain as the contract (if any) is not
honored. If all is implemented/configured correctly and one client is
lying on its identity (wrong information sent during the
authentication for example), there is a mismatch between its real and
expected IP addresses, and no authorization at the end.

The use-case I'm thinking about is indeed for static entries handled
manually. In my past experience, I would say each company I worked for
would have benefited of some similar entries (5~10) without thinking
"big". The mechanism to authorize these records is somewhat
administrative for the CRC (the decision-maker asks the CISO who in
turns asks the DNS admin to add a record), and limited for the CRS (a
new application is brought online, with its own domain name, and an
associated CRS record). As it's intended for Business-to-business,
both parts still agree by another kind of contract, and I don't any
necessity to have something more for the provisioning.

E.A.