[gnso-rds-pdp-wg] Definitions: Authentication and Anonymity
Stephanie Perrin
stephanie.perrin at mail.utoronto.ca
Thu May 18 15:21:10 UTC 2017
Unless I have missed something, we have not responded (nor reviewed in
group) the responses the DPAs sent to our last set of questions. I
would recommend that new members take a look at those answers before we
ask new ones.
Stephanie Perrin
On 2017-05-18 08:44, Gomes, Chuck via gnso-rds-pdp-wg wrote:
>
> Paul,
>
> They would of course be welcome. I would like to point out that Peter
> Kimpian is one of them and is a WG member.
>
> Chuck
>
> *From:* Paul Keating [mailto:Paul at law.es]
> *Sent:* Thursday, May 18, 2017 6:25 AM
> *To:* Gomes, Chuck <cgomes at verisign.com>; gca at icginc.com;
> lisa at corecom.com; gnso-rds-pdp-wg at icann.org
> *Subject:* [EXTERNAL] Re: [gnso-rds-pdp-wg] Definitions:
> Authentication and Anonymity
>
> 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
> <mailto: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
> <mailto:gnso-rds-pdp-wg at icann.org>>
> *Reply-To: *"Gomes, Chuck" <cgomes at verisign.com
> <mailto:cgomes at verisign.com>>
> *Date: *Tuesday, May 16, 2017 at 3:14 AM
> *To: *"gca at icginc.com <mailto:gca at icginc.com>" <gca at icginc.com
> <mailto:gca at icginc.com>>, "lisa at corecom.com <mailto:lisa at corecom.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>"
> <gnso-rds-pdp-wg at icann.org <mailto: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 <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
> <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
> <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>
>
>
> _______________________________________________
> 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/aada5033/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list