Subject: Re: [weirds] Security Requirements: Authentication

From: Edward Lewis <[email-masked]>
Date: Thu, 1 Nov 2012 10:35:24 -0400

At 12:49 +0000 10/8/12, Hollenbeck, Scott wrote:
>From "Inventory of WHOIS Service Requirements Final Report":
>
>Define an authentication framework for WHOIS that is able to 
>accommodate anonymous access as well as verification of identities 
>using a range of authentication methods and credential services.
>
>From RFC 3707:
>
>Entities accessing the service (users) MUST be provided a mechanism 
>for passing credentials to a server for the purpose of 
>authentication.
>
>The protocol MUST provide a mechanism capable of employing many 
>authentication types and capable of extension for future 
>authentication types.
>
>These are basically saying the same thing. Are there any other 
>requirements for authentication?

First, looking at the thread, the statements above only say the 
protocol has to convey claims of identity, not evaluate them.  Talk 
about "federating" and things like single-sign on are back end 
operations that a server might use to make decisions on what goes 
into a reply.  The set up and management of a federated framework 
ought to be (in my opinion) performed out-of-band relative to the 
WEIRDS WG protocol.

I'm going to "brainstorm" another requirement.  It might be totally 
out of scope...this is an exercise is seeing if all paths of 
communication are considered:

If any two "servers" of the WEIRDS WG protocol ever need to 
coordinate, the two administrations/servers would need to be able to 
mutually authenticate.  Here I am conidering any cooperation between 
numbering servers that might be be related in the CIDR sense of one 
being more specific than the other, or in the name servers where the 
servers are related because they represent the same economy (think 
postal code) but use different scripts.

Again - there might not be any need for that if the scope of the 
protocol excludes that interaction.

I don't believe there is a need for a server to authenticate to a 
client, outside of any source authenticity that is provided as part 
of data integrity or replay prevention.  IOW, we don't need to 
authenticate the channel from the server to the client although there 
are other requirements protecting the data sent.  (The requirements 
Scott presented relate to authenticating the channel from the client 
to the server.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: "John Levine" <[email-masked]>
Date: 2 Nov 2012 00:17:16 -0000

>mutually authenticate.

I don't see why server A would need to authenticate server B, since
it'll just be sending a note to the client to ask server B, but
it would be nice if the client could use the same credentials.
That's what we mean by federated authentication.

There's certainly no need to invent something new, just include
existing schemes, notably OAuth, in the list of ones to use.

R's,
John