| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 397.1 | TSIX vs. MAxSix 1.0 | NETRIX::"bayerl@zk3.dec.com" | Andy Bayerl | Tue Sep 17 1996 19:49 | 36 |
| 397.2 | following up... | SMURF::BAT | Segui la tua beatitudine | Tue Mar 18 1997 00:18 | 3 |
| I spoke with Jim Fohlin, who will be going with the site tomorrow with
Sam to see if they can find out what the problem is. He'll call once
there.
|
| 397.3 | www.zk3.dec.com/sec/MLS/standards/tsig/tsix/interop | SMURF::BAT | Segui la tua beatitudine | Tue Mar 18 1997 17:52 | 244 |
|
TSIX(re) 1.0 Configuration
[Digital MLS+] <=== CIPSO + TSIX(re) 1.0 ===>[HPUX CMW+]
(Select the Digital or HP logo for vendor specific configuration)
----------------------------------------------------------------------------
* Define the following two hosts:
o 192.26.50.1 decmls
o 192.26.50.2 hpcmw
* If you are using CIPSO network labelling, follow the steps for
configuring a CIPSO Domain of Interpretation.
* On both systems configure the remote host entry for the other system
o Specify that TSIX(re) 1.0 session management is to be used
o Specify that all attributes, except for Clearance are be sent
o Select the appropriate IP labelling type and DOI as needed
o Specify an appropriate minimum and maximum sensitivity level to be
used as the accreditation range of the other system
* Determine any mapping that might be needed for attributes
o In our case the systems are using the same encodings but we will
specify mapping tables on the HP side for illustration purposes.
For this example we used an encodings file very similar to the
sample which comes with MLS+ 3.1a and is the default on HP CMW:
/etc/policy/macilb/Encodings.MITRE If your encodings are different
then you may specify NO_MAPPING if both systems use the same
encodings or you may have to create mapping tables tailored to
your encoding.
o Since both systems have different privilege sets, you will also
need to specify on the HP system a mapping table to be used for
privileges.
* Follow system specific instructions for get the trusted network to to
start using the above changes.
Configuring a TSIX 1.0 Host on MLS+ 3.1a
[Digital MLS+]=== CIPSO + TSIX(re) 1.0 ===>[HPUX CMW+]
----------------------------------------------------------------------------
1. Create a CIPSO Domain of Interpretation
If you are not using network labelling, then you may proceed directly
to step 2, specifying unlabeled for the host type. Otherwise, update
the tsix_cipso Domain of interpretation as shown for the CIPSO only
configuration.
2. Add a Token Mapping Domain of Translation
Add a dec_3_0 DOT to /tcb/files/TNETDOMAINDB with the charactistics
below. Note, that the name is chosen to correspond with the DOT that
appears by default in the M6DOMAINS file on the HP side.
o Name: dec_3_0
o Type: token_map
o Weight: 250
o ASCII: SL,ILB,LUID,IDS,PRIVS
3. Add (or modify) the Remote Host Entry for hpcmw
Use Add Host in the Network ISSO tool and select the following:
o Name: hpcmw
o Address: 192.26.52.2
o Template: default_tsix_1_0
o Network Labelling Type: CIPSO
o Session Attributes and Defaults: Allow Non-Standard Settings of
Attributes
+ Clearance TOP SECRET NATO ALPHA ...
+ SL <Value from Session>
+ IL <Value from Session>
+ Privileges <Value from Session>
+ LUID <Value from Session>
+ UID <Value from Session>
+ GID <Value from Session>
+ GIDs <Value from Session>
+ Session Id <Value from Session>
+ Process Id <Value from Session>
o Accreditation Range:
UNCLASSIFIED || TOP SECRET NATO ALPHA ...
o Domain of Interpretation: tsix_cipso
Note, that we must use defaults for the clearance since it does not
appear that there is a way to specify on HP that clearance should be
sent.
4. The end result of the above steps should be:
o An entry in /tcb/files/TNETRHDB that looks something like this:
hpcmw:\
default_spec = default_tsix_1_0 :\
doi = tsix_cipso : \
nlm_type = cipso : \
max_sl = TOP SECRET NATO ALPHA SIOP ULTRA SAC TRIDENT :
\
flags =
export,import,mand_sl,mand_ilb,mand_privs,mand_luid,mand_ids,mand_sid,mand_pid
\:
o Entries in /tcb/files/TNETDOMAINDB that look something like this:
tsix_cipso: \
type = cipso:\
number = 12 :
dec_3_0: \
type = token_map:\
weight = 250:\
ascii = sl,ilb,luid,ids,privs:
5. Restart the trusted networking daemons
When you are satisfies with your changes, stop and restart the trusted
network daemons with the following commands (or reboot the system):
/usr/tcb/bin/tnetd_stop
/usr/tcb/bin/tnetd_start
Configuring a TSIX 1.0 Host on HP CMW 10.09
[Digital MLS+] <=== CIPSO + TSIX(re) 1.0 ===>[HPUX CMW+]
----------------------------------------------------------------------------
1. Create a CIPSO Domain of Interpretation
If you are not using network labelling, then you may proceed directly
to step 2, specifying unlabeled for the host type. Otherwise, create
the tsix_cipso Domain of interpretation as shown for the CIPSO only
configuration.
2. Add the Remote Host Entry for decmls
Create a new host using the network administrator tool, selecting the
following:
o Name: decmls
o Address: 192.26.52.1
o Host Type: cipso
o SMM Type: standard
o Attributes:
SL,ILB,PRIVS,LUID,IDS,SID,PID
o DOI: tsix_cipso
Note, that if you are not using network labelling, then you should be
able to specify unlabeled for the host type above. We did not test
this, however.
3. Modify the dec_3_0 Domain of Translation (DOT)
Modify the dec_3_0 entry in /tcb/files/M6DOMAINS using the network
administrator tool, selecting the following:
o Name: dec_3_0
o Type: token_map
o Mapping Tables:
class = NO_MAPPING
categories = NO_MAPPING
markings = NO_MAPPING
privs = dec_3_0_privs
uids = NO_MAPPING
gids = NO_MAPPING
o Mappings Flags (for opt_data):
SL,ILB,PRIVS,LUID,UID,GID,GROUPS
Note, that M6DOMAINS entries, when saved by the network manager tool,
seem to end up with an empty type field. You may have to manually edit
/tcb/files/M6DOMAINS to contain the following:
type = token_map:\
4. Check the Mapping Tables
In this example we specified a mappings table for privileges only. You
may need to look at the default dec_3_0_privs mappings table to verify
that privileges are correctly mapped. We did not specify mappings for
sensitivity and information labels, since we used the same encodings on
both systems. If your encodings are not identical, you may have to
supply mappings tables for class, categories, and markings.
5. The end result of the above steps should be:
o An entry in /tcb/files/M6RHDB that looks something like this:
192.26.50.1: \
min_sl = UNCLASSIFIED: \
max_sl = TOP SECRET NATO ALPHA SIOP ULTRA SAC TRIDENT: \
attributes = sl, ilb, privs, luid, ids, sid, pid: \
flags = import, export: \
max_privs = : \
host_type = cipso: \
cache_size = 512: \
smm_type = tsix: \
auth_type = standard: \
encrypt_type = standard: \
doi = tsix_cipso :
o An entry in /tcb/files/M6DOMAINS that looks something like this:
dec_3_0: \
type = token_map:\
number = 8:\
opt_data = 0x180f :\
weighing_factor = 250 :\
privs = dec_3_0_privs: \
class = NO_MAPPING: \
cat = NO_MAPPING: \
mark = NO_MAPPING: \
uids = NO_MAPPING: \
gids = NO_MAPPING: \
6. Reboot the HP CMW System
When you are satisfies with your changes, you should reboot to ensure
that the changes take effect. In general you will need to reboot
whenever you change M6DOMAINS or M6MAPPINGS. If you only add or change
M6RHDB, you will simply need to use the config menu item of the network
manager tool to reread the remote host entry for the host you have
changed.
|
| 397.4 | cipso configuration | SMURF::BAT | Segui la tua beatitudine | Wed Mar 19 1997 00:27 | 205 |
|
CIPSO Configuration
[Digital MLS+]<=== CIPSO ===>[HPUX CMW+]
(Select the Digital or HP logo for vendor specific configuration
----------------------------------------------------------------------------
* Define the following two hosts:
o 192.26.50.1 decmls
o 192.26.50.2 hpcmw
* Configure a common Domain of Interpretation (DOI) to be used for
network labelling
o Use the same unique DOI number on both systems. The HP as shipped
has a DOI numbers 1-11 already in use, so for this exercise we
have chosen 12.
o Pick a name for the DOI on both systems. It doesn't have to be the
same on both but for clarity we will use tsix_cipso here.
(see below)
* On both systems configure the remote host entry for the other system
o Specify that Sensitivity Level is the only attribute to be sent.
i.e.,
flags = mand_sl:\
o Select cipso as the IP labelling type
i.e.,
nlm_type = cipso:\
o Specify an appropriate minimum and maximum sensitivity level to be
used as the accreditation range of the other system
e.g.,
min_sl = minsl:\
max_sl = syshi:\
* Determine whether any mapping is needed between the sensitivity labels
on both systems. In our case the systems are using the same encodings
but we will specify mapping tables on the HP side for illustration
purposes. Note that for this example we used an encodings file very
similar to this sample which comes with MLS+ 3.1a and is the default on
HP CMW: /etc/policy/macilb/Encodings.MITRE
* Follow system specific instructions for getting the trusted network to
to start using the above changes.
==========================================================================
Configuring a CIPSO Host on MLS+ 3.1a
[Digital MLS+] === CIPSO ===>[HPUX CMW+]
----------------------------------------------------------------------------
1. Add the Remote Host Entry for hpcmw
Use Add Host in the Network ISSO tool and select the following:
o Name: hpcmw
o Address: 192.26.52.2
o Template: default_single_level
o Network Labelling Type: CIPSO
o Session Attributes and Defaults: Allow Non-Standard Settings of
Attributes
SL
o Accreditation Range:
UNCLASSIFIED || TOP SECRET NATO ALPHA ...
o Domain of Interpretation: tsix_cipso
2. Update the tsix_cipso DOI
Use the Configuration->TNETDOMAINDB menu item in the Network ISSO tool
and change the DOI number for tsix_cipso to 12.
3. The end result of the above steps should be:
o An entry in /tcb/files/TNETRHDB that looks something like this:
hpcmw:\
default_spec = default_single_level :\
doi = tsix_cipso : \
nlm_type = cipso : \
max_sl = TOP SECRET NATO ALPHA SIOP ULTRA SAC TRIDENT :
\
flags = export,import,mand_sl:
o An entry in /tcb/files/TNETDOMAINDB that looks something like
this:
tsix_cipso: \
type = cipso:\
number = 12 :
4. Restart the trusted networking daemons:
When you are satisfies with your changes, stop and restart the trusted
network daemons with the following commands:
/usr/tcb/bin/tnetd_stop
/usr/tcb/bin/tnetd_start
==========================================================================
Configuring a CIPSO Host on HP CMW 10.09
[Digital MLS+] <=== CIPSO ===[HPUX CMW+]
----------------------------------------------------------------------------
1. Add a Domain of Interpretation
Create a tsix_cipso DOI using the network administrator tool, selecting
the following:
o Name: tsix_cipso
o Type: cipso
o Mapping Tables:
class = std_cipso_class
categories = std_cipso_cat
o Mappings Flags (for opt_data):
SL
o DOI: tsix_cipso
Note, that M6DOMAINS entries, when saved by the network manager tool,
seem to end up with an empty field. You may have to manually edit
/tcb/files/M6DOMAINS to contain the following: type = cipso:\
2. Add the Remote Host Entry for decmls
Create a new host using the network administrator tool, selecting the
following:
o Name: decmls
o Address: 192.26.52.1
o Host Type: cipso
o SMM Type: standard
o Attributes:
SL
o DOI: tsix_cipso
3. Check the Mapping Tables
In this example we specified mappings tables for the class and
categories which will make up a CIPSO label. You may need to look at
the default mappings tables that are supplied to verify that the clas
and compartment numbers correspond to the local and remote encodings
values. If not, you will need to edit the /tcb/files/M6MAPPINGS file(s)
and run m6parser(8) command. Alternatively, you could specify
NO_MAPPING if you have the same encodings on both systems.
4. The end result of the above steps should be:
o An entry in /tcb/files/M6RHDB that looks something like this:
192.26.50.1: \
min_sl = UNCLASSIFIED: \
max_sl = TOP SECRET NATO ALPHA SIOP ULTRA SAC TRIDENT: \
attributes = sl: \
flags = import, export: \
max_privs = : \
host_type = cipso: \
cache_size = 512: \
smm_type = standard: \
auth_type = standard: \
encrypt_type = standard: \
doi = tsix_cipso :
o An entry in /tcb/files/M6DOMAINS that looks something like this:
tsix_cipso: \
type = cipso:\
number = 12 :\
opt_data = 0x1 :\
weighing_factor = 0 :\
class = std_cipso_class: \
cat = std_cipso_cats:
5. Reboot the HP CMW System
When you are satisfies with your changes, you should reboot to ensure
that the changes take effect. In general you will need to reboot
whenever you change M6DOMAINS or M6MAPPINGS. If you only add or change
M6RHDB, you will simply need to use the config menu item of the network
manager tool to reread the remote host entry for the host you have
changed.
|
| 397.5 | missed by 2 seconds | SMURF::BAT | Segui la tua beatitudine | Wed Mar 19 1997 00:28 | 81 |
| From: KAMLIA::thomson "Barbara Thomson UEG Engineering 18-Mar-1997 2110" 18-MAR-1997 21:15:22.75
To: jcf@gsg.dec.com
CC: smurf::bat
Subj: re: your voicemail of 6:31PM
I missed you by 2 seconds but it hadn't stored your
message yet, so I only just got that.
1. "Why are 'we' using CIPSO, since the customer needs 1024
compartments? Someone here thought that CIPSO doesn't support
that many compartments?"
I believe RIPSO[=IPSO] (see RFC 1108) is the one with the
limitation on the number of compartments -- actually it's really
a limit on the number of thingys that you can map to labels
(level+compartment). This is because it puts the SL "labels"
for the data in the IP options field of the IP header.
There's only about 40 bytes to play with, and so there's
not much room. And it doesn't handle any other types of
security attribute (privileges, ILs, IDs, etc.)
CIPSO is the security attribute encoding method that
puts the attributes in the body of the IP packet, instead
of the header, and therefore it can support more compartments.
(And more types of security attributes.)
The CIPSO spec I found, at least to my quick scan,
implies that it can support up to 255 sensitivity levels
and 65535 categories (compartments). But I could be wrong.
I'm sending you the specs I found, you can pass on to
the customer or not as you please.
2. "With the changes I made, we can now ping, but telnet
from MLS+->SCO fails with 'Connection closed by foreign
host' after the 'Trying, connected' message and
telnet from SCO-> MLS+ just hangs after it prints
the escape characters message. There are many errors
reported in the tndbmd and tnmapd .log files, too many
to read over the phone."
We need the error messages, so we can look up to
see what error is happening. Some message may not
be errors, they just may be informational.
The fact that you are getting errors in tndbmd might
mean, for example, (assuming you are getting these in real-time,
i.e., you are doing a tail -f on the log file while doing
the telnet) that you may have errors in the TNETDB itself.
"tndbmd: TNETDB is corrupt" is the message,
solution: remake the TNETDB
(if it won't remake properly, then you've got bad data
in TNETRHDB e.g., you're missing a tab character
at the beginning of each continuation line or a
RETURN character after every backslash
[continuation character] or some other such thing.)
/tcb/bin/tnetd_up will remake the TNETDB
I'll send next mail a list of the ones I got on a search
in the sources as a sample.
3. Here's an idea: can you send me the TNETRHDB and TNETDOMAINDB
you are using? (Or read the significant entries to me over the
phone) [assuming there is nothing confidential in them]
I will load them up on two MLS+ V3.1A systems here, and
see if they will talk to each other. If they reciprocate
fine, then the problem is that the setup we're using does
not match the way it is implemented in the SCO CMW box.
We may have to fallback to the MaxSix 1.0 setup (a la
Sun CMW). (If you have a second MLS+ V3.1A box there that
you could set up to talk with the first MLS+ V3.1A box,
you too could test this there.)
4. That's all the ideas I have for the moment.
I'll speak to Mike and/or Phil about using some
outside consulting time.
|
| 397.5 | need andy | SMURF::BAT | Segui la tua beatitudine | Fri Mar 21 1997 16:50 | 70 |
|
1. "Why are 'we' using CIPSO, since the customer needs 1024
compartments? Someone here thought that CIPSO doesn't support
that many compartments?"
Both RIPSO=IPSO and CIPSO put labels in the IP header options
field. RIPSO is limited to something like 16 "things", CIPSO,
it depends.
The CIPSO spec I found, at least to my quick scan,
implies that it can support up to 255 sensitivity levels
and 65535 categories (compartments).
But evidently it doesn't support that many compartments
simultaneously (i.e., in a given label for a packet) because
it is still bound without some sort of mapping, because there
still a limit of 40 bytes to the IP option length.
I'm sending you the specs I found, you can pass on to
the customer or not as you please. (http://www.tsig.org or
www.zk3.dec.com/sec/MLS/tsig
2. "With the changes I made, we can now ping, but telnet
from MLS+->SCO fails with 'Connection closed by foreign
host' after the 'Trying, connected' message and
telnet from SCO-> MLS+ just hangs after it prints
the escape characters message. There are many errors
reported in the tndbmd and tnmapd .log files, too many
to read over the phone."
We need the error messages, so we can look up to
see what error is happening. Some message may not
be errors, they just may be informational.
The fact that you are getting errors in tndbmd might
mean, for example, (assuming you are getting these in real-time,
i.e., you are doing a tail -f on the log file while doing
the telnet) that you may have errors in the TNETDB itself.
"tndbmd: TNETDB is corrupt" is the message,
solution: remake the TNETDB
(if it won't remake properly, then you've got bad data
in TNETRHDB e.g., you're missing a tab character
at the beginning of each continuation line or a
RETURN character after every backslash
[continuation character] or some other such thing.)
/tcb/bin/tnetd_up will remake the TNETDB
I'll send next mail a list of the ones I got on a search
in the sources as a sample.
3. Here's an idea: can you send me the TNETRHDB and TNETDOMAINDB
you are using? (Or read the significant entries to me over the
phone) [assuming there is nothing confidential in them]
I will load them up on two MLS+ V3.1A systems here, and
see if they will talk to each other. If they reciprocate
fine, then the problem is that the setup we're using does
not match the way it is implemented in the SCO CMW box.
We may have to fallback to the MaxSix 1.0 setup (a la
Sun CMW). (If you have a second MLS+ V3.1A box there that
you could set up to talk with the first MLS+ V3.1A box,
you too could test this there.)
4. That's all the ideas I have for the moment.
I'll speak to Mike and/or Phil about using some
outside consulting time.
|
| 397.6 | demo in progress as we speak (we think) | SMURF::BAT | Segui la tua beatitudine | Fri Mar 21 1997 16:57 | 17 |
| We got Andy and he recommended that if they are using MaxSix1.0, to
send both the SL and the session ID (flags=mand_sl,mand_sid in TNETRHDB
or in the M6RHDB, attributes=sl,sid). They got that working.
Andy also recommended that they use MaxSix3.0, aka tsix1_0, for the
smm_type, and unlabelled for the nlm_type. This will enable them
to support 1024 compartments, and not have to worry about mappings for
RIPSO or CIPSO because they are not using any routers or other systems
that need any info in the IP header options field. And they can be
sure that all the attributes they want will be passed (privs, ids,
etc.).
They will try that after the demo, if the demo launches something.
(In the meantime they ran into a problem with Trusted Oracle, in that
it has a limit of 256 compartments, or bytes, or something, which they
will have to work around for the moment.)
|
| 397.7 | sun<->dec maxsix1.0 smm_type=tnet | SMURF::BAT | Segui la tua beatitudine | Wed Apr 02 1997 00:30 | 73 |
| From: US2RMC::"CWOLF@us.oracle.com" "CWOLF.US.ORACLE.COM" 1-APR-1997 20:11:45.47
To: smurf::bat, thomson@zk3.dec.com
CC: CWOLF.US.oramail@us.oracle.com
Subj: Test results
Barbara,
Here are the results of using a Sun box as my maxsix1.0 client.
Maybe you can pass this on to Andy to see what he says.
Thanks,
-Chris
nlm_type = tnet
_______________________________________________________________________________
Sun DEC Results
------+------------------------------------------------------------------------
PRIVS | noprivs noprivs errno = 53
LABEL | unclassified unclassified
SID | none 3
------+------------------------------------------------------------------------
noprivs allowmacaccess
unclassified unclassified
no traffic no traffic errno = 53
------+------------------------------------------------------------------------
net_session allowmacaccess it works
unclassified unclassified
3 3
------+------------------------------------------------------------------------
net_session allowmacaccess it works, says client = unclassified
secret unclassified
3 3
------+------------------------------------------------------------------------
net_session allowmacaccess it works, says client = unclassified
+allownetaccess
secret unclassified
33416519 33416519
------+------------------------------------------------------------------------
nlm_type = unlabeled
_______________________________________________________________________________
SUN DEC
------+------------------------------------------------------------------------
net_session allowmacaccess Connects, can send traffic from
sun->dec
unclassified unclassified Fails upon first write dec->sun
3 none
------+------------------------------------------------------------------------
+------------------------------------------------------------------------+
| ORACLE Corporation |
| cwolf@us.oracle.com |
| Chris Wolf, Senior Software Engineer Voice +1.415.506.2529 |
| World Wide Government & Education Fax +1.415.506.7800 |
| Products Division |
+------------------------------------------------------------------------+
|
| 397.8 | need Fran's input | SMURF::BAT | Segui la tua beatitudine | Thu Apr 03 1997 17:14 | 19 |
| From: US2RMC::"CWOLF@us.oracle.com" "CWOLF.US.ORACLE.COM" 2-APR-1997 22:59:40.26
To: "jcf@gsg.dec.com"@us.oracle.com
CC: "becker@mail.dec.com"@us.oracle.com, smurf::bat, thomson@zk3.dec.com, JBOTELHO.US.oramail@us.oracle.com, ASCHEN.US.oramail@us.oracle.com
Subj: TCS status
Alright, the listener is now working with the maxsix protocol. It turns
out that this protocol, unlike CIPSO, tnet or tsix needs allowmacaccess
and allowilbaccess raised for each and every read from the socket.
I recommned an OS change to not require this because of the overhead.
-Chris
+------------------------------------------------------------------------+
| ORACLE Corporation |
| cwolf@us.oracle.com |
| Chris Wolf, Senior Software Engineer Voice +1.415.506.2529 |
| World Wide Government & Education Fax +1.415.506.7800 |
| Products Division |
+------------------------------------------------------------------------+
|