[Css-dts] SLE Transfer Service Security Specification W-0.02

[John Pietras]

Dear colleagues,
Attached is the draft SLE Transfer Service Security Specification W-0.02
(change "piz" to "zip" to decompress). This draft incorporates changes
resulting from Wolfgang Hell's review of the previous version. I believe
that the draft addresses all of Wolfgang's issues except one, which is
described in greater detail in the following paragraphs.

Annex C describes the use of security-related managed information to
authenticate and control access to SLE transfer services. Wolfgang has
pointed out that the mechanism does not exactly match that used by the
ESA implementation. I've discussed this to some extent with Wolfgang and
also with Michael Stoloff, in hopes of arriving at a description that is
mutually acceptable. I thought that I had a solution, but when I went
over my notes recently, I realized that I still don't understand all of
the aspects of the ESA approach enough to be sure of the approach. 

Also, I am beginning to suspect that there may be an incompatibility
between the current ESA approach, which I think may be tightly coupled
to a single authentication method, and the more general approach that
supports multiple authentication methods that I was envisioning in
writing Annex C. Should Annex C attempt to standardize what is, or
should it attempt to define what should be? Please understand that I
don't believe that what I've currently written in Annex C is necessarily
"what should be", but I was attempting to describe a mechanism that
would satisfy the goal of supporting multiple authentication methods. 

Note that if it is decided to document the current mechanisms, there are
differences between what ESA and JPL currently do in this area. Because
the processes on both ends are currently manual and because the current
implementations use only one authentication method, these differences
are smoothed over and the implementations are able to interoperate. But
an attempt to formally describe "the" process (which is essentially what
Annex C attempts to do) exposes the differences.

Finally, please note that these same problems exist in Annex F of the
Cross Support Concept Green Book, which served as the basis of the Annex
C of the attached.

Unfortunately, my funding for working on this document has reached its
end, so I will have to let someone else grapple with these issues. 

Best wishes for a healthy and happy new year,

John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: SLE TS Security W0.02.piz
Type: application/octet-stream
Size: 1104399 bytes
Desc: SLE TS Security W0.02.piz
Url : http://mailman.ccsds.org/pipermail/css-dts/attachments/20041228/72a3eee9/SLETSSecurityW0.02-0001.obj