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

From: "Mike St. Johns" <[email-masked]>
Date: Thu, 01 Apr 1999 16:14:41 -0800

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: Yost William <[email-masked]>
Date: Mon, 5 Apr 1999 10:05:06 -0500

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.

Comments? 

Thanks - Mike

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

    
    g = 2

---

From: Yost William <[email-masked]>
Date: Mon, 5 Apr 1999 11:00:05 -0500

This is how we are implementing V1/V2V3 compatibility.  This method uses a
proprietary method for getting the first Privacy and/or Authentication key
into the modem, but the other aspects as far as handling all 3 types of
packets should be applicable generally.

SNMP V1/V2/V3 compatibility 

The modem operates in two modes: SNMP V1/V2 compatibility mode, and SNMP V3
mode.
    
SNMP V1/V2 compatibility mode:

This mode is in effect from power up until the first entry in the SNMP V3
User Table has been made.  In this mode the docsDevNmAccessTable controls
SNMP access and determines where traps are sent.  Either SNMP V1, V2, or V3
packets are processed.  When a V3 packet is received, it must be of
noauthentication, no privacy security level.  The user name from the V3
packet is used as a community string and the packet is processed just like
SNMP V2 packets are processed.
 
SNMP V3 mode:

This mode is entered at the completion of processing an SNMP packet when at
least one user has been made in the SNMP V3 User Table. The modem will not
leave this mode until a reboot.  Upon entering this mode, the
authentication and or privacy keys of all users are set as described in the
initial key generation algorithm below. The User Based Security Model and
View Based Access Model are used to control access to the modem.  The
SNMP-NOTIFICATION-MIB determines where to send traps and whether a trap or
inform shall be sent. Either SNMP V1, V2, or V3 packets are processed.  When
an SNMP V1 or V2 packet is received, it is processed according to the SNMP
Coexistence document.  This method uses the SNMP-COMMUNITY-MIB that
describes how to translate the SNMP V1 and V2 community strings into user
names.  So an SNMP V1 or V2 request will only be processed if there are
entries in the SNMP V3 Group and Access Tables allowing the supplied
community string to be used in the NoAuthNoPriv security level.  The
docsDevNmAccessTable will have no effect in this mode.
 
The usual procedure for enabling SNMP V3 mode would be for the configuration
file to create one or more entries in the SNMP V3 User table, group table,
access table, and view table. The user names created by the configuration
file will not be private, but they will do no good to an outsider because he
will not know the DES key from the initial key generation algorithm.  The
config file must supply values for at least the usmUserName column in the
User Table and the necessary entries in the group, access, and view tables
to provide the desired access to the MIB elements.  If a usmUserAuthProtocol
value is not supplied, it will default to MD5.  If a usmUserPrivProtocol
value is not supplied, it will default to NoPriv.

Initial key generation algorithm

The executable program header stored in FLASH will contain a 1 to 8
character USM password.  This password will be set in the factory to
'initial'.  The MSO will be supplied with a utility to allow changing this
password in the program header of a load file image.  Inside the modem, this
USM password is transformed into a DES key by using the password to key
algorithm using MD5 as shown in section A.2.1 of RFC2274.  Next the DES key
is localized to the snmp Engine by using the procedure in section 2.6 of
RFC2274 (using MD5 for the hash function). The snmpEngineId value of the
modem shall be as specified in RFC2271 in 11 hex bytes:
80-00-0B-2F-03-mm-mm-mm-mm-mm-mm (mm = 6 byte MAC Address).  

Thus, the usual procedure would be for the MSO to change the initial
password in a copy of the load file image and save it with a new filename.
Then the configuration file would be set up to enable baseline privacy and
to direct the modem to load this new filename.  A factory fresh modem, or
one with an unknown password in it would register, turn on baseline privacy,
download the new filename with the new initial password, reboot, and then
the initial entries in the USM User Table would be created as directed by
the config file, using the DES key(s) created from the new initial password.
Since the download was done with Basline Privacy enabled, the new initial
password has not been revealed, and all modems can have the same initially
known password.  The RCA Cable Modem will not perform a download if baseline
privacy has been selected in the config file but baseline privacy mode has
not been entered.  This will prevent disclosure of the new password when
baseline privacy mode fails to be entered.  Since only the program header is
being changed, re-certifying the load file by Cable Labs would not be
required.  The MSO's will keep a record of what initial passwords correspond
to each load file name and there will be a private MIB element to determine
what load file the modem is running. 

-----Original Message-----
From: Jack Fijolek [mailto:[email-masked]]
Sent: Monday, April 05, 1999 10:26 AM
To: [email-masked]
Subject: RE: Strawman for initialization of snmpv3 agents in cable
modems.

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.

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

Comments?

Thanks - Mike

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

    g = 2

---

From: Yost William <[email-masked]>
Date: Mon, 5 Apr 1999 11:02:02 -0500

Yes, currently certified modems would have to be recertified if SNMP V3 is
added.

-----Original Message-----
From: Jack Fijolek [mailto:[email-masked]]
Sent: Monday, April 05, 1999 10:26 AM
To: [email-masked]
Subject: RE: Strawman for initialization of snmpv3 agents in cable
modems.

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

Comments?

Thanks - Mike

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

    g = 2

---

From: Yost William <[email-masked]>
Date: Tue, 13 Apr 1999 14:33:14 -0500

I agree this will place the modem into a secure SNMP V3 mode at
initialization time and the privacy and authentication keys of the first
user will be known only to the manager and the modem.  This therefore meets
the requirements and is good.  I have a couple of points to raise.

1. This SNMP V3 initialization routine does not specify how the shared
secret is translated into the authentication and privacy keys.  I think the
password to key algorithm described in Appendix A, section A.1, paragraph
(2) of RFC2274 'User-based Security Model (USM) for version 3 of the simple
network management protocol' should be used.  The MD5 algorithm should be
used at the step where a digest is calculated.  This algorithm is commonly
used by SNMP V3 managers since it is easy for a user to input a readable
text password.

I believe the shared secret 'sk' should be transformed into a readable
password of 12 characters or fewer with no embedded spaces by truncating any
octets beyond the twelfth and then performing the following operation on
each octet (Treating it as an unsigned 8 bit integer):
  if( octet > 0x7F ) octet = octet - 0x80;                     // Clear the
top bit
  if( octet <= 0x20 ) octet = octet + 0x40;                 // Map control
codes into readable characters
  if( octet == 0x7F ) octet = octet - 1;                        // Re-map a
delete character to a tilde

Then these 12 characters can be used as the password to be input to the
password to key algorithm

2. In the definition of docsDevKickstartMyPublic it says 'l = ' just after
the definition of p.  I think that is a lower case L.  What is the
definition of that 'l' supposed to be?

3. This SNMP V3 initialization routine will require the SNMP manager to
calculate and use a different shared secret for each modem each time that
modem reboots.  Is this acceptable? How would you use this operationally?
Would you have a master SNMP manager someplace that would either be
generating the manager's random number or at least know what number is
currently being used? This station would be receiving cold start traps from
modems and  polling to see which modems are operational.  It would then
create at least one SNMP V3 user with known authentication and privacy keys
by cloning it from the docsisProv user.  I guess the configuration file
could create entries in the SNMP-NOTIFICATION-MIB to send noAuthNoPriv traps
to the master station.

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

Comments? 

Thanks - Mike

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

    
    g = 2

---

From: [email-masked]
Date: Thu, 15 Apr 1999 13:57:43 -0700

Ran,

We at GI are currently working to integrate the Epilogue toolkit into our
product.
I do not personally know enough about v3 to be sure exactly what has to be
there 
to satisfy the @Home requirement.  I presume that all the infrastructure to
support 
USM will need to be there, including whatever key negotiation protocol we
eventually
all agree to.

A couple of questions:

Is it possible to get a list of MIBs that must be supported?

Are there any other mandatory configuration items?
(an @Home SNMPv3 profile, so to speak)

Jon Fellows

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, April 09, 1999 8:32 AM
> To:	[email-masked]
> Subject:	Re: Strawman for initialization of snmpv3 agents in cable
> modems.
> 
> 
> 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]