[gnso-rds-pdp-wg] Definitions: Authentication and Anonymity
Paul Keating
Paul at law.es
Thu May 18 10:24:32 UTC 2017
Chuck,
I may be going out on a limb here but wouldn¹t it be appropriate to have the
privacy authorities actually participating in this WG?
There are many opinions floating around in the emails and I see a continuing
pattern of confusion.
Given the importance of the governmental authorities here is it not
rationale to have their direct participation so we can reach a workable
solution?
Paul
From: <gnso-rds-pdp-wg-bounces at icann.org> on behalf of "Gomes, Chuck via
gnso-rds-pdp-wg" <gnso-rds-pdp-wg at icann.org>
Reply-To: "Gomes, Chuck" <cgomes at verisign.com>
Date: Tuesday, May 16, 2017 at 3:14 AM
To: "gca at icginc.com" <gca at icginc.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
> 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/20170518/b4f30f25/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list