NC Ethernet / Modem ROM Modifications

    Distribution: COMPANY CONFIDENTIAL

    Project:      NC Network
    Issue:        0.04
    Author(s):    Ant Skelton, Steve Cormie
    Date:         13-Jan-97
    Last Issue:   0.03
  

0.0 Abstract

It is proposed that some modifications are made to the modem and ethernet ROMs to address some shortcomings which have become apparent since OS release 1.06. This document details the additions or modifications which will be made to these ROM images, otherwise their content will remain the same.

Contents

• Abstract
• Introduction
• Contents
• Registry / Bootblock changes
• Smartcard Programming
• NC line-dropping modifications
• PAP/CHAP authentication problems
• Security issues
• Wimp
• ROM version module
• BOOTP extensions

0.1 Introduction

This document defines the changes which will be made to both the NC modem ROM and the NC ethernet ROM in order to update both the software contained within these ROMs and the main NC OS operating system software.

1.0 Registry / Bootblock changes

1.1 Proposed New Bootblock / Registry structure

The original bootblock format comprised an ordered list of tags of fixed sizes - unused tags are left blank. A few variable length tags ( special tags ) were able to be encoded into the send-expect script which was stored on the card.

This format is proving unwieldy and difficult to extend. In the light of our improved knowledge of smartcards in general and requirements in the field, a more flexible approach will be implemented.

Briefly, this will comprise:

1. bootblock entries are stored as tagged, byte counted entities, thus all entries are variable-length. Entry lengths may be modified up to a maximum hard limit, which is currently 65535 bytes.
2. the registry will maintain a mapping of tag names (as used by registry clients) to tag values (as stored in the bootblock). In addition, each tag mapping will include some flags, stating whether this entry is mandatory or optional, whether it is updateable, and whether it is overwriteable by a softloaded bootblock, as per the current mechanism. Maximum permissable tag data sizes will also be stored, as well as some bitfield manipulation data, so that multi-bit tag values may be dereferenced properly (eg reading the AUTH_ENABLE bit from the SYSTEM_FLAGS3 word).
3. extra tag mappings may be soft loaded into the registry from the bootblock, giving an extra degree of flexibility in the format without new registry code releases.
4. the complication of special tags is no longer needed - they can be removed from the dial up script and be replaced by regular bootblock entries.

The above requires changes to the registry module, the registry script support module, the dial-up script compiler, the smartcard programming tools, and the online registration process.

Smartcards have come preformatted to 440 bytes per bootblock - obviously these will not work where the bootblock is bigger than 440 bytes. We need to decide on a new maximum bootblock size for future smartcards. Once a smartcard is minted its bootblocks cannot have their lengths altered.

800 bytes will be used as the new size for bootblocks on minted smartcards. This size may change as necessary - the registry is unaffected. It is also feasible for bootblocks of different sizes to be created on one smartcard during the minting process. The registry will be able to interpret bootblocks of any length, within the limits imposed by available free memory on the NC.

Note that this size restriction is the maximum total amount of data which may be stored in a given bootblock. Existing smartcards will work with the new registry software, but new bootblocks will be limited in this case to 440 bytes in total.

The registry supports a maximum of 8 bootblocks and the bootblock size is suggested by the formula:

  max_bootblock_size = 1 (sc_size - index_size - sizeof(other_data) )
                       -
                       8

1.2 New bootblock structure details

1.2.1 Smartcard format

As before, ie one index file, max. 8 bootblocks, 1 NCBrowser scratch file. No change except for the bootblock format/size.

1.2.2 Bootblock format

1.2.3 Bootblock entry format

TAG_ID is an 8 bit quantity, giving us 256 maximum possible tags.

TAG_LEN is a 16 bit quantity, giving a max. tag length of 65536 bytes.

Bootblock entries may appear in any order in a bootblock.

The ISP_DOMAIN, NFS_MOUNT, URL_INIT, and NCD_INFO fields have been removed from the dial-up script to become entries in their own right.

1.2.4 Tag IDs

1.2.5 Special case tag entries

NULL TAG 0x00 - to pad out bootblocks

TAG_ID		0
TAG_LEN_LSB	0
TAG_LEN_MSB	0
TAG_DATA	none

CHECKSUM TAG 0xff - terminates and verifies a bootblock

TAG_ID		0xff
TAG_LEN_LSB	4
TAG_LEN_MSB	0
TAG_DATA	(checksum word) 

some sort of simple checksum, maybe a CRC.

NAMED_RECORD 0xfe - a datum providing it's own tag symbol.

TAG_ID		0xfe
TAG_LEN_LSB	n
TAG_LEN_MSB	m
DATA[n]		BYTE flags {
		     BIT updateable
		     BIT overrideable
                }
		BYTE[a] TAG_NAME/0
		BYTE[b] TAG_DATA

This tag will add a soft mapping to the registry's tag mapping table. The TAG_DATA may be fetched by registry clients using the TAG_NAME encoded in the entry. Soft mappings have no mandatory bit, as it doesn't make any sense in this context.

Named records may be used to add new information to a bootblock, eg an interface could store it's unique paramaters.

1.3 NCRegistry tag mappings

The registry maintains a list of mappings of tags it knows about:

  WORD tag_id 		; matches the tag ids in bootblock entries
  STRING tag_name	; symbol for the tag - used in client enquiries
  WORD flags {
	BIT mandatory	; this tag must be present in a valid bootblock
	BIT updateable	; this tag may be overwritten
	BIT overrideable; this tag may be overridden by a soft bootblock
  }
  WORD offset		; used to decode multibit tags
  WORD mask		; used to decode multibit tags

tag_ids may be mapped to more than one tag_name symbol.

1.4 NCRegistry startup

On smartcard insertion the registry determines what network interfaces are present and searches the smartcard index file for a matching bootblock. The first correct match is used. Eventually this process may need to be extended to accomodate multiple interfaces per NC, with a bootblock for each, or multiple bootblocks per interface. Arbitration will require user input, or input from the NC configuration application.

Only one bootblock is active at any given time. Removal of the smartcard causes all registry structures to be reset, pending the insertion of another smartcard.

On finding a valid bootblock, the registry will determine whether CHV1 pin locking is enabled and load it, obtaining the PIN where necessary.

The bootblock is checked against its checksum. If this fails, the bootblock is considered invalid and is ignored by the registry.

Bootblock entries are validated - unrecognized tag_ids may cause the bootblock to be considered invalid, subject to version control (see below).

The registry checks that all mandatory bootblock entries are present in the bootblock - if not, the bootblock is considered invalid.

The registry then adds any soft tag mappings to its mapping table.

The registry then continues as normal.

1.5 Version control

It is proposed that the current 32 bit version field in the bootblock be split into two 16 bit values, a major version number and a minor version number.

Releases of the registry will carry two major version numbers and one minor version number. The two major version numbers will provide the current major version, and the minimum backwards-compatible version. This is provided so that obsolete bootblock interpreter code may be phased out of future registry releases.

Major version numbers will be used for significant upheavals in the format. A version of the registry will be able to interpret all bootblocks with lesser major version numbers, provided the major version number is greater than or equal to the registry's minimum backwards-compatibility version. If bootblocks are encountered with a higher major version number than the executing registry module, the bootblock will be marked invalid.

A registry implementation will operate with a lower minor version bootblock, provided that there is sufficient information in the bootblock for the registry to meet its mandatory tag requirements. Failure to do so will result in the bootblock being marked invalid.

If the bootblock minor version is less than or equal to the current registry minor version, unrecognised tag_ids will cause the bootblock to be considered invalid.

A registry implementation will operate with a higher minor version bootblock, provided that its mandatory flag requirements can be met. In this case, unrecognized tag ids in the bootblock will be ignored by the registry - it will merely track them for storage reasons, but will not attempt to interpret them.

This revision of the Registry software will maintain backwards-compatibility with current smartcards ie. smartcards in the field will not need to be reprogrammed.

1.6 Client Interface

The client <--> registry interface will remain the same for compatibility. Additional status bits will be added to status words to indicate bootblock failure due to version issues (ie 'too old' and 'too new' flags).

Registry enquiries will return additional status information concerning the bootblock entry (the entry tags, plus an indication of whether the tag is a soft mapping or not).

New SWIs will be added to allow the creation, editing, and removal of soft tag mappings. Soft tag mappings will be written to the smartcard immediately, and will become active after a successful write.

1.7 Proposed changes to bootblock entries

This section details bootblock entries which have changed since the previous version, within the scope of the entirely new bootblock structure.

Note that the move to variable length fields for all bootblock entries removes the 24 character restriction on LOGIN_ID and LOGIN_SECRET which has been causing problems with AT&T's dial-up system.

1.8 Bug fixes

A bug exists in the registry in ROM release version 1.06 - this causes a PIN to be requested even if it has not been set on the card. This has been identified and fixed, and the modification will be incorporated into the new registry code.

1.9 Module locations

The new registry modules NCRegistry and NCRegistrySpprt are present in the modem ROM but are not present in the ethernet ROM. These are loaded from the server as part of the boot process for ethernet NCs and are released as part of the NC server release.

2.0 Smartcard Programming

Although smartcard programming software is not built into the ethernet or modem ROM it is tied quite closely to the changes in the smartcard bootblock contents and to the changes in the Registry modules. For this reason, changes to the smartcard programming software are described in this specification.

The current smartcard programming software will be modified so that it can write smartcards with the new bootblock format described in section 1.0. It will also be converted into a module named SCProgram as described below.

The current procedure for programming smartcards will be changed. In the next version the programming software will be update to allow users to write/edit a script file on an NC and program the card at the click of a button.

A default smart card script will be written and saved on the server with a script filetype. The Browser can display a HTML page containing links to all the scripts by entering the URL of the scripts directory.

Users can click on a smartcard script and it will be loaded by the new SCProgram module, this module will take the script and create a HTML based form containing the name of the file and the contents of the script. The module will then request the Browser to display this HTML page, which will look similar to this:

The user will then be able to change the filename and then edit the script in the form before either, saving the script back to the server or programming the smart card. The SCProgram module will compile the script before saving or programming and will report any errors that may exist in it.

3.0 NC line-dropping changes

There is a problem with the NC not dropping the line properly when it is instructed to do so. This will be investigated and resolved in the new modem ROM.

4.0 PAP / CHAP Problems

PAP/CHAP authentication appears to have broken between modem ROM releases 0.17 and 0.22 . This problem will be investigated and resolved in the new modem ROM.

5.0 CLIprotect module

5.1 Preventing access to the command line

The CLIprotect module will be added to prevent unauthorized access to the command line interpreter. This module already exists in modem ROM release 0.22 and will also be added to the new ethernet ROM. Any attempt to access the command line will cause the NC to reset immediately.

5.2 Preventing execution of arbitrary files

Sufficient protection exists in the NC OS to prevent a user being able to run arbitrary files from an NC. However, it is possible to create files on an NFS system from another computer which may be subsequently run on an NC, provided that the NC understands its file type.

To tighten security in this area, !Sennen will be modified to intercept the following file types:

• Desktop (0xfea)
• Obey (0xfeb)
• Module (0xffa)
• BASIC (0xffb)
• Command (0xffe)
• Absolute (0xff8)
• Utility (0xffc)

This modification has already been made to modem ROMs with version numbers 0.22 or higher. On ethernet NCs the application is run from the server and so does not form part of the ethernet ROM.

Other types of files will not be executed by the NC, as it does not recognize their file types. Recognized filetypes may be added to the main boot file in the NC's read-only NFS mount, however.

6.0 Window Manager Module

The latest version of the Window Manager module will also be added to the modem ROM. This will replace the Window Manager in the main ROM. In the case of ethernet NCs the new Window Manager is not present in ROM but is loaded from the server as part of the boot process.

7.0 Expansion ROM Version Module

A new module will be added to both the ethernet and modem ROMs to update the configuration application to display the current ROM version number.

8.0 BOOTP extensions

The ethernet ROM is enhanced to provide support for extensions to the BOOTP protocol as specified in RFC-1048 and RFC-1533. The Internet module is extended and included in the ethernet ROM so that the NC can determine the following information from the extended BOOTP reply packets which are sent by the server (fields marked * are new functionality):

The DoBootP module in the ethernet ROM is extended to read Inet$Gateway and Inet$EtherIPMask as set by the Internet module and to set up the appropriate route and net-mask required.

Note that these BOOTP extensions must be enabled at the server end by including the ":vm=rfc1048:" field in the /etc/bootptab file to set the magic value in the vendor specific data within the BOOTP reply packet.

9.0 Future possibilities

It may be possible for the registry to upgrade an old minor format version bootblock to the current format - this would involve pruning tags which are no longer recognized by the registry, and converting any soft tag mappings which now have hard mapped tag ids into proper bootblock entries. This functionality is NOT planned initially. It may well be the case that this sort of function would be better served by a script on an ISP's server.