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

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 21 Oct 2005 15:13:45 -0700

Nelson, David <> supposedly scribbled:

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

I agree.
      
> 
> 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.  

Yes, & that's not completely unreasonable.
   
> 
> The need for non-enrolled, non-authenticated entities to obtain
> access, for monitoring purposes, may make sense in some scenarios. 

It might, indeed, but I would be strongly opposed to using the word "secure" in referencing those applications...

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

I think it's actually more like "don't care" than truly anonymous. 
 
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

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 21 Oct 2005 17:56:42 -0700

Hi -

Perhaps we can distill the what the use cases are asking for:

-  that the user of the command generator application does
not need to be known to to the administration.  (the security
administrator may, of course, choose to prohibit such access)
This isn't necessarily true anonymity, and I'm sure it would help
if someone could suggest a term from the security community
that means what we intend.

- the request will be encrypted, if the user wants privacy.  Other
"anonymous" users will have no advantage in attempting to
decrypt such a request.

- the command responder will have reasonable confidence
that the request has not been modified en route, even by another
"anonymous" users. 

- the "anonymous" user making such a request can be referred
to in a VACM policy

- if the request was encrypted, the response will also be encrypted, so
that only the intended recipient (and possibly the sender) will be able to
decrypt it.  In particular, other "anonymous" users will NOT have any
advantage in attempting to decrypt the response.

- the user of the command generator application will be able to be
reasonably confident that the response came from the intended
command responder, and was not modified in transit.

(The reason for wanting integrity on the request is due to the way
getNext and getBulk work in SNMP.  With a simple get request,
the response would make it clear whether the request had been
mangled in any significant way.  With getNext and getBulk, one
can massively change the request, and the response would give
no clue that this had happen, even though the information returned
could indeed be different.)

Randy