Subject: [midcom] STUN issue #6: Client certs considered harmful

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Nov 2002 03:27:12 -0500

STUN allows for a client to present certificates in the TLS exchange, at 
MAY strength. However, this provides no value at all, since the server 
doesn't need to authenticate the client. In fact, it is harmful, because 
it introduces a way to impose computational load on the server.

The proposal is to change use of client authentication to MUST NOT.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 19 Nov 2002 10:29:37 -0600

Why wouldn't we want the client to authenticate? I would think that this
a requirement.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Tuesday, November 19, 2002 2:27 AM
To: [email-masked]
Subject: [midcom] STUN issue #6: Client certs considered harmful

-Jonathan R.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 19 Nov 2002 13:03:32 -0500

Could you describe what you'd be protecting against by
having the client authenticated by the server?

Thanks,

Melinda

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 19 Nov 2002 12:42:28 -0600

Unauthorized access/use of the server

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Tuesday, November 19, 2002 12:04 PM
To: Christopher A. Martin
Cc: 'Jonathan Rosenberg'; [email-masked]
Subject: Re: [midcom] STUN issue #6: Client certs considered harmful

Thanks,

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Tue, 19 Nov 2002 13:48:54 -0500

> Unauthorized access/use of the server

Understood, but I think that the word "unauthorized" needs
more explication in this context, or at least we need to
understand what the risk to the server is.  That's
particularly a concern given that the mitigation (client
authentication) introduces a DoS threat, itself.

Melinda

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 19 Nov 2002 13:04:56 -0600

I think that any service that provides a function such as this, to
address NAT/firewalls traversal, has the potential to be abused.
Authentication can reduce the number of connections at least by
authenticating the subscribed users. Those that cannot authenticate can
be dropped, reducing the application overhead that would be required to
process unauthorized users. The digest mechansims for other protocols
could probably be applied here as well as a minimal requirement to
reduce overhead needed to perform authentication and prevent spoofing. 

If we are just saying, "hey, lets put a server up to permit everyone
with a firewall, traversal capability, because we have plenty of system
resources to handle it", then I would say, okeedokee, otherwise, might
be a good idea, at least to address those folks that don't have the
resources to give away to everyone, to follow up and confirm whether it
is required or not.

NOTE:
This is just my kneejerk reaction to a single email that caught my eye,
I am doing a bit of a diservice right now commenting without fully
reading the entire thread or drafts to date, so ignore my comments while
I go back and read up on the current status and drafts available. If it
does sound like something that should be addressed I wanted to bring it
up just in case someone who has been following lately can confirm
whether this is a problem or not.

Sorry, it s a resource issue,
Chris

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]] 
Sent: Tuesday, November 19, 2002 12:49 PM
To: Christopher A. Martin
Cc: 'Jonathan Rosenberg'; [email-masked]
Subject: Re: [midcom] STUN issue #6: Client certs considered harmful

Understood, but I think that the word "unauthorized" needs
more explication in this context, or at least we need to understand what
the risk to the server is.  That's particularly a concern given that the
mitigation (client
authentication) introduces a DoS threat, itself.

Melinda

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Nov 2002 15:14:33 -0500

inline.

Christopher A. Martin wrote:
> I think that any service that provides a function such as this, 

Function? The STUN server is providing a reflector service. The activity 
of authenticating the client for purposes of authorization to use the 
service exceeds the work in actually providing the service. 
Authorization is only needed to manage access and usage to constrained 
resources. That is not the case here. It has been the operating 
procedure for a LONG time that there is absolutely no requirement for 
client authentication or authorization. If you are proposing to change 
that assumption, please provide some concrete reasoning.

> to

See above.

> resources to give away to everyone, to follow up and confirm whether it

What resources??? This is a packet reflector.

> I go back and read up on the current status and drafts available. 

Disservice indeed. I would strongly recommend reading the documents 
before criticizing the design choices that have been made.

-Jonathan R.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Tue, 19 Nov 2002 14:41:11 -0600

ok

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, November 19, 2002 2:15 PM
To: Christopher A. Martin
Cc: 'Melinda Shore'; [email-masked]
Subject: Re: [midcom] STUN issue #6: Client certs considered harmful

inline.

> authenticating the subscribed users. Those that cannot authenticate 
> can be dropped, reducing the application overhead that would be 
> required to process unauthorized users. The digest mechansims for 
> other protocols could probably be applied here as well as a minimal 
> requirement to reduce overhead needed to perform authentication and 
> prevent spoofing.

See above.

> with a firewall, traversal capability, because we have plenty of 
> system resources to handle it", then I would say, okeedokee, 
> otherwise, might be a good idea, at least to address those folks that 
> don't have the resources to give away to everyone, to follow up and 
> confirm whether it is required or not.

> 
> NOTE:
> This is just my kneejerk reaction to a single email that caught my 
> eye, I am doing a bit of a diservice right now commenting without 
> fully reading the entire thread or drafts to date, so ignore my 
> comments while I go back and read up on the current status and drafts 
> available.

-Jonathan R.