[gnso-rds-pdp-wg] Definitions: Authentication and Anonymity
Gomes, Chuck
cgomes at verisign.com
Tue May 16 12:46:02 UTC 2017
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 ¾ 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<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) 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
--
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<mailto: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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170516/45587c66/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list