[gnso-rds-pdp-wg] Definitions: Authentication and Anonymity
Paul Keating
Paul at law.es
Tue May 16 13:16:22 UTC 2017
Thanks Chuck.
I have always understood there to be formal consensus and one that works
more gradually, shaping the future conversations and narrowing to the final
outcome.
From: "Gomes, Chuck" <cgomes at verisign.com>
Date: Tuesday, May 16, 2017 at 3:03 PM
To: Paul Keating <paul at law.es>, "vgreimann at key-systems.net"
<vgreimann at key-systems.net>, "gnso-rds-pdp-wg at icann.org"
<gnso-rds-pdp-wg at icann.org>
Subject: RE: [gnso-rds-pdp-wg] Definitions: Authentication and Anonymity
> Paul,
>
> It is important to remember that we will not formally measure consensus until
> we get close to finalizing our reports to the community. In the meantime, we
> determine rough consensus using discussion in at least one meeting followed by
> a poll and, when that is not possible, we discuss the issues in multiple
> meetings with the understanding that we can always revisit interim tentative
> conclusions that we reach.
>
> Chuck
>
>
> From: Paul Keating [mailto:Paul at law.es]
> Sent: Tuesday, May 16, 2017 8:57 AM
> To: Gomes, Chuck <cgomes at verisign.com>; vgreimann at key-systems.net;
> gnso-rds-pdp-wg at icann.org
> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Definitions: Authentication and
> Anonymity
>
>
> I agree which is why I supported the change of times.
>
>
>
> However, I also stated that it essentially duplicated calls because consensus
> must be measured across more than one call IMHO.
>
>
>
> PRK
>
>
>
> 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 2:46 PM
> To: "vgreimann at key-systems.net" <vgreimann at key-systems.net>,
> "gnso-rds-pdp-wg at icann.org" <gnso-rds-pdp-wg at icann.org>
> Subject: Re: [gnso-rds-pdp-wg] Definitions: Authentication and Anonymity
>
>
>>
>> I understand the difficulty of participating in the middle of the night and
>> do not criticize anyone for not doing so, but I do think it is important to
>> realize that WG members from the Asia Pacific region have that problem for at
>> least 3Ž4 of our meetings.
>>
>> Chuck
>>
>>
>> From:gnso-rds-pdp-wg-bounces at icann.org
>> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Volker Greimann
>> Sent: Tuesday, May 16, 2017 4:54 AM
>> To: gnso-rds-pdp-wg at icann.org
>> Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Definitions: Authentication and
>> Anonymity
>>
>> Same here. That time is just not workable for me.
>>
>>
>>
>> Am 16.05.2017 um 02:13 schrieb Greg Aaron:
>>> 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
>>> 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
>>
>>
>>
>> --
>> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>>
>> Mit freundlichen Grüßen,
>>
>> Volker A. Greimann
>> - Rechtsabteilung -
>>
>> Key-Systems GmbH
>> Im Oberen Werk 1
>> 66386 St. Ingbert
>> Tel.: +49 (0) 6894 - 9396 901
>> Fax.: +49 (0) 6894 - 9396 851
>> Email: vgreimann at key-systems.net
>>
>> Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net
>> <http://www.RRPproxy.net>
>> www.domaindiscount24.com <http://www.domaindiscount24.com> /
>> www.BrandShelter.com <http://www.BrandShelter.com>
>>
>> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
>> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
>> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
>>
>> Geschäftsführer: Alexander Siffrin
>> Handelsregister Nr.: HR B 18835 - Saarbruecken
>> Umsatzsteuer ID.: DE211006534
>>
>> Member of the KEYDRIVE GROUP
>> www.keydrive.lu <http://www.keydrive.lu>
>>
>> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
>> Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
>> Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese
>> Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per
>> E-Mail oder telefonisch in Verbindung zu setzen.
>>
>> --------------------------------------------
>>
>> Should you have any further questions, please do not hesitate to contact us.
>>
>> Best regards,
>>
>> Volker A. Greimann
>> - legal department -
>>
>> Key-Systems GmbH
>> Im Oberen Werk 1
>> 66386 St. Ingbert
>> Tel.: +49 (0) 6894 - 9396 901
>> Fax.: +49 (0) 6894 - 9396 851
>> Email: vgreimann at key-systems.net
>>
>> Web: www.key-systems.net <http://www.key-systems.net> / www.RRPproxy.net
>> <http://www.RRPproxy.net>
>> www.domaindiscount24.com <http://www.domaindiscount24.com> /
>> www.BrandShelter.com <http://www.BrandShelter.com>
>>
>> Follow us on Twitter or join our fan community on Facebook and stay updated:
>> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
>> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
>>
>> CEO: Alexander Siffrin
>> Registration No.: HR B 18835 - Saarbruecken
>> V.A.T. ID.: DE211006534
>>
>> Member of the KEYDRIVE GROUP
>> www.keydrive.lu <http://www.keydrive.lu>
>>
>> This e-mail and its attachments is intended only for the person to whom it is
>> addressed. Furthermore it is not permitted to publish any content of this
>> email. You must not use, disclose, copy, print or rely on this e-mail. If an
>> addressing or transmission error has misdirected this e-mail, kindly notify
>> the author by replying to this e-mail or contacting us by telephone.
>>
>>
>>
>> _______________________________________________ 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/969cf232/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list