[gnso-rds-pdp-wg] Definitions: Authentication and Anonymity
Paul Keating
Paul at law.es
Tue May 16 15:02:07 UTC 2017
Im sorry but not all of the examples below are in fact anonymous:
The transaction to purchase tokens. The anonymity would require that the
tokens themselves not be traceable. I seriously doubt this would be the
case and there would be virtually no way to ensure privacy.
IP addresses. These are in fact known as a result of any contact with a
website. Whether the IP address used is in fact the users is another story.
However, there is an IP WHOIS database just as there is one for domains.
This, however, cannot be helped.
So, I believe the 1st should be prohibited but the 2nd not.
PRK
From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Greg Aaron
<gca at icginc.com>
Date: Tuesday, May 16, 2017 at 5:16 AM
To: "Gomes, Chuck" <cgomes at verisign.com>, "lisa at corecom.com"
<lisa at corecom.com>, "gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
Subject: Re: [gnso-rds-pdp-wg] 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>; lisa at corecom.com; 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>; Gomes, Chuck <cgomes at verisign.com>;
> 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>; 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 <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.)
>
> ---------
> _______________________________________________ gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170516/77ad4e19/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list