Subject: [Isms] Questions for Call home

From: "David T. Perkins" <[email-masked]>
Date: Thu, 15 Sep 2005 11:22:09 -0700 (PDT)

HI,

In "call home",

1) What identities and credentials are being used?
2) How are those identities "put on the box"?
3) Are those identities and credentials there due to
   other management operations?
4) Are they used by other management interfaces?
5) What are the possible exploits that performed
   with identities and credentials from a
   compromized system?
6) Are there any changes that need to be made to
   existing security infrastructure to support
   the "call home" functionality, such as
   defining new RADIUS extensions?

Regards,
/david t. perkins

---------- Forwarded message ----------
Date: Wed, 14 Sep 2005 12:15:12 -0700 (PDT)
From: David T. Perkins <[email-masked]>
To: [email-masked]
Subject: [Isms] Tests for ISMS

HI,

In evaluating any candidate ISMS solution, I'd like to remind
all of the tests that I use:

1) What identity credentials does the candidate require from EACH
end of the SNMP operation pair? 

2) Does each end "already have" those credentials
due to setting up some other service? If they don't
have the credentials, then REJECT the candidate.

3) Does the candidate require that an existing security
infrastructure be modified (or extended) for the
candidate to work? If so, then REJECT the candidate.

4) Do other "management interfaces" use the same "operations
model". If not, then hold the candidate to higher
scrutiny. 

Note that the following are NOT reasons to REJECT a candidate:
1) backwards compatibility with an existing SNMP security model
2) new code for SNMP agents or managers
3) new SNMP terminology and ways of viewing the management model

Regards,
/david t. perkins

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

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 16 Sep 2005 10:13:28 +0200

Dave,

> 1) What identities and credentials are being used?

Borrowing from BEEP terminology for the moment, the initiator and
listener will use any authentication mechanism supported by the
underlying mapping protocol.  That is to say, for SSH, the responder is
configured to authenticate to the command generator via an appropriate
SSH mechanism such as a user name and password.  The generator would
authenticate via a host key or other mechanism defined with SSH.

The SNMP command generator is assigned an identity by the responder at
the time of invocation and as part of configuration.

> 2) How are those identities "put on the box"?

In the case of user name/password authentication, the command responder
is configured via configuration functions.  This may include updating of
various VACM tables once the connection is established.  The command
generator may hold the identities locally or may use a protocol such as
radius, diameter, or TACACS+.

>    other management operations?

On the command responder this will likely be the case.  The command
generator would use the same database used for other authentication.

> 4) Are they used by other management interfaces?

Quite possibly netconf as well as PPP.  Other uses are possible, such as
local consumer email access, account management web sites, etc.

>    with identities and credentials from a

I do not claim this is a complete analysis.  However...

If the command generator is compromised the exposure is the same as if
any other command generator is compromised.  If the command responder is
compromised, its configuration and potentially and some identity
information relating to its configuration may be exposed.  The
credentials used to authenticate administrative user access to the
responder are not envisioned to be the same as those used by the
responder to authenticate to the generator.  Remember, the responder is
requesting to be managed.

>    defining new RADIUS extensions?

No.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Sep 2005 11:11:02 +0200

> authenticate via a host key or other mechanism defined with SSH.

So you are saying that for CH, the entity with the command generator
you have to authenticate the user identity, that is the "agent" logs
into the "manager" by sending a user identity and a password. So how
does the agent then later on when the "manager" sends a request do the
access control decision? As far as I can tell, the "agent" does not
really have an authenticated securityName - the only thing the "agent"
has is an authenticated host identity.

Can you explain how you envision to resolve this?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Eliot Lear <[email-masked]>
Date: Fri, 16 Sep 2005 11:50:25 +0200

Juergen,
> Can you explain how you envision to resolve this?

I believe I commented on this in the same message.  I envision the agent
being configured with an identity that it would associate with the session.

So in pseudo-command parlance:

snmp-server call-home host 192.168.1.1 user eliot password LetMeIn
      snmp-user-is nocadmin

Where 192.168.1.1 is the manager, the user and password to access the
manager are 192.168.1.1 and password are eliot and LetMeIn, respectively.

Where [ snmp-user-is .... ] might have default values.

Eliot