[comp.protocols.iso.dev-environ] The innards of the FTAM implementation

clissman@ccvax.ucd.ie (02/09/91)

I am trying to modify the FTAM implementation included in ISODE 6.0, but
am having difficulty tying down the data structures involved. 
Can anyonne tell me
1: which procedures are used by the ftam functions to gain access to the 
presentation layer, ie how do FDataRequest, FReadWriteRequest and so on get
their data from level 6 ? It seems they may use PDataRequest, can someone 
confirm this ? 
2: What kind of a data strcture is used to move user file contents from
level 7 to level 6 and vice versa. And where are these data structures
defined. (It seems a PE structure may be used, but I'm having problems
finding a definition for PE in the .h files.)

I want to get at this data and encrypt it before it arrives in level 6, and
then 
decrypt it as it goes from level 6 to level 7. Has anyone got clever ideas
on this one ? 
My gratitude for any help received,

Thanks

Ciaran

Ciaran Clissmann
Dept Comp Sci
Univ. Coll. Dublin Ireland

brett@solar.card.inpu.oz.au (Brett Sealey) (02/11/91)

clissman@ccvax.ucd.ie writes:

>I want to get at this data and encrypt it before it arrives in level 6, and
>then 
>decrypt it as it goes from level 6 to level 7. Has anyone got clever ideas
>on this one ? 
>My gratitude for any help received,

I would have thought that level 6, being the Presentation Layer, would
be a logical place _within_ which do perform encryption & decryption?

Sorry I can't really help you much but I wonder what other people feel
about what is the appropriate point at which to apply encryption/decryption
and even compression/decompression.
______________________________________________________________________________
  __   __   ___ ____ ____
 /__) /__) /_    /    /				brett@solar.card.inpu.oz.au
/__) / \  /__   /    /					       Brett Sealey
______________________________________________________________________________

tebbutt@RHINO.NCSL.NIST.GOV (John Tebbutt) (02/12/91)

>I would have thought that level 6, being the Presentation Layer, would
>be a logical place _within_ which do perform encryption & decryption?

Depends on the kind of en/decryption you want. If you wanted to do it
within the Presentation layer, you would need to internationally
standardize just how you were going to do it in order to be able to
interoperate with other systems which may or may not know how to handle
your encryption: there would have to be something in the Presentaion
PDU to indicate to the receiving Presentation entity whether the user
data had been scrambled wholesale, and by what means. Without this, a
non-encrypting Presentation implementation would take the scrambled
user data, pass it up to layer 7 unaltered, and the application would
be saddled with a PDU it could not process.
 
In practice, organizations do not want nor need to encrypt the OSI
protocol structure itself, but merely the data they are using the
protocols to transmit.  In the case of Ciaran's FTAM, it would seem
more sensible to encrypt the application user data in the application
layer, then all protocol control info remains intact and the worst that
can happen is that the FTAM implementation at the receiving end
produces a file which looks like garbage because it didn't know the
file data was encrypted.
 
Having said all this, I'm no security expert ! I would be eager to hear any
better ideas !

        JT

PS What's a munnari ?

galvin@TIS.COM (James M Galvin) (02/15/91)

	In practice, organizations do not want nor need to encrypt the OSI
	protocol structure itself, but merely the data they are using the
	protocols to transmit.  In the case of Ciaran's FTAM, it would seem
	more sensible to encrypt the application user data in the
	application layer, then all protocol control info remains intact and
	the worst that can happen is that the FTAM implementation at the
	receiving end produces a file which looks like garbage because it
	didn't know the file data was encrypted.

This model of the placement of security services is valid, but your message
suggests it is the preferred placement.  In fact, the placement of security
services is entirely dependent on the perceived threats.  For example, if
traffic analysis is a threat, this placement is not appropriate.

I am not sure this is an appropriate discussion for this list, but I would
be happy to discuss this further privately.

Jim

yee@AMES.ARC.NASA.GOV (02/19/91)

Check ISO 7498 Part 2 for ideas on where ISO thinks it is appropriate to
provide certain security functions.  Currently there is work being done on
encryption at layers 3 and 4 (SDNS) and layer 2 (SILS).  I'm sure there
are other places where you can do it and other work being done for those
layers.

							-Peter Yee
							yee@ames.arc.nasa.gov
							ames!yee

nick@stca77.stc.oz (Nick Lochrin) (03/04/91)

In article <1991Feb11.113524.222@solar.card.inpu.oz.au> brett@solar.card.inpu.oz.au (Brett Sealey) writes:
>clissman@ccvax.ucd.ie writes:
>
>>I want to get at this data and encrypt it before it arrives in level 6, and
>>then 
>>decrypt it as it goes from level 6 to level 7. Has anyone got clever ideas
>>on this one ? 
>>My gratitude for any help received,
>
>I would have thought that level 6, being the Presentation Layer, would
>be a logical place _within_ which do perform encryption & decryption?

I would agree that layer 6 is a reasonable place for this. I think this fits
into the concept of a presentation context,

where:
	presentation context = abstract syntax + transfer syntax

X.208 describes ASN.1 (abstract syntax notation number one) and
X.209 describes BER (basic encoding rules) transfer syntax.

also of use here is the concept of a Defined Context Set (DCS) which refers
to the set of currently active presentation contexts. Before any information
exchange can occur, both end systems must reach an agreement on which abstract
syntaxes are to be used. This happens via the P-CONNECT request primitive.

I think you could define a new transfer syntax which say used an encrpted
version of BER. IMHO this could also be applied to compression/decompression
of application data.
-- 
Nick Lochrin                 nick@stca77.stc.oz
Alcatel STC Australia        ...!uunet!stca77.stc.oz!nick
252-280 Botany Road,         nick%stca77.stc.oz@uunet.UU.NET
ALEXANDRIA  NSW  2015        "Are you the police ?.. No ma'am, we're musicians."