Subject: RE: [Isms] Questions for Call home

From: [email-masked]
Date: Thu, 15 Sep 2005 13:48:25 -0700

Hi David,

Actually the reason I stated the cable case was because cable modems are
a typical example of set of CallHome use cases that deal with SOHO
devices (and some small branch offices). These include DSL, SOHO
routers, Perosnal VPN/Firewall devices etc., these devices required to
be managed, i.e. provisioning and monitoring. In most cases, these
devices will be behind a NAT/Firewall and cannot be managed by requiring
the NMS to initiate requests.

The Cable folks have made very specific technology choices such as use
of Kerberos but in general terms the notion of device identity and
credentials is pretty similar.

p.s. - The cable folks uses Syslog & DHCP for provisioning in addition
to SNMP and the list of management protocols might grow in the future.

regards,
  kaushik!

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: Thursday, September 15, 2005 1:23 PM
To: Kaushik Narayan [[email-masked]]
Cc: [email-masked]
Subject: RE: [Isms] Questions for Call home

HI,

Thank you for providing this information. 

I believe that cable modems are a special case, which can not be used to
project to other network infrastucture devices. That is, I believe the
cable modems were designed to be primarily (or only) managed via SNMP
and have no other management interface.

If a cable modem is compromised, I would guess that the only sensitive
info would be the private key for the cablem modem's X.509 cert. With
these, the exploits could be any that required that identity. Could that
allow theft of service?

I do appreciate your response, and hope that similar info can be
provided for SSH CH.

On Thu, 15 Sep 2005 [email-masked] wrote:
> Hi David,
> 
> I can give you a typical example of Call Home from the Cable space 
> since I being going through some of their specifications.
> 
> PacketCable 1.0 uses SNMPv3 for part of the provisioning, TFTP is used

> to download to the actual configuration file. Each MTA is required to 
> provisioned with a X.509 certificate (actually there are separate 
> certs for the cable modem and MTA) typically done at manufacturing. 
> The MAC address is used as CN within the X.509 cert
> 
> The X.509 certificate is shared between SNMPv3 and IPSec that is used 
> for communication between the MTA and the Call Management Server.
> Kerberized SNMPv3 is used for protection of SNMPv3 message, PKINIT is 
> used for initial authentication and ticket generation. The MAC address

> is used as USM user name (identity) within the Kerberized SNMPv3 
> exchange, the cable modem (managed device) initiates the exchange.
> 
> Hope this helps.
> 
> regards,
>   kaushik!
>  
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of David T. Perkins
> Sent: Thursday, September 15, 2005 11:22 AM
> To: [email-masked]
> Subject: [Isms] Questions for Call home
> 
> 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

---

From: [email-masked]
Date: Fri, 16 Sep 2005 09:21:43 -0700

Hi Juergen, Eliot,

I think we need to keep in mind the SNMPv3/USM model when we talk about
identity. The role of ISMS is to provide flexible authentication and key
management without modifying the notion of identity within USM. From a
security perspective the only identity USM deals with is the
securityName, i.e. SNMP principal (SNMP engine ID is really not
authenticated). What the means is that irrespective of the SNMP engine
that initiates the conversation (CH or otherwise), command generators
and notification generators MUST authenticate using SNMP securityName(
using the SSH user authentication protocol)

Regards,
  kaushik!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Juergen Schoenwaelder
Sent: Friday, September 16, 2005 2:11 AM
To: Eliot Lear
Cc: [email-masked]
Subject: Re: [Isms] Questions for Call home

On Fri, Sep 16, 2005 at 10:13:28AM +0200, Eliot Lear wrote:

> You asked a bunch of questions relating to CH.  Please see below:
> 
> 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.

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: [email-masked]
Date: Fri, 16 Sep 2005 11:05:13 -0700

Hi Dave,

I'm not sure I agree with your statement.

Your last sentence says "MUST authenticate using SNMP securityName. I
believe that is incorrect. It is acceptable to have a mapping from the
SNMP securityName to a model-specific identity, and to perform the
authentication using the model-specific identity.

One way to change your statement would be to say "MUST authenticate SNMP
securityName". 

<Kaushik> You are right but I did not intend my statement to preclude
mapping of securityName. I think your correction is valid.

---

From: [email-masked]
Date: Fri, 16 Sep 2005 13:50:53 -0700

Hi David,

Please find my reply inline.

1) I have a concern with statements that certain types of applications
must authenticate. I don't believe that is an architectural requirement,
but more a factor of the way USM works. I believe a new security model
could do things differently, and new applications could be written that
had different requirements for authentication. 

<Kaushik>

I think the statement does not suggest that only certain applications
MUST authenticate, it describes what identity needs to be authenticated
by certain applications since those applications need that identity to
be authorized before execution of the operations. It would be applicable
to any new SNMP application that would require to authorize operations.

2) It is incorrect to say that "any command generators and notification
generators which generates/sends a message in the 
conversation MUST authenticate" - SNMPv3 also supports noAuthNoPriv.

<Kaushik>

That actually raises a question. Do we plan to support noAuthNoPriv with
SSHSM (cipher=none, authentication method=none).

dbh

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, September 16, 2005 1:00 PM
> To: [email-masked]; Eliot Lear
> Cc: [email-masked]
> My previous statement had some ambiguity. Here is a second try
> 
> I think we need to keep in mind RFC3411 when we talk about identity. 
> The role of ISMS is to provide flexible authentication and key
management
> without modifying the notion of identity within RFC3411. From a 
> security perspective the only identity RFC3411 deals with is the
securityName,
> i.e. SNMP principal (SNMP engine ID is really not authenticated).
What
> the means is that irrespective of the SNMP engine that initiates the 
> conversation (CH or otherwise), any command generators and 
> notification generators which generates/sends a message in the 
> conversation MUST authenticate using SNMP securityName (using the SSH 
> user authentication
> protocol)
>