I agree that storage is out of scope for the IETF related work that we're discussing but it's not at all irrelevant to the overall problem of delivering security services for defense of the log information tailored to specific application and user-network needs. The legal evidence issue is clearly part of the user's problem. But let's agree that we are talking (now) about protocol features as seen on the wire. One of the reasons I'm enthusiastic about the XML encoding approach is that it offers almost unlimited flexibility in developing further tags and wrappers for such requirements. If XML encoding is (optionally) retained in the stored data it might be possible to provide "cradle-to-grave" defense of log streams a la Schneier & Kelsey -- if supported by both client or forwarder(s) and final loghost. None of this has to be in the iniitial specs; it can all be added if and as necessary,. Also, XML encoding offers a lot of flexibility in demarcation of security regions within an event stream. It might be useful, for example, to consider a log "session" (e.g. a TCP connection) as an XML "document" with its originator's authentication credentials implemented as tags presented at its head. The parser at the loghost, like any SGML parser, need not keep the connection open any longer on discovering that the "document"'s credentials are bogus. Or alternatively, for a UDP system, each record might bear some credentials such as an authentication MAC, as another type of authentication tag. The burden of complex structured encoding is substantial, of course, but there might be enough payoff in specific applications to make it worthwhile. It's up to the designers of the access server or firewall, the loghost/forwarder, and the final network application to decide. What we have to decide now, is the (hopefully small) number of scenarios that need to be supported in a basic core protocol. Alex "Chris M. Lonvick" wrote: > Hi, > > At 08:26 PM 11/24/99 +1100, Darren Reed wrote: > >In some email I received from Chris Calabrese, sie wrote: > >> > >> > >> Let's see... > >> > >> Orange Book requires that the TCB shut down if it can't log, so that > >> jibes with Chris L's statement about the .gov wanting confirmed delivery. > >> Not all subsystems will have this requirement, however, and it will also > >> be difficult to do over UDP, so we want this to be optional in some way. > >> This probably means an option to openlog(3) and logger(1) to specify that > >> the logs must be verified, and an option in syslog.conf to say that a > >> particular log stream can only go over a verifiable connection. > > > >I think we need to do what we can, at a protocol level, to support whatever > >one needs to do at an application level, in order to facilitate confirmed > >delivery. If we can provide host to host confirmed delivery (and storage?) > >then the applications exchanging messages may be able to provide feedback > >to other programs about the success/failure of their logging. > > I agree with Darren on this. Specifying how the end-system is supposed to > work seems to be going a bit too far. Options can be suggested to > implementors. Claims of adherence to code and/or specifications will not > get a device certified through TCSEC, ITSEC or CC. It must be documented > and tested by a qualified evaluation. If some vendor/implementor really > feels the need to have their product evaluated, then they can state their > claim in their Security Target and have it evaluated. If they don't feel > the urge to go through perdition for a formal evaluation, then they can > just state their claims in their advertising. > > >> The courts are going to want chain-of-custody evidence, so that implies > >> digital signatures to prove where the data came from and that it has not > >> been altered. This is both in transmission and in the log store. > > Which courts of which legal system? (Many judicial systems throughout the > world do not acknowledge the use of digital signatures for validation of > immutability of digital information. At this time, the US (sometimes > thought of as a technically advanced nation) does not have a unified law > on the use of digital signatures.) On the other hand, the majority of the > technical community agrees that digital signatures can prove immutability > and that's a goal that should be addressed in the transmission of the > information. Let's justify the requirements based upon technical needs > and not upon the needs of technically oblivious legal systems. > > Again, we need to address the transmission and leave the storage to the > implementor. If challenged in court, a vendor can state how the logs are > actually handled. Even after unified laws are passed, most courts that I > am aware of will retain the right to interpret vendor claims and pass > judgement upon their admissability in each specific case. > > Thanks, > Chris -- Alex Brown http://www.msg.com/~abrown +1 617 504 8761
