This digest for list has been created on Sat Nov 1 02:38:19 3897 ------- THIS IS A RFC934 COMPILANT DIGEST, YOU CAN BURST IT ------- Date: Fri, 31 Oct 1997 17:33:02 -0800 (PST) From: Erik Guttman Reply-To: Erik Guttman Subject: test To: gulp@hsc.fr Message-Id: Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: uIuG5GxeNbQHDpYWN3FmaQ== X-Mailer: dtmail 1.1.0 CDE Version 1.1_59 SunOS 5.5.1 sun4m sparc X-Sequence: 7 Precedence: list test test ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- Date: Mon, 3 Nov 1997 13:55:44 -0800 (PST) From: Erik Guttman Reply-To: Erik Guttman Subject: Universal Logging Protocol (ULP) BOF To: ietf@ietf.org Cc: gulp@hsc.fr, eguttman@Eng.Sun.COM Message-Id: Mime-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-Md5: AhRTfXgUsZgV5JZM55B2xg== X-Mailer: dtmail 1.1.0 CDE Version 1.1_59 SunOS 5.5.1 sun4m sparc X-Sequence: 8 Precedence: list I would like to announce a BOF we'll be holding in Washington, DC. ULP BOF Description: Network based logging services provide system administrators with an important tool for diagnosing a variety of problems. There is no standard way to do logging. We propose a single very simple protocol which will allow interoperable logging for the Internet. This protocol will include features for structuring log entries with fields which have standard definitions. We would like to define a standard API, string based protocol and message format for log entries. We also will address internationalization of logs, how to transmit log entries securely. Another important topic is how a logging protocol should interact with network management. We have started an archived mailing list. The archive is at http://www.hsc.fr/gulp or retrievable via email by sending "index gulp" in the body of email to sympa@hsc.fr. To subscribe, please send "sub gulp" to the same address. Erik Guttman Sun Microsystems ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- Date: Tue, 18 Nov 1997 12:00:10 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: ULP and its goals To: gulp@hsc.fr Cc: eguttman@Eng.Sun.COM Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sequence: 9 Precedence: list I wanted to start a discussion on what ULP will attempt to achieve. If we don't focus on a simple set of objectives I think we run the risk of getting embroiled in attempting to get right what past efforts to standardize logging have gotten wrong. The goal of ULM would be simply to provide a simple tagged (if verbose) format for logging system events, whether they be for debugging, administrative record keeping or security audit trails. The tagging does not have to be comprehensive: It needs to include standard tags and be extensible to new tags, either for private use or for the community. The very fact that this tagging exists will make analysis of logs vastly easier and more effective. The ULP protocol does *not* need to be 'secure' - but it does need to have some security properties which are well defined. This may make it unsuitable for certain security auditing tasks. In short, ULP has rather modest goals. The question is are these goals something which will get people excited enough to use it? Will we encounter the same problems which efforts in the past have (OSI, Posix, others I have heard of) where it is difficult to come to a concensus about what the standard set of tags should be? Erik Guttman ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- From: schaefer@cert.dfn.de Message-Id: <199711181531.QAA24420@concert.cert.dfn.de> Subject: Questions and suggestions... To: gulp@hsc.fr Date: Tue, 18 Nov 1997 16:31:41 +0100 (MET) Cc: schaefer@cert.dfn.de (Leslie Schaefer) Content-Type: text X-Sequence: 10 Precedence: list Firstly, as most lists observe this etiquette, an introduction to my person: I'm a mature student of computer science, who unfortunately receives no money of any kind and must thus work to pay for his education. For the last few years I worked night shift at the local central post office (NASTY) until I was offered this job (NICE). This is my second degree, the first one was a BSc in wood science so I'm so old that no-one will probably give me a job afterwards, so I enjoy the degree with no career stress. Secondly: A) Are there back-issues of mails from the ULP mailing list? If so, where do I find them? B) Is there a list of mailing list members? C) I was bounced me one of Eriks mails: my notes are at home, but here's a summary off of the top of my head: I'm writing a project titled (at the min.) "An Introduction to Computer System Monitoring", which includes a chapter on a possible "Universal Monitoring Protocol". The difference to logging (as far as I'm concerned) is reliability: I've tried to partition messages into two groups- 1. those generated with participation of the applications concerned (eg. syslog); 2. those generated by the OS "kernel". I've identified a number of problems I want to solve with it, whereby security and monitoring go hand-in-hand. My goals include: 1. a binary message format, which is allows for string fields to be included (binary format for faster processing). Strings are also far too easy to "corrupt": one can imagine that some manufacturers could feel that for their os a similar string (read "different") expresses some concept to "their" users much better and they change it - no longer standard. Imagine the system using a (fictitious) message CHANGE_OWNER OLD_UID NEW_UID STRING_LENGTH STRING_QUALIFYER and some manufacturer (hence the NS) saying, "but we don't have uids like that on our os, we'll use" NS_CHANGE_OWNER OLD_ACCOUNT_NR NEW_ACCOUNT_NR STRING_LENGTH STRING_QUALIFYER Now the whole idea of "universal" has evaporated. Not olny that, but the length and variety of messages starts to look just like existing "standards". An integer (a binary bit pattern to be more honest) stays a binary bit pattern. If a manufacturer started playing around with them he'd be saying "nice one boys, but we've decided to intentionally scr** you over, we'll introduce the same system, just with different numbers". In the end he'd be much more likely to end up with egg on his face as with strings. Using bit fields also means less net traffic. If the length of the message primary key is large enough (say 64 bits) then there's enough room to allocate sectors to specific manufacturers, so that they will not feel the need to redefine standard (monitoring protocol defined) keys. 2. The system can be implimented as a user-level process or as part of the kernel (either hard coded or as a linkable module) : the message format will have a bit set (or not) to indicate on which level each message was generated (and thus indicate its reliability). It's just too easy to generate a lot of syslog junk actively and bung a system up. 3. The message system will have a timer, which can be set in order to send messages at maximal time intervals (eg. every 10 ms) in order to see if someone takes a machine off line (eg. new boot to compromise the monitoring system) for even the shortest of time periods. An empty message unit just says that a specific system has had no activity during the specific time segment. It's also possible (just as an eg.) for machines taken from the net to recognize this: introduces the possibility of a machine shutting down in response. 4. Each message unit has a time sent field within its own data area, this with point 6 should help stop replays. 5. Each message unit has a sequence number within its own data area, this with point 6 should help stop replays. 6. Each machine within the system encrypts the message units using an asymmetric encryption system, which firstly prevents any sniffing on the line (which would give away far too much information) and secondly with 4. and 5. should go a long way to preventing anyone generating false info. (Ignoring the case of a program being able to maliciously generate info. => bit for user/kernel generated info.) If all the message units are sent to a single (specialized) monitoring machine (or machines: part of my project) then the system can automatically tunnel the messages over public networks without too much danger. (Leaving out traffic analysis of course 8^) .) 7. The system can have the possibility to boot with the machine specific encryption key being dynamically loaded onto it. Eg. the system admin in a company takes a key on a diskette. An extention to this is that a machine cannot boot without a key. This opens the door for denial of service attacks, but I'm a long way from seriously working on the chapter at the minute. Other "secure" transmission media also possible eg. using asymmetric cryptography. 8. Leave room in the concept to integrate a network management system. Some questions, sorry if they have already been covered previously: Eriks mail said- >The ULP protocol does *not* need to be 'secure' - but it does >need to have some security properties which are well defined. >This may make it unsuitable for certain security auditing tasks. Why develop another logging system which duplicates existing ones to a large extent? If the object is to standardize message formats, then go for a revitalization of syslog. If one wants to really see what is going on on a machine (over a net?) then the security side is just as important as the message format side. =>Develop a new multi-featured, specialized system, which is platform independent of any os. >The very fact that this tagging exists will make >analysis of logs vastly easier and more effective. Easyer and more effective, but what about the integrity of the messages, I don't want to sound sarcastic, but "Sure John, we can analyze the thousands of messages at over three ducks a zork. Of course, we don't know if the three toasters found actually mean anything!" Comments welcome, even if the goals of the ULP are different to mine, it'd be nice for someone to pull my ideas apart and show me the way... Regards, Les ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Les E. Schaefer: Mature student of computer science: University of Hamburg, Germany E-Mail: 2schaefe@informatik.uni-hamburg.de & schaefer@informatik.uni-hamburg.de Works as well... DFN-CERT, Department of Computer Science, University of Hamburg E-Mail: schaefer@cert.dfn.de ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Disclaimer: All opinions expressed are personal. I neither speak on behalf of my employer or institute of education, nor should anything I express be taken as an indication of their views or policies on either the subject being discussed or on any other related subjects. Should I wish to convey their policies, this will be expressly stated. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- From: Adam Shostack Message-Id: <199711181552.KAA15318@homeport.org> Subject: Re: Questions and suggestions... In-Reply-To: <199711181531.QAA24420@concert.cert.dfn.de> from "schaefer@cert.dfn.de" at "Nov 18, 97 04:31:41 pm" To: schaefer@cert.dfn.de Date: Tue, 18 Nov 1997 10:52:52 -0500 (EST) Cc: gulp@hsc.fr X-Mailer: ELM [version 2.4ME+ PL27 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Sequence: 11 Precedence: list schaefer@cert.dfn.de wrote: | I'm writing a project titled (at the min.) "An Introduction to | Computer System Monitoring", which includes a chapter on a | possible "Universal Monitoring Protocol". The difference to | logging (as far as I'm concerned) is reliability: I've tried | to partition messages into two groups- | I've identified a number of problems I want to solve with | it, whereby security and monitoring go hand-in-hand. My | goals include: | | 1. a binary message format, which is allows for string | fields to be included (binary format for faster | processing). Strings are also far too easy to | "corrupt": one can imagine that some manufacturers Text is easier to parse in many scripting languages that are useful for writing log monitors (perl, tk, python). Having a binary format requires custom tools and libraries, which is not a move towords universiality. | 3. The message system will have a timer, which can be set | in order to send messages at maximal time intervals | (eg. every 10 ms) in order to see if someone takes a | machine off line (eg. new boot to compromise the monitoring This is a monitoring function, not a logging function. What if the logging daemon breaks? If the machine becomes hevily loaded? | 4. Each message unit has a time sent field within its own | 5. Each message unit has a sequence number within its own | 6. Each machine within the system encrypts the message | units using an asymmetric encryption system, which | firstly prevents any sniffing on the line (which Performance? | >The ULP protocol does *not* need to be 'secure' - but it does | >need to have some security properties which are well defined. | >This may make it unsuitable for certain security auditing tasks. | | Why develop another logging system which duplicates existing | ones to a large extent? If the object is to standardize message | formats, then go for a revitalization of syslog. If one wants to | really see what is going on on a machine (over a net?) then the | security side is just as important as the message format side. | =>Develop a new multi-featured, specialized system, which is | platform independent of any os. Because syslog is not a standard. Because syslog uses udp. Because syslog throws away information intentionally. Because syslog is not designed for reliability. Redoing the transport underneath a syslog like system would offer us minimal work for maximum gain. | >The very fact that this tagging exists will make | >analysis of logs vastly easier and more effective. | | Easyer and more effective, but what about the integrity | of the messages, I don't want to sound sarcastic, but | "Sure John, we can analyze the thousands of messages | at over three ducks a zork. Of course, we don't know if | the three toasters found actually mean anything!" Use an hmac to ensure the message came from one side of the conversation or the other. Reasonably fast, very secure, except against key theft attacks. Patent free. IETF standardized already. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- Date: Tue, 18 Nov 1997 20:28:29 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: security in ULP To: gulp@hsc.fr Cc: Chris Newman Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sequence: 12 Precedence: list Chris Newman wrote: >> The goal of ULM would be simply to provide a simple tagged >> (if verbose) format for logging system events, whether they be >> for debugging, administrative record keeping or security audit trails. >> The tagging does not have to be comprehensive: It needs to include >> standard tags and be extensible to new tags, either for private use >> or for the community. The very fact that this tagging exists will make >> analysis of logs vastly easier and more effective. > >So the goal is a simple attribute value protocol. I think the key to >keeping this simple is to avoid the issue of efficient access to stored >log data and focus primarily on sending data to the server. If any >access facility is provided it should be limited to a complete download >only (otherwise you'd be re-inventing most of ACAP). An idea occurs to me: A set of ULM entries could be structured in such a way that it could be searched and accessed using ACAP. What we are after with ULP is really only the ability to upload log entries efficiently. There are features of the NT event logger which are attractive, which allow logs to be accessed (on an entry by entry basis) or even deleted. It is really worth pursuing using ACAP for doing this as you say. >> The ULP protocol does *not* need to be 'secure' - but it does >> need to have some security properties which are well defined. >> This may make it unsuitable for certain security auditing tasks. > >I disagree. If it crosses a network it needs security of some flavor. If >we use TCP, I suggest we use SASL (RFC 2222) for security which provides a >nice simple standards track framework. I don't mean we don't need security, rather that we need to be really careful what we say when we say "secure logging protocol." There are *some* security requirements on system audit trail log entries which would be extremely hard to provide (guaranteed deliver, for example.) I agree SASL is attractive for this application, but I recall that Jerome disagrees. Jerome? Erik ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- Date: Tue, 18 Nov 1997 20:42:15 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Questions and suggestions... To: gulp@hsc.fr Cc: schaefer@cert.dfn.de In-Reply-To: "Your message with ID" <199711181531.QAA24420@concert.cert.dfn.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sequence: 13 Precedence: list You can get at the mail archives off the main site for the project: http://www.hsc.fr/gulp Please read the internet draft on a proposed tagged universal log message format. I think you'll find it interesting. There is a link off the web page. I don't mean to say ULP won't have *any* security, just that it won't be *fully secure*, which is of course an impossibility. Message integrity, bidirectional authentication: These are really important. Is encryption? Is nonrepudiation? Is guaranteed delivery? Should there be integrity checks that can be applied to the log entries long after they have been archived to ensure they have not been tampered with? And there are of course a host of other features we could dream up! Erik ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- Message-Id: <19971119145845.33529@coredump.hsc.fr> Date: Wed, 19 Nov 1997 14:58:45 +0100 From: Jerome Abela To: gulp@hsc.fr Subject: Re: security in ULP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Erik Guttman on Tue, Nov 18, 1997 at 08:28:29PM +0100 X-Sequence: 14 Precedence: list Erik Guttman Wrote: > An idea occurs to me: A set of ULM entries could be structured in such > a way that it could be searched and accessed using ACAP. I like this idea. > >I disagree. If it crosses a network it needs security of some flavor. If > >we use TCP, I suggest we use SASL (RFC 2222) for security which provides a > >nice simple standards track framework. > > I agree SASL is attractive for this application, but I recall that > Jerome disagrees. Jerome? I also believe ULP should provide basic security, and basic security includes mutual strong authentication. I think we all agree on this even if the strong authentication we choose is not to be unbreakable. However, if ULM could fit in ACAP for logging as well as for searching/accessing, SASL is of course the authentication protocol to be used (authentication, integrity, confidentiality). Is there a simple way to make ULM fit into ACAP ? If so, ULP should just define how ACAP is used to log/search/access aginst an ULP server... Jerome. ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- Date: Thu, 20 Nov 1997 11:32:49 -0800 (PST) From: Chris Newman Subject: Re: security in ULP In-Reply-To: <19971119145845.33529@coredump.hsc.fr> To: Jerome Abela Cc: gulp@hsc.fr Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=thor.innosoft.com X-Sequence: 15 Precedence: list On Wed, 19 Nov 1997, Jerome Abela wrote: > I also believe ULP should provide basic security, and basic security > includes mutual strong authentication. I think we all agree on this > even if the strong authentication we choose is not to be unbreakable. Just say SASL for now and we can pick a mandatory to implement authentication mechanism underneath SASL at a later date. That's the simplist way to do connection security without re-inventing the wheel. > Is there a simple way to make ULM fit into ACAP ? Sure. ACAP is an extensible attribute-value protocol, so it's fairly easy. The only tricky part is that each entry in an ACAP dataset has to have a single unique entry identifier. > If so, ULP should just define how ACAP is used to log/search/access > aginst an ULP server... I'd say a good way to proceed is define a really simple ULP, perhaps with 4 commands: AUTH -- using SASL LOG -- record a ULM line FLUSH -- make sure all LOGs are written to disk (for reliability) QUIT -- does implicit FLUSH Then define a simple mapping for accessing logs via ACAP. I'm big on separation of function, so while most of ACAP's facilities are needed for efficient remote access to a log, it shouldn't be needed to create the log. - Chris ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- X-Authentication-Warning: kruuna.Helsinki.FI: ssyreeni owned process doing -bs Date: Mon, 24 Nov 1997 17:04:08 +0200 (EET) From: Sampo A Syreeni Sender: ssyreeni@cc.helsinki.fi Reply-To: decoy@iki.fi To: Erik Guttman Cc: gulp@hsc.fr, schaefer@cert.dfn.de Subject: Re: Questions and suggestions... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sequence: 16 Precedence: list On Tue, 18 Nov 1997, Erik Guttman wrote: >Message integrity, bidirectional authentication: These are >really important. Is encryption? Is nonrepudiation? Is >guaranteed delivery? Should there be integrity checks that >can be applied to the log entries long after they have been >archived to ensure they have not been tampered with? Somehow that seems like an overkill. Building features of that kind into every single protocol (which is what seems to be happening) seriously violates the basic principle of keeping things simple and modular. For the time being, such mechanisms aren't, to my opinion, really necessary. They could be useful, but can largely be provided by standard means (IPSEC, for example, once it gets here). Of course, all the machinery isn't here yet, but one possibly has to use the protocol for a long time after. And you _can_ do without those features now... Especially since it takes some time to finish the protocol anyway - what's the use of incorporating the full suite of cryptographic add-ons if all it amounts to is making the spec late and bloated? >And there are of course a host of other features we could >dream up! And, alas, somebody would have to implement. Protocol bloat, is that a word?` Sampo Syreeni , Decoy/Dawn, Student (Math, Helsinki University) ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- Date: Tue, 25 Nov 1997 12:21:18 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Questions and suggestions... To: decoy@iki.fi Cc: Erik Guttman , gulp@hsc.fr In-Reply-To: "Your message with ID" Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sequence: 17 Precedence: list Sampo, I agree we should attempt to use existing mechanisms rather than inventing our own. What is most important to discuss is what properties we might need. This will guide our choice of mechanisms (ie. is HMAC enough, or do we need TLS, etc.) The properties that seem really important for logging in general are: - integrity - bidirectional authentication This way a host A can transmit a log entry to host B and be reasonably sure that it got there. B can obtain a log entry from A and be reasonably sure that it wasn't forged, altered, etc. Now, if we want ULP to do more than this, in other words, that it be able to meet some of the requirements for security audit trails, perhaps we have more requirements: - Encryption (the audit trail entries might be sensitive information, especially as they would divulge to an attacker that she has been caught, etc.) - Nonrepudiation (this might aid in making the audit entry stronger evidence in case of a prosecution.) There is another feature that we might consider for ULP: - Guaranteed delivery (The host A which wishes to log with B would have to implement some form of message queuing and only erase the log records after a successful transfer of the log entry had been achieved with B.) To achieve this transaction, TIP (transaction internet protocol) could be used. To obtain the security properties, IPSec, SASL or some other mechanism could be used. The important thing to concentrate on now is not mechanism, but architecture. It is quite possible there will be no ULP, but just a statement that ULM based records are transmitted using the following techniques (fill in the blank with a 'Core Security Mechanism', as per draft-iab-secwks-report-00.txt), etc. Erik > On Tue, 18 Nov 1997, Erik Guttman wrote: > > >Message integrity, bidirectional authentication: These are > >really important. Is encryption? Is nonrepudiation? Is > >guaranteed delivery? Should there be integrity checks that > >can be applied to the log entries long after they have been > >archived to ensure they have not been tampered with? > > Somehow that seems like an overkill. Building features of that kind into > every single protocol (which is what seems to be happening) seriously > violates the basic principle of keeping things simple and modular. For the > time being, such mechanisms aren't, to my opinion, really necessary. They > could be useful, but can largely be provided by standard means (IPSEC, for > example, once it gets here). Of course, all the machinery isn't here yet, > but one possibly has to use the protocol for a long time after. And you > _can_ do without those features now... Especially since it takes some time > to finish the protocol anyway - what's the use of incorporating the full > suite of cryptographic add-ons if all it amounts to is making the spec late > and bloated? > > >And there are of course a host of other features we could > >dream up! > > And, alas, somebody would have to implement. Protocol bloat, is that a > word?` > > Sampo Syreeni , Decoy/Dawn, Student (Math, Helsinki University) > ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- X-Authentication-Warning: kruuna.Helsinki.FI: ssyreeni owned process doing -bs Date: Wed, 26 Nov 1997 15:17:33 +0200 (EET) From: Sampo A Syreeni Sender: ssyreeni@cc.helsinki.fi Reply-To: decoy@iki.fi To: Erik Guttman Cc: gulp@hsc.fr Subject: Re: Questions and suggestions... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sequence: 18 Precedence: list On Tue, 25 Nov 1997, Erik Guttman wrote: > - Encryption (the audit trail entries might be sensitive information, > especially as they would divulge to an attacker that she has been > caught, etc.) IMO, encryption is necessary only because otherwise logging could breach the anonymity of legitimate users, which shouldn't be the case, generally. > - Nonrepudiation (this might aid in making the audit entry stronger > evidence in case of a prosecution.) This one's a bit odd. Why would log entries be held against the one who made them in the first place? A scenario? >To achieve this transaction, TIP (transaction internet protocol) could >be used. To obtain the security properties, IPSec, SASL or some other >mechanism could be used. The important thing to concentrate on now is >not mechanism, but architecture. That's what I'm saying. What I'm saying is, let's not get hasty and bloat the protocol itself if alternatives exist. Sampo Syreeni , Decoy/Dawn, Student (Math, Helsinki University) ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- Date: Wed, 26 Nov 1997 14:58:55 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Questions and suggestions... To: decoy@iki.fi Cc: Erik Guttman , gulp@hsc.fr In-Reply-To: "Your message with ID" Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Sequence: 19 Precedence: list > > - Nonrepudiation (this might aid in making the audit entry stronger > > evidence in case of a prosecution.) > > This one's a bit odd. Why would log entries be held against the one who made > them in the first place? A scenario? > If I am logging activity on a set of systems and there is a security violation I would imagine that I could supply the log records as legal evidence. If the log entries could not be forged it would be clear that they were indeed generated by the system and not later entered into the log record. This would increase the value of the evidence. I am not implying the log entries would be held against the administrator doing the logging. Rather, the log entries would be 'strong evidence' as opposed to an easily manipulated text file. What I am really talking about here is the use of digital signatures - it is not so important that we can say 'that logging host really did log this message' as 'no one could have forged this message, it could only have been from this logging host.' I'm not saying this is an important feature - just one to bat around a little bit. > Sampo Syreeni , Decoy/Dawn, Student (Math, Helsinki University) > Erik ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- X-Authentication-Warning: kruuna.Helsinki.FI: ssyreeni owned process doing -bs Date: Thu, 27 Nov 1997 17:01:27 +0200 (EET) From: Sampo A Syreeni Sender: ssyreeni@cc.helsinki.fi Reply-To: decoy@iki.fi To: Erik Guttman Cc: gulp@hsc.fr Subject: Re: Questions and suggestions... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Sequence: 20 Precedence: list On Wed, 26 Nov 1997, Erik Guttman wrote: >If I am logging activity on a set of systems and there is a security violation >I would imagine that I could supply the log records as legal evidence. > >If the log entries could not be forged it would be clear that they were >indeed generated by the system and not later entered into the log record. Is this not authentication? I've always taken nonrepudiation to mean something that makes it impossible to deny you have done something. For example, deny, that some log entry indeed was made. >What I am really talking about here is the use of digital signatures - >it is not so important that we can say 'that logging host really did log >this message' as 'no one could have forged this message, it could only >have been from this logging host.' So authentication, not nonrepudiation... >I'm not saying this is an important feature - just one to bat around a little >bit. I agree. We indeed need authentication to make the system do what it's supposed to do, that is, make it possible to show, beyond doubt, that something has happened... As for nonrepudiation, I do not agree. Sampo Syreeni , Decoy/Dawn, Student (Math, Helsinki University) ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT ------- Message-Id: <19971127173553.18952@coredump.hsc.fr> Date: Thu, 27 Nov 1997 17:35:53 +0100 From: Jerome Abela To: Sampo A Syreeni Cc: gulp@hsc.fr Subject: Re: Questions and suggestions... References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: ; from Sampo A Syreeni on Thu, Nov 27, 1997 at 05:01:27PM +0200 X-Sequence: 21 Precedence: list > >If the log entries could not be forged it would be clear that they were > >indeed generated by the system and not later entered into the log record. > > Is this not authentication? I've always taken nonrepudiation to mean > something that makes it impossible to deny you have done something. For > example, deny, that some log entry indeed was made. Both imply the log record really come from where they say they come from. Authentification implies that, from the server point of view, the log records don't come from an other system. Nonrepudiation implies that, from a human point of view, the log records have not been forged by a malicious hacker on the log server. Nonrepudiation could also imply that, from a law man point of view, the log records found on the server are evidences. Jerome. ------- CUT --- CUT --- CUT --- CUT --- CUT --- CUT --- CUT -------