cgg@topexpress.co.UK (Gray Girling) (06/30/89)
This is something of a delayed response to something Steve Kille said in the X-Windows on ACSE or Transport layer discussion: > Another reason for mapping onto ACSE is that it will give natural hooks for > authentication and encryption services, which you would not get from a > mapping onto transport. Is this how people see the ISO 7498-2 security services being incorporated into the upper layers? Two issues come to mind: 1) the choice of architectural places where security services could be obtained: They *could* be provided from an ACSE, or they could be provided by one or more separate "security" ASEs, or they could be available, somehow, directly from the Presentation layer [the use of encipherment is sometimes seen as something to do with the choice of transfer syntax] 2) the place of the encipherment mechanism: "encryption" is not (according to ISO 7498-2) a security service, it is only a mechanism that can be used to provide (one of a number) of them. Should the Presentation layer provide a real encipherment service for the Application layer to use, or should it reside as a mechanism in the Application layer? If the latter, given that communicating Application entities do not necessarily share the same syntax, how does this encipherment work? Has anyone any ideas? These questions are currently being addressed in the evolving upper layers security model - but are unresolved at the moment. Gray Girling ------------------------------------------------------------------------------- Gray Girling Telephone : (+44) 223 462121 Topexpress Ltd Telex : 817911 Topexp G Poseidon House, Castle Park Fax : (+44) 223 315057 Cambridge, CB3 0RD, UK E-Mail : cgg@uk.co.topexp -------------------------------------------------------------------------------
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (07/03/89)
Encryption should indeed be provided with the presentation service, as the data to encrypt will have to be encoded in ASN1-BER or something equivalent before encryption. However, the semantics of the P-protocols dont make the provision of encryption ``as an alternative transfer syntax'' very easy: * there is no place to convey a key negociation, you can only refer to syntaxes by their OID, * it should be negociated separately for each presentation context, * and it is hard to perform the P Protocol in hardware. I have the feeling that encryption would be better dealt with at the transport or network layer. For example, one could place a key negociation within the Transport connection negociation. Christian Huitema
cgg@topexpress.co.UK (Gray Girling) (07/05/89)
The transport and network layer are good places to support encipherment, but if you want the added efficiency of selective field based security or if you require non-repudiation (using digital signatures) 7498-2 says you must use the upper layers to provide it. So some way to deal with encipherment in the upper layers will eventually be standardized. The version of 7498-2 I have implies that selective field confidentiality could be provided in the Application layer. Given the logical difference between the syntax used in two AEIs, encipherment (as usually understood) would not seem to be an applicable mechanism. So how could you do it?
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (07/06/89)
You should distinguish between encipherment, which is basically a transmission function aiming at a particular quality of service, i.e. confidentiality, and signatures, which are clearly dependent of end users interaction, thus located in the application layer. In principle, the same application could run either in encrypted or plain mode without much consequences. After all, confidentiality of the transmission could be provided by many other means, e.g. miliotary guarded shielded cables; usage of end to end encryption appears to me very much the same as using end to end checksum, i.e. a particular transport function that is applied when one does not trust the network. The tricky point of the application layer signature or encryption mechanisms is that they should be based on the ``abstract syntax'' of the data. There is one approach in X.500. Christian Huitema