Subject: [weirds] Security Requirements: Authentication

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 8 Oct 2012 12:49:27 +0000

>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?

Scott

---

From: "John Levine" <[email-masked]>
Date: 9 Oct 2012 00:16:47 -0000

>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?

Not exactly the same thing, the first says there must be at least
one way to authenticate, and the second is saying that there must
be provision for multiple types.  Both seem reasonable.

It would be nice if there were a provision for federated
authentication, so you don't have to reauthenticate at each stage of a
referral.  I realize there are situations where this won't be
possible, but I also expect there will be a fair number where it will.

The model I have in mind is zone file access for ICANN's new domains,
where the plan is that you will sign up once with ICANN, who will
distribute the credentials to all of the registries so for the most
part the same credential will work everywhere.

R's,
John

---

From: Chris Wright <[email-masked]>
Date: Tue, 9 Oct 2012 14:31:58 +1100

Easiest way to do that is have ICANN sign your public key providing you
with a certificate that each server could simply validating using ICANNs
public key, no need to have any sharing of credentials or anything else.

Of course that means one of the supported authentication methods needs to
be certificate based authentication - which exists for HTTPs already.

This is only if indeed we need federated credentials at all, which is
another question.

Thanks

c.

On 9/10/12 11:16 AM, "John Levine" <[email-masked]> wrote:

>_______________________________________________
>weirds mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/weirds

---

From: "John Levine" <[email-masked]>
Date: 9 Oct 2012 04:02:20 -0000

>public key, no need to have any sharing of credentials or anything else.

That is certainly one approach to federated authentication, which
could work OK if people agreed that ICANN was the central
authentication authority, users all worked in ways where it was
practical to install a signed certificate into their browser or other
client, and they agreed on what if anything to do about certificate
revocation.  OAuth and OpenID are some other possibilities with other
advantages and disadvantages.

But I believe that Scott is asking whether we think he has the right
items on his security checklist, not asking us to implement them
quite yet.

R's,
John

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 9 Oct 2012 11:01:05 +0000

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Monday, October 08, 2012 8:17 PM
> To: [email-masked]
> Cc: Hollenbeck, Scott
> Subject: Re: [weirds] Security Requirements: Authentication
> 
> for
> >passing credentials to a server for the purpose of authentication.
> 
> authentication
> >types.
> Not exactly the same thing, the first says there must be at least one
> way to authenticate, and the second is saying that there must be
> provision for multiple types.  Both seem reasonable.

I meant that the one sentence from the "Inventory of WHOIS Service Requirements Final Report" (which says "x" as well as "y") and the two from RFC 3707 are basically the same.

Scott

---

From: "Ning Kong" <[email-masked]>
Date: Wed, 10 Oct 2012 10:39:27 +0800

> It would be nice if there were a provision for federated authentication,
so you
> don't have to reauthenticate at each stage of a referral.  I realize there
are
> situations where this won't be possible, but I also expect there will be a
fair
> number where it will.
I'm also interested in such federated authentication. I think there may be
potential user demand on it to simplify the process of authentications from
one client to multiple servers. I still wonder whether we should consider
such requirement at present.

Cheers,
Ning

---

From: Andy Newton <[email-masked]>
Date: Wed, 10 Oct 2012 12:54:26 +0000

>such requirement at present.

Perhaps rdap-sec could describe various federated approaches much the same
way it is outlining the authentication mechanisms. Having a description of
such things would probably be very useful to policy makers.

Also, I think rdap-sec should make clear the distinction between
authentication and authorization. Again, something very useful for policy
makers.

-andy

---

From: "Ning Kong" <[email-masked]>
Date: Thu, 11 Oct 2012 16:52:37 +0800

> Perhaps rdap-sec could describe various federated approaches much the
> same way it is outlining the authentication mechanisms. Having a
description
> of such things would probably be very useful to policy makers.
If the requirement can be accepted by the WG, I'd like to do this work in
the next version of rdap-sec.

> authentication and authorization. Again, something very useful for policy
+1
I also think authentication and authorization are technically two things.
Authorization issues, which I think are necessary to be considered, are not
discussed in the current rdap-sec draft. I wonder which document (rdap-sec
or using-http) is more suitable to cover this topic.

Cheers,
Ning

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 11 Oct 2012 10:56:54 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ning Kong
> Sent: Thursday, October 11, 2012 4:53 AM
> To: 'Andy Newton'; 'John Levine'; [email-masked]
> Authorization issues, which I think are necessary to be considered, are
> not discussed in the current rdap-sec draft. I wonder which document
> (rdap-sec or using-http) is more suitable to cover this topic.

It's on my to-do list for rdap-sec -01.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 11 Oct 2012 10:59:52 +0000

> If the requirement can be accepted by the WG, I'd like to do this work
> in the next version of rdap-sec.
> 
> > authentication and authorization. Again, something very useful for
> > policy makers.
> +1

I do, too. That's precisely why I started one discussion thread for authentication and another for authorization:

http://www.ietf.org/mail-archive/web/weirds/current/msg01671.html

Scott

---

From: Andy Newton <[email-masked]>
Date: Thu, 11 Oct 2012 12:10:06 +0000

>the next version of rdap-sec.

Well, I don't know about a requirement, as in I don't think we can say all
servers MUST participate in federated authentication or any authentication.

However, listing out federated authentication schemes and providing a
taxonomy would most likely be very useful to a lot of people. Certainly it
would not be an exhaustive list and other schemes could be created later,
but allowing policy makers and proposal writers to say "we endorse scheme
ABC in RFC ABC" would be beneficial.

-andy

---

From: Andy Newton <[email-masked]>
Date: Thu, 11 Oct 2012 12:11:40 +0000

On 10/11/12 6:59 AM, "Hollenbeck, Scott" <[email-masked]> wrote:
>
>I do, too. That's precisely why I started one discussion thread for
>authentication and another for authorization:
>

My bad, Scott! I was reading the rdap-sec draft and lost focus on the
thread.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 11 Oct 2012 08:16:33 -0400

> I don't think we can say all servers MUST participate in federated 
> authentication or any authentication.

Clearly not, it's a local policy thing.

> taxonomy would most likely be very useful to a lot of people.

That was my thinking -- if we can encourage people to agree on a small set 
of schemes, it's that much more likely that the servers you want to use 
will all handle the same one.

R's,
John

---

From: "Linlin Zhou" <[email-masked]>
Date: Fri, 12 Oct 2012 10:20:54 +0800

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Andy Newton
> Sent: Thursday, October 11, 2012 8:10 PM
> To: Ning Kong; 'John Levine'; [email-masked]
servers
> MUST participate in federated authentication or any authentication.
> 

I don't think all the server should in the federated authentication
mechanism. Generally speaking, I think there are two implementation methods,
one is centralized mode, the other is alliance mode that any two servers can
be authenticated by each other. But the realization approach can be the same
essentially.

> taxonomy would most likely be very useful to a lot of people. Certainly it
would
> not be an exhaustive list and other schemes could be created later, but
allowing
> policy makers and proposal writers to say "we endorse scheme ABC in RFC
ABC"
> would be beneficial.

Agree.