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

Tue May 16 00:13:50 UTC 2017

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>; Gomes, Chuck <cgomes at verisign.com>; 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/82d93ee6/attachment-0001.html>