[gnso-rds-pdp-wg] Definitions: Authentication and Anonymity
Paul Keating
Paul at law.es
Tue May 16 12:56:46 UTC 2017
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/0548b8a5/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list