RE: SunScreen v3.1 to v3.0b communications

From: Valerie Anne Bubb (Valerie.Bubb@Sun.COM)
Date: 10/05/01 

Message-Id: <200110042232.PAA15722@phys-ha2mpka-16.Eng.Sun.COM>
Date: Thu, 4 Oct 2001 15:32:32 -0700 (PDT)
From: Valerie Anne Bubb <Valerie.Bubb@Sun.COM>
Subject: RE: SunScreen v3.1 to v3.0b communications
To: focus-sun@securityfocus.com, sean@boran.com

Sean -

Combining both of your emails, since some details in each need
to be responded to. :)

>From: "Sean Boran" <sean@boran.com>
>

>> >Create new one:
>> >skiplocal -k -m 512
>> >Print out command for other side:
>> >skiplocal -x
>> >Add local and remote certs to Sunscreen engine:
>> >ssadm edit Mypolicy
>> >edit> list certificate
>> >edit> add certificate "admin-group" GROUP "remote"
>> >edit> add certificate  "remote" SINGLE NSID 8 MKID
>> >"0x4fd3a1eec3a168e1lotsofcrap"
>> >edit> add certificate  "MyScreen.admin" SINGLE NSID 8 MKID
>> >"0x9c6e6b0822b590otsofcrap"
>> >edit> save
>> >ssadm activate Mypolicy
>> >skipd_restart
>>
>> Have you set up an accessRemote rule? (one would have been set
>> up by default with ss_install if you said you wanted remote
>> administration, and you would only need to update the key now).
>> If so, what does it look like?
>
>add service "remote administration" GROUP ss_admin ping ssh
>
>No actual rule is needed AFAIK?

Yes, you need a special remote administration rule, "accessRemote"
type. You should also have accessLocal rules (which specify which
users can do administration, and what their priveledges are).

W/out such a rule, SKIP will know how to do the decryption, but
SunScreen will not know that the traffic is indeed allowed.

>When I do an ssadrm -r ss3 login admin from the Admins statn , a snoop
>on the ss sees only the following every 30 secs or so until the login
>times out.
>
> admin -> ss3 TCP D=3853 S=34325 Syn Seq=1097095997 Len=0
>Win=928
>2 Options=<mss 1326>

FYI: When you can see something like "TCP" or "UDP" (ie you can
identify the protocol of the traffic), then it is not being
encrypted by SKIP. SKIP encrypts at the IP layer, so everything
is encapsulated into a new IP type 57 packet.

I see from your next email that you resolved this.

your next message:

>I restarted SKIP on both sides and now I see the CDP which seems to
>work:
>
>On the ss, the skipd.log says:
>Thu Oct 4 11:40:59 2001 action=get nsid=8 mkid=90b299b8b1xxxx
>cert=NULL response=getok (1 cert)
>Thu Oct 4 11:41:00 2001 Calculating Shared secret for 4fd3a1eec3axxxxxx
>
>However, the login still doesn't work.
>So some kind of cert exchange is working, but then it grinds to a halt..
>(Surely a cert exchange should not be needed, since I add the certs to
>each side?)

A bit of background on SKIP: what you've actually exchanged are
the MKIDs (sort of like "names") of the certificates - not the
actual certificates themselves. SKIP uses these MKIDs and CDP
(certificate discovery protocol) to actually exchange the certifcates
on the wire. (This can be done manually via floppy, if you do not want to
use CDP).

I image what is not working now is that you do not have a
remote administration rule (different from regular packet filtering
rules), so SunScreen does not know what to do with the packet
after it's been decrypted (and it's default action is to then
drop the packet). You should be able to see this "default drop"
if you turn on debugging on the screen console:
# ssadm debug_level 1000

hth

Valerie