Sorry to disappoint Chris but I'm a little overworked right now for a
long one. However.....(gotcha).... you may be confusing packet signing
with encryption. Since early Netware (at least v2.11) the Netware
Client had three levels of packet signature available (never, always,
and if available). The purpose of packet signature is to protect
against session hijacking. So, if you have packet signature enabled on
the client and your server then each packet is signed in such a way that
the recipient can always verify if a received packet has been tampered
with or inserted by a foreign source. The only native encryption has
always been for the password which also has always been hash encrypted
for the login session. The contents of the packet is and always has
been independent of the client's capabilities. So, if you send material
in the clear then it passes from the client to the server (or
server-to-client) in the clear. You can see this in the following two
packet capture fragments (frame 728 and 729) which is a request to
obtain a file from a server and the response (I don't include the
search, obtain info, and open exchanges):
=========================
Frame 728 (90 bytes on wire, 90 bytes captured)
<snip some for space>
Checksum: 0x04a5 (correct)
SEQ/ACK analysis
This is an ACK to the segment in frame: 727
The RTT to ACK the segment was: 0.000082000 seconds
NetWare Core Protocol
NCP over IP signature: Demand Transport (Request) (0x446d6454)
NCP over IP length: 36
NCP over IP Version: 1
NCP over IP Reply Buffer Size: 4098
Type: Service request (0x2222)
Sequence Number: 99
Connection Number: 35
Task Number: 5
Function: 72 (0x48), Read From A File
Group: File
Reserved: 202
File Handle: 0000CB109088
File Offset: 0
Maximum Number of Bytes: 4096
0000: 00 D0 B7 A9 C3 BC 00 07 E9 EC A9 D3 08 00 45 00
..............E.
0010: 00 4C B3 FB 40 00 80 06 AA 8B 9F B2 2F BB 9F B2
.L..@......./...
0020: 2D 05 04 39 02 0C 05 1C 83 FA C5 FB 41 D4 50 18
-..9........A.P.
0030: 80 21 04 A5 00 00 44 6D 64 54 00 00 00 24 00 00
.!....DmdT...$..
0040: 00 01 00 00 10 02 22 22 63 23 05 00 48 CA 00 00
......""c#..H...
0050: CB 10 90 88 00 00 00 00 10 00 ..........
=========================
Frame 729 (233 bytes on wire, 233 bytes captured)
<snip some for space>
Checksum: 0x2256 (correct)
SEQ/ACK analysis
This is an ACK to the segment in frame: 728
The RTT to ACK the segment was: 0.000174000 seconds
NetWare Core Protocol
NCP over IP signature: Transport is NCP (Reply) (0x744e6350)
NCP over IP length: 179
Type: Service reply (0x3333)
Sequence Number: 99
Connection Number: 35
Task Number: 5
Response to Request in Frame Number: 728
Time from Request: 0.000174000 seconds
Function: 72 (0x48), Read From A File
Completion Code: 0 (0x00), OK
Connection Status: 0
Number of Bytes: 161
0000: 00 07 E9 EC A9 D3 00 D0 B7 A9 C3 BC 08 00 45 00
..............E.
0010: 00 DB 1A F8 40 00 80 06 43 00 9F B2 2D 05 9F B2
....@...C...-...
0020: 2F BB 02 0C 04 39 C5 FB 41 D4 05 1C 84 1E 50 18
/....9..A.....P.
0030: 52 49 22 56 00 00 74 4E 63 50 00 00 00 B3 33 33
RI"V..tNcP....33
0040: 63 23 05 00 00 00 00 A1 20 20 31 36 35 31 32 20 c#...... 16512
0050: 62 79 74 65 73 2E 20 20 37 34 33 37 2E 31 34 20 bytes. 7437.14
0060: 4B 42 70 73 2E 20 20 37 34 33 37 2E 31 33 20 41 KBps. 7437.13
A
0070: 67 67 72 65 67 61 74 65 20 4B 42 70 73 2E 0D 0A ggregate
KBps...
0080: 20 20 20 35 31 32 20 62 79 74 65 73 2E 20 20 31 512 bytes.
1
0090: 34 35 30 2E 36 33 20 4B 42 70 73 2E 20 20 31 34 450.63 KBps.
14
00A0: 35 30 2E 36 33 20 41 67 67 72 65 67 61 74 65 20 50.63 Aggregate
00B0: 4B 42 70 73 2E 0D 0A 20 20 37 34 33 37 2E 31 33 KBps...
7437.13
00C0: 20 4D 61 78 69 6D 75 6D 20 4B 42 70 73 2E 20 20 Maximum KBps.
00D0: 20 20 34 34 34 33 2E 38 38 20 41 76 65 72 61 67 4443.88
Averag
00E0: 65 20 4B 42 70 73 2E 0D 0A e KBps...
=========================
Note that in Frame 729 (the requested down loaded text file) that the
file contents are in the clear. But in both frames, there is a unique
packet signature (NCP over IP signature:).
(if you are interested, the text simply reads:
16512 bytes. 7437.14 KBps. 7437.13 Aggregate KBps.
512 bytes. 1450.63 KBps. 1450.63 Aggregate KBps.
7437.13 Maximum KBps. 4443.88 Average KBps.
which is the captured output of an old Novell PERFORM3 utility)
So, while the packets are signed (and thus more difficult to hijack)
they are NOT encrypted. It is the responsibility of a higher
application level to provide encryption services of the transmitted
packet contents (eg VPN, PGP, etc.). VPN provides an automatic
encryption level for transport between the "open" network region and the
"trusted" network region as has been previously pointed out in recent
VPN discussions. PGP or some other mechanism must provide the
application-to-application encryption.
Now, Novell's move to "open systems" over the past 4 years or so has
been moving away from the proprietary client for connection services.
Most management functions and the new Virtual Office (iPrint, iFile,
etc) depend on browsers and standards based encryption for transport
services. In particular, SSL is the method most often implemented in
the new connections. This is true for most secure login, directory
services (including secure LDAP), Novell Instant Messaging, and other
transport services. All such are built around Novell International
Cryptographic Services (NICI) which is available world-wide. Future
applications running on Novell servers (including SUSE AG) have access
to the NICI API's to provide full application-to-application encryption
if the builders so desire it.
GroupWise (the Novell e-mail/collaboration suite) is one exception that
has always encrypted the contents of the message during all transport
and storage within a MTA-to-MTA, MTA-PO, PO-PO, or MTA-PO-GATEWAY
context. However, even with GroupWise, if the message leaves the Novell
environment (ie goes out an SMTP gateway to the Internet) then it gets
converted back into a non-encrypted format so "foreign" systems can
interpret the results. The latest versions of GroupWise gateways allow
SSL SMTP-to-SMTP connections to maintain the transport encryption, but
if the destination is not a known GW PO then the message itself will
still be delivered on the other side of the receiving SMTP gateway as
clear text unless the message was separately encrypted. GroupWise
systems can be known to each other in a number of ways including special
SRV records in DNS so that message AND transport can remain encrypted to
GW standards (see TID2941929).
Well, it's not four pages, but it does cover a lot. Mainly, it should
be clear from the above that the Novell Client should NOT be considered
an encrypting substitute for other transport (VPN, SSL, SSH, etc) or
application-to-application encryption. What the client provides is
encrypted passwords and a packet signing protocol that makes hijacking
sessions difficult. But that later concept may be somewhat obsolete in
our session-less client-server connections of today.
Ken Massey
>>> Chris Meyers <[log in to unmask]> 8/6/2004 2:37:33 PM >>>
Novell has support packet encryption for over a decade (beginning in
the
days of NW 3.x and IPX). Packet signing over IP is (and has) been
completely supported in every version of Netware that natively runs
IP.
You have to make sure both the client and server agree on the level of
packet signing AND you have to make NICI is properly configured.
I'm sure (hope) Mr. Massey will weigh in with a 4-page post outlining
all the permutations of packet encryption for each and every verson of
Netware going back to 2.x ;-)
URLS of interest...
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10024712.htm
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10057465.htm
c
>>> Bob Johnson <[log in to unmask]> 8/5/04 6:44:50 PM >>>
<snip>
>
> On a separate note. Does anyone know how secure communication is if
I
> connect to a Novel server across an IP network? For example if
someone
> could intercept the packets would they get any useful information
out
of
> them?
>
I'll pass on that one, too, although my vague recollection is that
recent versions of Novell use encryption.
- Bob
**********************************************************************
This message and any attachments are intended only for the individual
to whom it is addressed. They are confidential and may be privileged
information. If you are neither the intended recipient nor the agent
responsible for delivering the message to the intended recipient you are
hereby notified that any dissemination of this communication is strictly
prohibited and may be unlawful.
If you feel you have received this communication in error please notify
us immediately by returning this email to the sender and deleting it out
of your email.
Thank You.
James Moore & Co P.L.
**********************************************************************
|
