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
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 14 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 14 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 14 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 14 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 14 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 14 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.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]
Internet-Draft Client Roaming Control April 2022
Client DNS Client FTP Server FTP
FTP USER [email protected]
----------------------------->
...
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 protected]
----------------------------->
...
FTP PASS ********
----------------------------->
Query : CRC ftp.example.com_21.example.org
<------------------------------------
Answer : No such name (3)
------------------------------------>
FTP 430
<------------------------------
5.2. Controlled Application
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]
Internet-Draft Client Roaming Control April 2022
Client DNS Client browser Web application
.....
Client certificate [email protected]
----------------------------------->
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 protected]
----------------------------------->
Query : CRC www.example.com_443.example.org
<------------------------------------------
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.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]
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 14 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 14 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 protected]
Adell Expires 14 October 2022 [Page 11]
Le mar. 12 avr. 2022 à 02:44, Mark Andrews <[email protected]> a écrit :
>
>
>
> > On 11 Apr 2022, at 17:57, Mark Andrews <[email protected]> wrote:
> >
> > 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.
> >
> > ftp.foo.com_21_bar.com,195.13.35.0/24,91.220.43.0/24
> >
> > would be
> >
> > ftp.foo.com._21._crc.bar.com APL 1:195.13.35.0/24 1:91.220.43.0/24
>
>
> 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.
>
> >> On 5 Apr 2022, at 20:52, Eugène Adell <[email protected]> wrote:
> >>
> >> 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 protected]
> >> ----------------------------->
> >> ...
> >> 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 protected]
> >> ----------------------------->
> >> ...
> >> 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 protected]
> >> ----------------------------------->
> >> 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 protected]
> >> ----------------------------------->
> >> 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 protected]
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 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 protected]
> >> 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 protected]
> >> 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
> >> <draft-adell-client-roaming-00.txt><RFC 6895
> >> material.txt>_______________________________________________
> >> DNSOP mailing list
> >> [email protected]
> >> 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 protected]
> >
> > _______________________________________________
> > DNSOP mailing list
> > [email protected]
> > 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 protected]
>
Internet Engineering Task Force E. Adell
Internet-Draft 12 April 2022
Intended status: Informational
Expires: 14 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 14 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 14 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 14 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 14 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 14 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 14 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.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]
Internet-Draft Client Roaming Control April 2022
Client DNS Client FTP Server FTP
FTP USER [email protected]
----------------------------->
...
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 protected]
----------------------------->
...
FTP PASS ********
----------------------------->
Query : CRC ftp.example.com_21.example.org
<------------------------------------
Answer : No such name (3)
------------------------------------>
FTP 430
<------------------------------
5.2. Controlled Application
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]
Internet-Draft Client Roaming Control April 2022
Client DNS Client browser Web application
.....
Client certificate [email protected]
----------------------------------->
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 protected]
----------------------------------->
Query : CRC www.example.com_443.example.org
<------------------------------------------
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.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]
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 14 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 14 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 protected]
Adell Expires 14 October 2022 [Page 11]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
