[gnso-rds-pdp-wg] Definitions: Authentication and Anonymity

Tue May 16 13:21:17 UTC 2017

That's helpful Greg.  Thanks.

Chuck

From: Greg Aaron [mailto:gca at icginc.com]
Sent: Monday, May 15, 2017 11:16 PM
To: Gomes, Chuck <cgomes at verisign.com>; lisa at corecom.com; gnso-rds-pdp-wg at icann.org
Subject: [EXTERNAL] RE: Definitions: Authentication and Anonymity

Dear Chuck:

You can be anonymous but your access can still require authentication.  In Lisa's material below there's an example of an anonymous transaction that is authenticated.

For example, a registry could require you to purchase tokens to be used for making WHOIS queries.  Those tokens don't have to stay linked to your identity.  But requiring their use to make a WHOIS query involves an authentication.

Or you could be required to register your IP address with the registry in order to make WHOIS queries from it.  In this setup you could be anonymous (the registry might not know your  personal identity), but the registry would authenticate that the access is coming from an allowed IP.

This is an exercise in finding loopholes.

One way to think of it is: authentication can be a barrier to data access.

All best,

--Greg

From: Gomes, Chuck [mailto:cgomes at verisign.com]
Sent: Monday, May 15, 2017 9:14 PM
To: Greg Aaron <gca at icginc.com<mailto:gca at icginc.com>>; lisa at corecom.com<mailto:lisa at corecom.com>; gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
Subject: RE: Definitions: Authentication and Anonymity

Greg,

Considering that we already have rough consensus that requestor does not have to be identified, what would need to be authenticated?  In other words, why would we need to add 'without authentication'?

It would be helpful if you could respond to these questions on Tuesday  before our WG meeting on Wednesday considering you will not be able to attend the WG call.

Chuck

From: Greg Aaron [mailto:gca at icginc.com]
Sent: Monday, May 15, 2017 8:14 PM
To: Lisa Phifer <lisa at corecom.com<mailto:lisa at corecom.com>>; Gomes, Chuck <cgomes at verisign.com<mailto:cgomes at verisign.com>>; gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
Subject: [EXTERNAL] RE: Definitions: Authentication and Anonymity

Thanks you, Lisa.

I will be unable to make the next meeting because the 05:00 UTC meeting time.

Based on last week's meeting, I I think we are aiming for something like:

"Thin data elements must be accessible to anonymous requestors, without authentication."

If we say:

"Thin data elements must be accessible without requestor authentication"

then that means consumers of registration data might or might not be anonymous.

For example, a registry operator could make me register my IP address, from which I can query registration data.  Those queries could be made without  authentication (a username/password), and so the registry's registration program could be allowed.  But arguably I would not be anonymous.

Whatever policy  language is proposed must be examined for how it can be interpreted and possibly bypassed.   Both the intent of the WG and the specific language will eventually need to be laid out.

So I also suggest it be made explicit that access to registration data remain free, without charge.

All best,

--Greg

From: Lisa Phifer [mailto:lisa at corecom.com]
Sent: Wednesday, May 10, 2017 12:04 PM
To: Greg Aaron <gca at icginc.com<mailto:gca at icginc.com>>; Gomes, Chuck <cgomes at verisign.com<mailto:cgomes at verisign.com>>; gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
Subject: Definitions: Authentication and Anonymity

All,

Starting a new thread to pursue Greg's suggestion to agree upon definitions for "authentication" and "anonymity" to help the WG address the charter question now under deliberation.

Below are a few definitions copied verbatim from RFC 4949 ( https://tools.ietf.org/html/rfc4949) as a starting point for WG discussion of these and other possible sources/definitions.

Lisa

>From RFC 4949:

 $ anonymity
      (I) The condition of an identity being
unknown or concealed. (See:
      alias, anonymizer, anonymous credential,
anonymous login,
      identity, onion routing, persona
certificate. Compare: privacy.)

      Tutorial: An application may require
security services that
      maintain anonymity of users or other
system entities, perhaps to
      preserve their privacy or hide them from
attack. To hide an
      entity's real name, an alias may be used;
for example, a financial
      institution may assign account numbers.
Parties to transactions
      can thus remain relatively anonymous, but
can also accept the
      transactions as legitimate. Real names of
the parties cannot be
      easily determined by observers of the
transactions, but an
      authorized third party may be able to map
an alias to a real name,
      such as by presenting the institution with
a court order. In other
      applications, anonymous entities may be
completely untraceable.

>From RFC 4949:

$ anonymous login
      (I) An access control feature (actually,
an access control
      vulnerability) in many Internet hosts that
enables users to gain
      access to general-purpose or public
services and resources of a
      host (such as allowing any user to
transfer data using FTP)
      without having a pre-established,
identity-specific account (i.e.,
      user name and password). (See:
anonymity.)

      Tutorial: This feature exposes a system to
more threats than when
      all the users are known, pre-registered
entities that are
      individually accountable for their
actions. A user logs in using a
      special, publicly known user name (e.g.,
"anonymous", "guest", or
      "ftp"). To use the public login
name, the user is not required to
      know a secret password and may not be
required to input anything
      at all except the name. In other cases, to
complete the normal
      sequence of steps in a login protocol, the
system may require the
      user to input a matching, publicly known
password (such as
      "anonymous") or may ask the user
for an e-mail address or some
      other arbitrary character string.

>From RFC 4949:

$ authenticate
      (I) Verify (i.e., establish the truth of)
an attribute value
      claimed by or for a system entity or
system resource. (See:
      authentication, validate vs. verify,
"relationship between data
      integrity service and authentication
services" under "data
      integrity service".)

      Deprecated Usage: In general English
usage, this term is used with
      the meaning "to prove genuine"
(e.g., an art expert authenticates
      a Michelangelo painting); but IDOCs should
restrict usage as
      follows:
      -  IDOCs SHOULD NOT use this term to
refer to proving or checking
         that data has not been
changed, destroyed, or lost in an
         unauthorized or
accidental manner. Instead, use "verify".
      -  IDOCs SHOULD NOT use this term to
refer to proving the truth or
         accuracy of a fact or
value such as a digital signature.
         Instead, use
"verify".
      -  IDOCs SHOULD NOT use this term to
refer to establishing the
         soundness or correctness
of a construct, such as a digital
         certificate. Instead,
use "validate".

>From RFC 4949:

   $ authentication
      (I) The process of verifying a claim that
a system entity or
      system resource has a certain attribute
value. (See: attribute,
      authenticate, authentication exchange,
authentication information,
      credential, data origin authentication,
peer entity
      authentication, "relationship between
data integrity service and
      authentication services" under
"data integrity service", simple
      authentication, strong authentication,
verification, X.509.)

      Tutorial: Security services frequently
depend on authentication of
      the identity of users, but authentication
may involve any type of
      attribute that is recognized by a system.
A claim may be made by a
      subject about itself (e.g., at login, a
user typically asserts its
      identity) or a claim may be made on behalf
of a subject or object
      by some other system entity (e.g., a user
may claim that a data
      object originates from a specific source,
or that a data object is
      classified at a specific security level).

      An authentication process consists of two
basic steps:
      -  Identification step: Presenting
the claimed attribute value
         (e.g., a user
identifier) to the authentication subsystem.
      -  Verification step: Presenting or
generating authentication
         information (e.g., a
value signed with a private key) that acts
         as evidence to prove the
binding between the attribute and that
         for which it is claimed.
(See: verification.)

---------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170516/59948832/attachment-0001.html>