Return to mroe.idea CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / others / X / ideas

Annotation of 43BSDReno/contrib/isode-beta/others/X/ideas/mroe.idea, revision 1.1.1.1

1.1       root        1: (Message inbox:23)
                      2: To: Steve Kille <[email protected]>
                      3: cc: Mike Roe <[email protected]>, Jon Crowcroft <[email protected]>
                      4: Subject: Re: Moron X Window protocol on ISODE TS 
                      5: In-reply-to: Steve Kille's message of Tue, 17 Oct 89 08:15:08 +0100.
                      6:              <[email protected]> 
                      7: Date: Tue, 17 Oct 89 12:41:13 +0100
                      8: From: Mike Roe <[email protected]>
                      9: 
                     10: 
                     11: > Forget transport layer authentication.  If you want to add in authentication,
                     12: > do it where it fits "proerly".    I think that the aim is a simple
                     13: > and reaonabvly efficient mapping of X.  For this, cutting at the 
                     14: > transport layer makes a lot of sense.  But don't try hacking in bells
                     15: > and whistles.   
                     16: 
                     17: Firstly, I agree "X over TS" is an orthogonal issue to authentication, and 
                     18: should be tackled separately.
                     19: 
                     20: However, I'm now going to fall for it and ask "What's wrong with transport
                     21: level authentication?".
                     22: 
                     23: Here, you have a stream of data between a sender and a receiver. (Ok, so the 
                     24: stream consists of X protocol datagrams). All you want to do is convince the
                     25: receiver that everything came from the sender --- there is no need for
                     26: non-repudiation etc.
                     27: 
                     28: Clearly, you want to insert a checksum into the stream every so often, at
                     29: least once per (application) datagram. Note that this ought to be a
                     30: simple hash (eg DES in CBC mode). Sending a full authenticator (Certification
                     31: path + RSA encrypted token) each time is unacceptably wasteful.
                     32: 
                     33: Claim: The end of a TSDU or SSDU is as good a place as any to put the checksum.
                     34: 
                     35: I can see some of the arguments against it :
                     36: 
                     37: 1. (Pragmatic) As I said before, no agreed way to set up the key.
                     38: 
                     39: 2. (Religious) It's the layer 7 entity you want to authenticate, not the T-layer
                     40:    The T-layer should not have to know about application layer information.
                     41: 
                     42: 3. The only time the Rx needs to look at the checksum is at the end of a 
                     43:    datagram, so it should be sent only at the end of a datgram. 
                     44:    From the standpoint of the 7 layer model, only application/presentation can
                     45:    do this.
                     46:    From the standpoint of the actual protocols, session can also do this,
                     47:    as a P-DATA.REQUEST maps directly onto an S-DATA.REQUEST.
                     48: 
                     49: Religious argument for it :
                     50: 
                     51:   The application layer doesn't know about the concrete encoding --- so it
                     52:   can't calculate a checksum.
                     53: 
                     54:   While we're on this, the X.509 "SIGNED" and "ENCRYPTED" macros are somewhat
                     55:   broken : They prevent you from negotiating a different transfer syntax!
                     56: 
                     57: THESIS: Only the lower layers know which encoding to sign.
                     58: ANTITHESIS: Only application layer knows which key to use.
                     59: SYNTHESIS: Sometimes the seven layer model creates imaginary problems.
                     60: 
                     61: Mike

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.