Subject: RE: [Isms] #1: is it important to support anonymous user accesstoSNMP?

From: "Nelson, David" <[email-masked]>
Date: Fri, 21 Oct 2005 11:13:07 -0400

Whether or not "it" is a useful feature in ISMS, I pedantically oppose
use of the term "authenticated anonymous access" to describe "it".  As
explained in this thread, "it" is access by means of a security
association in which one party is authenticated and the other party is
anonymous.  I still claim that it is meaningless to say that an
anonymous entity has been authenticated, and that's what "authenticated
anonymous access" says if you parse it using standard syntax rules for
the English language.

In the "one party authenticated, one party anonymous" scenario, the two
parties still need to have some form of shared credential for any
authentication to occur.  One example of this is when the anonymous
party has a local trust anchor (e.g. an X.509 certificate chain) that
allows it to authenticate the non-anonymous party.  This certainly works
with modern web browsers.

The need for non-enrolled, non-authenticated entities to obtain access,
for monitoring purposes, may make sense in some scenarios.  But do the
non-authenticated entities need to be anonymous?  I use the word
anonymous in its traditional security protocol meaning, i.e. the
identity of the entity is not disclosed and cannot be determined.

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 21 Oct 2005 12:05:48 -0400

> Note that I am not necessarily saying ISMS has to support
> authenticated anonymous access - perhaps community "public" is good
> enough, even though it is not authenticated.

The question was whether this is a useful feature. My answer is yes.
Whether it's a necessary one, or how much development efforts it
justifies - I abstain from answering.

> In fact, does authenticated anonymous access not boil down to "I
> configure a well-known (typically read-only) user identity with a
> secret that everybody knows about"? If yes, then I don't think ISMS
> has to do something special.

No, because in models such as USM - knowledge of that secret
cryptographically allows to impersonate *either* end of the
conversation. In ISMS it may or may not be different.

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 21 Oct 2005 09:36:44 -0700

Since it seems like we are talking about unauthenticated access I see
this as more of an operational issue than something that would require
much, if any, protocol specification.  If unauthenticated access is
really required then operational conventions can be developed to support
this within the current authentication framework of SSH.  

David B Harrington wrote:
> This approach is already being used by NMS systems today. I
> don't see why it would be impractical.
> 
> 
> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Blumenthal, Uri
>> Sent: Friday, October 21, 2005 9:08 AM
>> To: [email-masked]
>> Subject: RE: [Isms] #1: is it important to support anonymous user
>> accesstoSNMP? 
>> 
>>>> Consider a public facility (maybe a library) that has free network
>>>> access. Consider management applications that could be used to
>>>> determine the availability of some resource (such as a printer). In
>>>> this situation, it would be impractical to give each user a unique
>>>> identity so that they could use SNMP to determine the status of the
>>>> printers. If the identities of the printers were not authenticated
>>>> (or the communication not integrity checked) then someone could
>>>> fake that a printer was unavailable so that they could have
>>>> exclusive access.
>>> 
>>> The much simpler approach is to give the printer-monitoring
>>> application installed on the public computers its own credentials -
>>> the application is mapped to a securityName, and the application is
>>> allowed to see specific portions of the SNMP data.
>> 
>> I agree with Dave Perkins here. "Semi-anonymous" access (where the
>> server is authenticated to an anonymous client) has its merits, and
>> is useful for SNMP; for monitoring and not management.
>> 
>>> Human users have anonymous access to the application, which has
>>> access to the SNMP data and would presumably interpret the data and
>>> display the interpretation in a form suitable for human consumption.
>> 
>> IMHO this is possible but impractical, at least much less practical
>> than what Dave P. outlined. 
>>

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 21 Oct 2005 13:43:41 -0400

> Since it seems like we are talking about unauthenticated access

Not quite. There are two end-points, and it is possible to authenticate
only one of them. Apparently it can be useful to be able to enforce
authentication of only one end.

> ....I see
> much, if any, protocol specification. 

Probably - I don't know.

> If unauthenticated access is

For SSH it would mean - SSH server doesn't authenticate the user (or a
"well-known" credential is used, such as "public"), but the SSH client
authenticates SSH server.

---

From: "Kaushik Narayan \(kaushik\)" <[email-masked]>
Date: Tue, 25 Oct 2005 08:21:57 -0700

I really don't see any serious SNMP use cases that might require
anonymous user support. I completely agree with David here, we should
use capabilities from SSH based on what's needed for SNMP.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sam Hartman
Sent: Monday, October 24, 2005 3:16 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Isms] #1: is it important to support anonymous user
accesstoSNMP?

>>>>> "David" == David B Harrington <[email-masked]> writes:

    David> Personally, rather than seeing support for a wide variety
    David> of authentication alternatives, I'd like to see us support
    David> the widely-deployed SSH authentication mechanisms that
    David> serve SNMP needs. I am willing to accept that we should
    David> support any authentication mechanism REQUIRED or
    David> RECOMMENDED for use with the SecSH standard.

I think as a matter of architectural sanity you need to support any
authentication mechanism that works with the ssh protocol regardless of
whether it is recommended for use.

    David> Is anonymous SSH authentication supported by the secsh
    David> standards?

Sure.  Two ways.  The easiest is that the server simply returns success
when you start user authentication instead of giving you methods to
choose from.  I've also seen servers that offer keyboard-interactive and
when you select it simply return success.
The second is that you have some well known credential.

--Sam

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 25 Oct 2005 10:46:33 -0700

Randy Presuhn <> supposedly scribbled:

...

> To make it really concrete, if we assume the security adminstrator is
> reasonably sane, the permissions granted to "anonymous" would
> probably be identical to those given to "public".  The difference
> (with respect to using "public" with USM or SNMPv1 or SNMPv2) is that
> the user could have reasonable assurance that the data being
> retrieved was not tampered with or spoofed, and, optionally, was
> protected from evesdroppers. 

OK, so this argues not for some kind of ill-defined "anonymous user authentication", but for actual authentication of the communicating devices.  One size does _not_ fit all...
    
> Randy

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 25 Oct 2005 12:35:00 -0700

Glen,

Since I've scribbled once, I may as well scribble again to respectfully
disagree with your posting:
If one defines authentication to be "proving that an entity is who it
claims to be", then authenticating an anonymous entity is simply proving
that the entity has no specific identity to that system. 

It is a separate issue as to whether anonymous authentication is needed
or not within ISMS. I originally thought that it anonymity was not
desirable in network management (i.e., the perspective I surmise that
you hold), but David Perkin's subsequent arguments convinced me that
there is a potential need to support anonymous entities. It also is a
separate issue as to how authorization should relate to authentication.

--Eric

-----Original Message-----
From: Glen Zorn (gwz) [mailto:[email-masked]] 

Fleischman, Eric <> supposedly scribbled:

> This discussion appears to me to have been coupling authentication 
> with authorization. If we permit the authentication of an "anonymous" 
> entity, then the question of whether or not that entity is authorized 
> to do anything useful is a policy issue.

The term "authentication" doesn't seem to apply to anonymous entities.

Hope this helps,

~gwz

W

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 25 Oct 2005 15:50:15 -0400

Eric Fleischman writes...

> that the entity has no specific identity to that system.

Well, this *is* a rathole, but I'll go one more round.  :-)

I support Glen Zorn's assertion.  You are attempting to prove a
negative.  As an example, please *prove* to me that you and I have never
met and that you would not recognize me on the street.  Assume that I've
provided you no credentials, and that my e-mail username may very well
be a pseudonym.

I respectfully suggest that the term "anonymous access" or the term
"non-authenticated access" would accurately describe the feature under
discussion.  I agree that the term "authenticated anonymous access" is
an oxymoron.

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 25 Oct 2005 15:32:18 -0700

Ira,

Thank you for this insightful posting. Perhaps I was too easily swayed,
but the thoughts within David Perkin's postings that I resonated with
are the following points (i.e., not the printing example that you
cited):
1) David Perkins argument about the need for ""anonymous clients"
retrieving info via an authenticated server via a channel with integrity
and possibly encryption"
2) Joe Touch's ideas about the need for a "minimalist" security options
(i.e., something between none and plenty) such as
http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/dra
ft-touch-anonsec-00.txt
3) My own Fear, Uncertainty, and Doubt (FUD) as I remembered how often I
have failed to think of important use cases in the past and a desire
therefore to avoid being painted into a corner in the future by my own
lack of foresight.

Do any of these points resonate with you?

--Eric

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 27 Oct 2005 10:12:06 -0700

David T. Perkins <mailto:[email-masked]> supposedly scribbled:

> HI,
> 
> Glen - what terminology would you want all to use when discussing:
>   client identity is not authenticated
>   server identity is authenticated
>   session data is integrity checked

How about "server-side authentication"?  That seems to sum it up to me.  What is done w/the session data stream (integrity protection, encryption, etc.) seems to be a different question insofar as data protection isn't entailed by authentication.

> Regards,
> /david t. perkins

...

Hope this helps,

~gwz

---

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 31 Oct 2005 09:45:44 -0800

Ira,

Thank you for considering these issues and evaluating them in regards to
ISMS. I certainly concur with you that the primary goal of ISMS is to
improve upon SNMPv3 security. I am also aware of the problems that have
been occuring with the SNMP "public" community. Thus, unless somebody
can identify an actual requirement for "anonymous users" within SNMP,
you have convinced me that providing an anonymous authentication
possibility (i.e., solely for FUD reasons) is not something we want to
do in ISMS.

--Eric

-----Original Message-----
From: McDonald, Ira [mailto:[email-masked]] 
Sent: Saturday, October 29, 2005 12:20 PM
To: Fleischman, Eric; McDonald, Ira; Glen Zorn (gwz); Joseph Salowey
(jsalowey); [email-masked]; Blumenthal, Uri; [email-masked]; David
T. Perkins
Subject: RE: [Isms] #1: is it important to support anonymous user
accesstoSNMP?

Hi Eric,

Thanks for the pointer to Joe Touch's ANONsec draft from May 2004.

I read it all the way through with interest.  And then I discovered 
the recently chartered IETF BTNS (Better Than Nothing Security) WG, 
(http://www.ietf.org/html.charters/btns-charter.html), which has
published:

  "Problem and Applicability Statement for Better Than Nothing Security
  (BTNS)", Joseph Touch, 26-Sep-05,
<draft-ietf-btns-prob-and-applic-01.txt>

The two independent working drafts are:

  "An Unauthenticated, or Leap-of-Faith-Authorization Mode for
  Bump-In-The-Stack Implementations of IPsec Using Internet Key Exchange
  Protocols", Nicolas Williams, 2-May-05,
  <draft-williams-btns-unauthenticated-bits-00.txt>

  "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec",
Nicolas
  Williams, 8-Sep-05, <draft-williams-btns-00.txt>

The latter is the successor to Joe Touch's original ANONsec draft.

But what Joe Touch and the BTNS folks have done is give a good rationale
for adding support for unauthenticated IKE SAs (Security Associations)
to 
IKEv2.

That is, the whole point of Joe's argument is that this mechanism is
ONLY useful at the NETWORK layer - to protect against off-path attacks
on the transport protocols - such as the serious RST attack on TCP,
which cannot be defended against within TCP for long-duration
connections at high data 
rates (above 100 Mbps), because the valid receive window simply becomes 
too large.

I'm unpersuaded that this is a good general mechanism at the application
layer (e.g., SNMP), even though it is ubiquitous in web browsing
(HTTPS).

This is NOT an 'authenticated' mechanism.  When used at the application 
layer, it cannot defend against active off-path or man-in-the-middle
attacks.

I doubt that the reason we want networks to deploy SNMPv3 is the
protocol performance improvements over SNMPv1.  I think the main reason
is to get them to use acceptably strong security to avoid compromising
the integrity of their networks.

Anonymous use access to SNMP is available now with the SNMPv1 'public'
community.  And it's caused a lot of serious problems.

Cheers,
- Ira