Subject: RE: Strawman for initialization of snmpv3 agents in cable modems.

From: "Jack Fijolek" <[email-masked]>
Date: Mon, 5 Apr 1999 10:26:05 -0500

Will currently certified modems have to be upgraded and then recertified to
participate in your proposal? SNMPv1 was/is the DOCSIS 1.0 certification
requirement. Doesn't that imply that CMs and CMTSs should really be v1,v2,v3
multilingual and sense the managers version to interoperate correctly?
Jack Fijolek
3Com Cable Access
847-262-2201

Yost William <[email-masked]> on 04/05/99 10:05:06 AM

Please respond to [email-masked]

To:   "'ipcdn @terayon.com'" <[email-masked]>
cc:    (Jack Fijolek/MW/US/3Com)
Subject:  RE: Strawman for initialization of snmpv3 agents in cable modems.

I suggest that docsDevKickstartMgrPublic be settable by SNMP only via SNMP
MIB objects in the config file.  You do not have to define a new config file
object type that way.  The agent can tell whether an SNMP command comes from
the config file or not.

Also, the modem should operate in SNMP V2 mode after processing the config
file if docsDevKickstartMgrPublic was not set by the config file.  Otherwise
it should operate in SNMP V3 mode.

-------------------- William H. Yost, Thomson Consumer Electronics (317)
587-4816 [email-masked] --------------------------
(Remove $ signs from Email address to reply)

-----Original Message-----
From: Mike St. Johns [mailto:[email-masked]]
Sent: Thursday, April 01, 1999 7:15 PM
To: [email-masked]
Subject: Strawman for initialization of snmpv3 agents in cable modems.

I've attached a rough draft of a set of MIB objects and procedures to permit

an operator take control of a DOCSIS modem in a relatively secure manner via

SNMPv3.  The basic mechanism is a Diffie-Hellman key exchange.  The manager
provides its public value to the modem via the configuration file.  The
manager reads the public value of the modem via snmpv3 using a standard
default usmUser which has access only to these values (and the standard
'system' group).

Via the DH exchange, the manager and the cable modem can agree on a common
shared secret which is used to popluate the key values for another standard
usmUser who has access to the usmUserTable to create and delete additional
users.  The manager can then populate that table as necessary.

Comments?

Thanks - Mike

docsDevKickstartMyPublic OBJECT-TYPE
    SYNTAX  OCTET STRING
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
     "The agent's Diffie-Hellman public value.  At initialization,
    the agent generates a random number and derives its public value
    from that number.  This public value is published here[ and may be
    included in the DHCP request].  This public value 'y'  equals g^r
    MOD p where g is the from the set of Diffie-Hellman parameters, p
    is the prime from those parameters, and r is a random integer
    selected by the agent in the interval 2^(l-1) <= r < p-1.

    The public value is expressed as an OCTET STRING 'PV' of length
    'k' which satisfies

              k
        y =  SUM   2^(8(k-i)) PV'i
             i = 1

     where PV1,...,PVk are the octets of PV from first to last, and
        where PV1 != 0.

    The following DH parameters (Oakley group #2, RFC 2409, sec 6.1,
    6.2) are used for this object:

    g = 2
    p = FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
        29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
        EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
        E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
     EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
        FFFFFFFF FFFFFFFF
    l =
    "
    ::= { docsDevV3KickstartGroup 1 }

docsDevKickstartMgrPublic OBJECT-TYPE
    SYNTAX  OCTET STRING
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
     "The manager's Diffie-Hellman public value.  Note that this
    value is may not be set via the SNMP network agent, but may be set
    via the Cable Modem configuration file or via a DHCP response.

    The manager calculates this value in the same manner and using the
    same parameter set as the agent does.  E.g. it selects a random
    number, calculates y = g^r mod p and sends 'y' as the public
    number expressed as an OCTET STRING.  See docsDevKickstartMyPublic
    for details.

    When this object is set with a valid value during initialization,
    a row is created in the usmUserTable with the following values:

    usmUserEngineID      localEngineID
    usmUserName               "docsisProv"
    usmUserSecurityName       "docsisProv"
    usmUserCloneFrom          ZeroDotZero
    usmUserAuthProtocol       usmHMACMD5AuthProtocol
    usmUserAuthKeyChange ""
    usmUserOwnAuthKeyChange   ""
    usmUserPrivProtocol       usmDESPrivProtocol
    usmUserPrivKeyChange ""
    usmUserOwnPrivKeyChange   ""
    usmUserPublic        ""
    usmUserStorageType        permanent
    usmUserStatus        active

    A shared secret 'sk' is calculated at the agent as sk =
    mgrPublic^r mod p where r is the agents random number and p is the
    DH prime from the common parameters.  The underlying privacy key
    for this row is derived from sk by....  The underlying
    authentication key for this row is derived from sk by.....

    The manager can use its knowledge of its own random number and the
    public value published by the agent to kickstart its access to the
    agent in a secure manner.  Note that the security of this approach
    is directly related to the strength of the authorization security
    of the out of band provisioning of the managers public value
    (e.g. the configuration file)."
    ::= { docsDevV3KickstartGroup 2 }

The following entries are included in a DOCSIS SNMPv3 compliant modem.

This entry allows access to the system and docsDevV3Kickstart groups

usmUserEngineID          localEngineID
usmUserName         "docsisInit"
usmUserSecurityName "docsisInit"
usmUserCloneFrom    ZeroDotZero
usmUserAuthProtocol none
usmUserAuthKeyChange     ""
usmUserOwnAuthKeyChange  ""
usmUserPrivProtocol none
usmUserPrivKeyChange     ""
usmUserOwnPrivKeyChange  ""
usmUserPublic       ""
usmUserStorageType  permanent
usmUserStatus       active

This is the entry created when the modem is correctly provisioned via
the config file manager public value entry as above.  Note that this
username  gives at LEAST full access to the usmUser table for the
creation of additional entities.

usmUserEngineID          localEngineID
usmUserName         "docsisProv"
usmUserSecurityName "docsisProv"
usmUserCloneFrom    ZeroDotZero
usmUserAuthProtocol usmHMACMD5AuthProtocol
usmUserAuthKeyChange     ""
usmUserOwnAuthKeyChange  ""
usmUserPrivProtocol usmDESPrivProtocol
usmUserPrivKeyChange     ""
usmUserOwnPrivKeyChange  ""
usmUserPublic       ""
usmUserStorageType  permanent
usmUserStatus       active

This maps the initial user into the accessible objects

vacmSecurityModel        3 (USM)
vacmSecurityName         "docsisInit"
vacmGroupName            "docsisInit"
vacmSecurityToGroupStorageType     permanent
vacmSecurityToGroupStatus     active

Group name to view name translation.

vacmGroupName            "docsisInit"
vacmAccessContextPrefix       ""
vacmAccessSecurityModel       3 (USM)
vacmAccessSecurityLevel       noAuthNoPriv
vacmAccessContextMatch        exact
vacmAccessReadViewName        "docsisInitRestricted"
vacmAccessWriteViewName       ""
vacmAccessNotifyViewName "docsisInitRestricted"
vacmAccessStorageType         permanent
vacmAccessStatus         active

Two entries to allow the initial entry to access the system and
kickstart groups.

vacmViewTreeFamilyViewName    "docsisInitRestricted"
vacmViewTreeFamilySubtree     1.3.6.1.2.1.1  (system)
vacmViewTreeFamilyMask        ""
vacmViewTreeFamilyType        1
vacmViewTreeFamilyStorageType permanent
vacmViewTreeFamilyStatus active

vacmViewTreeFamilyViewName    "docsisInitRestricted"
vacmViewTreeFamilySubtree       (docsDevV3KickstartGroup)
vacmViewTreeFamilyMask        ""
vacmViewTreeFamilyType        1
vacmViewTreeFamilyStorageType permanent
vacmViewTreeFamilyStatus active

---

From: [email-masked] (Randall Atkinson)
Date: Fri, 9 Apr 1999 08:31:33 -0700

Jack,

	I can't and won't try to speak for the CableLabs process.
I can and will say that modems will have to be upgraded to support
SNMPv3 to meet @Home's needs.  This even includes already deployed
MCNS 1.0 modems.  We've already seen security compromises that are
believed due to SNMPv1, so this is directly impacting our business.

Yours,

Ran
[email-masked]