WE PAY CASH NOW!
WE PAY CASH, NOW! We will pay you a lump sum of cash for Eight years of your Military and Government pensions, or your VA diusability. We pay top dollar! Go to: www.tfund2000.com and click on Military/Government pensions. www.tfund2000.com To be removed, please send a blank email with the word remove in the subject line.
Wouldn't Flexible Investment Terms be nice?
Title: Government Secured WEALTH WITHOUT RISK! Government "Secured" tax certificates PAY YOU between 16%-50%! Receive your free copy of "INSIDER SECRETS OF IVESTING IN SECURED GOVERNMENT TAX CERTIFICATES," just for filling out this form! (A $39.95 Value)YOURS FREE!! DOES THIS SOUND LIKE YOU? Looking For a Crisis Proof Investment? Want For Flexible Investment Terms? Want Something SAFE For a Change? Frustrated Watching The Stock Market? Want an Investment Backed By "Real Property? Would Like a Guaranteed Rate of Return? WE WILL SHOW YOU HOW TO: Remove Yourself From The Crisis World! Receive Flexible Options For Your Money Provide Yourself With SAFE Investment Tools Get Away From The Market Fluctuations Get a Collateralized Investment Opportunity! Get Yourself a Guaranteed Rate of Return! What Can I Make?* The average interest one makes on back taxes is 15%-50% guaranteed by the government, and this is the low end. Our clients are making an incredible 30 to 50 times their money on a high end. The banks have been doing this for over 100 years. Our company has developed a program that allows you to capitalize on these proven techniques and strategies for the first time ever. Please review the chart below to see what our program can do for you when taking advantage of this exciting opportunity! *[The numbers used below are for example only, your individual situations will vary. Affidavits on file] Property # Assessed State Amount Paid Assessed Value PROFIT POTENTIAL #196 Assessed Oklahoma $300.00 $20,000.00 $19,700.00 #206 Assessed Florida $1,957.00 $250,000.00 $248,043.00 #209 Assessed California $65,595.00 $262,349.00 $196,794.00 #211 Assessed New York $7,000.00 $42,500.00 $35,500.00 TOTAL 4 Properties Assessed Single Family $74,012.00 $574,849.00 $500,837.00 Please fill out the following,NO OBLIGATION Form to Receive your FREE Copy of "INSIDER SECRETS OF INVESTING IN SECURED GOVERNMENT TAX CERTIFICATES" (A $39.95 VALUE) All information given herein is strictly confidential and will not be re-distributed for any reason other than for the specific use intended. Required Input Field* Name* Web Address Company Name State * Business Phone* Home Phone Best time to contact: * Morning Afternoon Night Email Address* Type of Business To be removed from our distribution lists, please Click here.
Pay nothing for your conference calls!
Title: Take Control Of Your Conference Calls Crystal Clear Conference CallsOnly 18 Cents Per Minute! (Anytime/Anywhere) No setup fees No contracts or monthly fees Call anytime, from anywhere, to anywhere Connects up to 100 Participants International Dial In 18 cents per minute Simplicity in set up and administration Operator Help available 24/7 Get the best quality, the easiest to use, and lowest rate in the industry. If you like saving money, fill out the form below and one of our consultants will contact you. Required Input Field* Name* Web Address Company Name* State* Business Phone* Home Phone Email Address* Type of Business c 1999-2002 CCFL To be removed from our distribution lists, please Click here..
Would you Like a Guaranteed Rate of Return on your Investment?
** Message from InterScan E-Mail VirusWall NT ** ** No virus found in attached file noname.htm This e-mail has been checked for viruses and found to be clean. * End of message *** Title: Government Secured Government "Secured" Tax Certificates PAY YOU Between 15%-300% GUARANTEED! Receive your FREE copy of "INSIDER SECRETS OF INVESTING IN SECURED GOVERNMENT TAX CERTIFICATES." (A $39.95 Value) WE WILL SHOW YOU HOW TO: Remove Yourself From The Crisis World Receive Flexible Options For Your Money Provide Yourself With SAFE Investment Tools Get Away From The Market Fluctuations Get a Collateralized Investment Opportunity Get Yourself a Guaranteed Rate of Return GUARANTEED INTEREST RATE EXAMPLES: (Business and investment opportunity in all 50 states) Michigan: 15-50% Michigan Compiled Laws...Section 211.73c Georgia: 20-40% Ref. Official Code of Georgia, Section OCGA 48-4-42 Iowa: 24% Ref. Iowa Code Annotated. Sections 447.1 & 447-9 Illinois: 18-48% Illinois Compiled Statutes. Section 35ILCS 200/21-260 Interest rates are set into law, and can only be changed by an act of legislation. What Can I Make? The average interest one makes on back taxes is 15%-50% guaranteed by the government, and this is the low end. Our clients are making an incredible 30 to 50 times their money on a high end. The banks have been doing this for over 100 years. Our company has developed a program that allows you to capitalize on these proven techniques and strategies for the first time ever. Please review the chart below to see what our program can do for you when taking advantage of this exciting opportunity! *(The numbers used below are for example only. Individual situations will vary. Affidavits are on file) Property #AssessedStateInvestmentAssessed ValuePROFIT POTENTIAL #196AssessedOklahoma$300.00$20,000.00$19,700.00 #206AssessedFlorida$1,957.00$250,000.00$248,043.00 #209AssessedCalifornia$65,595.00$262,349.00$196,794.00 #211AssessedNew York$7,000.00$42,500.00$35,500.00 We are dedicated to providing our clients with the most comprehensive education/information on investing in government Tax Certificates, with the highest standards of accuracy, credibility, and integrity. Opportunies are limited and closing fast due to recent economic conditions. Fill out the no obligation form below for a free consultation with one of our advisors. Required Input Field* Name* City * State * Day Phone* Night Phone Best time to contact: Morning Afternoon Night Email Address* Are you currently investing? Yes No Type of investment: Bonds Mutual Funds Stocks Real estate Other Investment objective: Conservative Balanced Risk Current investments: 0-25 k 25-100 k 100-250 k 250 k+ All information given herein is strictly confidential and will not be re-distributed for any reason other than for the specific use intended. To be removed from our distribution lists, please Click here. ***
Conference calls/best quality/$.18 per minute!
Title: Take Control Of Your Conference Calls Crystal Clear Conference CallsOnly 18 Cents Per Minute! (Anytime/Anywhere) No setup fees No contracts or monthly fees Call anytime, from anywhere, to anywhere Connects up to 100 Participants International Dial In 18 cents per minute Simplicity in set up and administration Operator Help available 24/7 Get the best quality, the easiest to use, and lowest rate in the industry. If you like saving money, fill out the form below and one of our consultants will contact you. Required Input Field* Name* Web Address Company Name* State* Business Phone* Home Phone Email Address* Type of Business c 1999-2002 CCFL To be removed from our distribution lists, please Click here.. ***
Re: TCP-syslog (as RFC)
Darren, with thre risk of starting a flamwar .. However for syslog-reliable, as good as the protocol is, there are no implementations yet! And you didn't implement it because ? As said, NO S-R is to complex to implement _*_ for us _*_ ( my custumor the _user_) ! Our implemenation is based on BSD's syslogd, with a few hundred line of C-code extended. The custumor can manage that .. But for working on S-R: no, not an option. Tryed it. But no, no go, no budget ... (personally, But that's another storry. ..) (Yes, You can say that is a kind of not here ... But not one I can influance) ...and rather than build syslog-reliable, which has been put through a process of international peer review, by intelligent people, you've gone away and designed your own protocol. Wel kind of. Choosen to use an option. And yes, build it, reviewed it internally. But also (trying) to ask for your help! To review it, to make use of this WG to fill the gap we found, we think So I hope you will help. But as nobody is willing to comment on this protocol, even without willing to read it, I think it's better no to send our Req for comment to this group. Maybe some other time, some other place ..
Re: Any early syslog-sign implementations?
We are currently spawning off a project that will hopefully around may/june bring a basic implementation of syslog-sign. A few things need to be finalized, but I am positive it will happen. Question: are there some implementations already out? Any planned within that time frame? Our project will most probably run initially under win32, so I guess I have already a (open source) implementation for syslog-sign. It is based on FreeBSD's syslog; and currently aimed ad FreeBSD. Porting to others is simple. It is based on the previous draft. I have given a presentation about it, on BSDEuroCon 2002 See http://2002.eurobsdcon.org/ http://2002.eurobsdcon.org/papers/#mietus http://2002.eurobsdcon.org/papers/mietus_presentation.pdf Email mee for more info --ALbert Mietus Sent prive mail to: [EMAIL PROTECTED] Sent business mail to: [EMAIL PROTECTED]
FYI: implementation of syslog-sign now on SF.net
Hello All, To keep you informed, I have uploaded my implementation of syslog-sign (based on draft-07) to sourceforge. Info can be found on http://sourceforge.net/projects/syslog-sec/ Note: Today (April 4), the CVS Repository does contain incorrect files. It is corrected, but it will take a day or so, before the correct files are publicly visible. The downloadable file is correct. And contain the latest sources to insert syslog signatures in (FreeBSD's) syslog deamon. Comment's are welcome. Note, changes and updated will be made, someday :-) -- --ALbert Mietus Send prive mail to:albert _at_ ons-huis . net Send business mail to: albert . mietus _at_ PTS .nl
Re: Where we're at - 25 Aug 2003
John and Jon have updated syslog-sign: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-12.txt [[Grrr]]. Every time I continue on implementing draft-N, JJ come up with draft-N+1. I never catch up, that way :-) However, I will switch to draft-12 now. And will comment it as soon I find thing hard to implement. The first one's are found: sec 2.2 TIMESTAMP(3339) === Are the following timestamps allows/wanted? (1) 2003-08-26T12:01:00-00:00 (2) 2003-08-26T12:02:00.+02:00 (3) 2003-08-26T12:03:00.12345678901Z Ad 1. This an UTC time, but with an offset of zero instead of a Z to denote UTC. I have implemented this, while it easy to do. (less code) and it seams to be allowed. Ad 2. Currently this is not allowed. There should be at least 1 digit after the (fracseconds) dot. (1*DIGIT) I can live with this. But I often see a construction like this; e.g. to denote the fraction is unknown/unaccurate. Possible we should allow it (but I'm NOT asking for it) Ad 3. When a TZ offset is used, there is only space for 6 secfrac digits (millisecond). When UTC is used (with Z) the resolution can be increased with 3 digit (microseconds). I think we should not allow that. And change the syntax to allow upto 6 digits, for all timezones. Then, the limit 'upto 32 positions' for the complete timestamp is met, always. sec 2.1 PRI === As Chris explained, syslog-sign is/will be the official standard for syslog, not rfc3164. It's improved. So we can also remove historical limits. The upper value of 191 for PRI (local7.debug) is such a limit. Without changing the protocol (which has space for 3 digits (999), we can extent this. It's not simple to add severities, but we can add facilities with out braking anything. 999 happens to be 124*8+7. So I propose to extent the allowed facilities to 124. This gives a lot of possibilities for new numbers. Here, we have the four options: First, simply add local8 to local108. Second, assign some `new numbers' to 'new, modern items' (e.g. Web, ssh, virus, database,..) Third, we make it assigned numbers (like ports etc), and define the outside this rfc. Then, it is possible to extent syslog-numbers, as needed. Possible, this can/must be done by IANA. Last, we can assign some numbers, and define the rest as reserved (but allowed). Personally, I would vote for option 3. To extent the facilities, we only have to add 1 of 2 paragraphs to section 2.1. When requested, I'm willing to propose one. NOTE: I Agree, this remark is late. I was always on the track keep in inline with rfc3164, but the mail of Chris has shown me we are allowed to improve syslog. I think this simple change is a big improvement! (Let face it, the current name/numers are old) --ALbert Mietus Send prive mail to: [EMAIL PROTECTED] Send business mail to: [EMAIL PROTECTED]
Misunderstanding ( was security and reboot (was ...))
Renair wrote, on a reply of a earlier posting of me. In the context of -sign, this is NO issue at all,[...] However, in the light of -international, things are quite different. But I think you did not get the spirit of my post. I can see this because you snipped out the most important part. [...] reads as follows: I'm sorry, to give that impression. I used the ``[ ... ] '' notation to shorted the quote. That part IS important. In short: For security, crypto is needed. That is what -sign is about. To make that work, a reboot counter can be used. But the security doesn't depend on that counter. Similar, a reboot-counter can be used to make -international work. However, when implementing (or even reading) the rfc's two kind of reboot-counters can lead to misunderstanding. Therefor, I suggest (to both authors of both drafts) to use different words. Just to give the authors a hint: For -sign, which basically add the concept of secure sessions, the term session-number can be used. For -international, (which draft I not familiar with,) a term as fragment-counter can possible be used. Hope this helps, and clearifies. Note to the WG: On a private discussion about syslog, we (Renair and me) agree we agree on most issues. So please don't misread our discussion! --ALbert Mietus Send prive mail to: [EMAIL PROTECTED] Send business mail to: [EMAIL PROTECTED] Don't send SPAM! -- --ALbert Mietus Send prive mail to: [EMAIL PROTECTED] Send business mail to: [EMAIL PROTECTED] Don't send SPAM!
RE: syslog implementations etc.
"Alex" == Alex Brown [EMAIL PROTECTED] writes: Alex [EMAIL PROTECTED] wrote: "Time synchronization is _definitely_ outside Alex the scope of a logging protocol." Actually, _I_ said that. Alex I agree that there should be as few protocol dependencies in the solutions Alex chosen as possible, esp. at the client, but it is important to identify Alex security-related information dependencies that they might indicate. For Alex example, the log timestamp not only confirms serialization of events, but Alex gives them a quantifiable relationship in time. It's well worth Alex identifying needs for accuracy and trust in a time source at the logging Alex system. Which is why I suggested propogating the originator's timestamp in the log message. This solves the problem without exceeding our scope. Whether you want to include intermediate hop timestamps as well is a topic for discussion. Cross-machine time synchronization is NTP's job, not ours. -- Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cs.columbia.edu/~carson/home.html Queen Trapped in a Butch Body
Majordomo results: who syslog-sec
-- who syslog-sec Members of list 'syslog-sec': [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 154 subscribers end END OF COMMANDS
Ballot: On the question of moving the list (anywhere)
[EMAIL PROTECTED] wrote: "If we moved the list address to a list hosted by at www.onelist.com it would provide that a few other nifty features like a calendar, shared web links, etc." Having got my network support people in motion to get the list hosted here, I'm not eager to move it, but if there are a lot of advantages I'll investigate it. Let's keep this off the list, and put the question to a ballot by private email: On the question of moving the list (anywhere) send me a reply message with "yes" or "no". A majority of the current list membership voting "yes" will encourage me to look into it, but I can't promise anything soon. NB: There are only a few weeks until the BOF, so one wonders whether it would be worth it now. This might be something best done afterwards. Alex Brown [EMAIL PROTECTED] +1 508 323 2283
Re: syslog.conf format
"Roger" == Roger Marquis [EMAIL PROTECTED] writes: Roger A few suggestions for /etc/syslog.conf: Roger * default location remains /etc/syslog.conf, No. New semantics, new name. Using an old name for a new thing is a _very_ bad idea. -- Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cs.columbia.edu/~carson/home.html Queen Trapped in a Butch Body
Re: [syslog-sec] Re: timestamps and timezones (was: time-sync)
"cstone" == cstone [EMAIL PROTECTED] writes: cstone Keeping backwards compatibility with traditional syslog by accepting cstone its UDP messages is a useful goal--I don't really like the idea cstone of running two syslog daemons speaking two entirely different protocols This is _entirely_ implementation specific. Use 2 different ports for 2 different protocols. If you want them both implemented by one daemon, that's your choice. -- Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cs.columbia.edu/~carson/home.html Queen Trapped in a Butch Body
Re: timestamp in syslog messages belong to ?
"Darren" == Darren Reed [EMAIL PROTECTED] writes: Re: transit timestamps Darren I have one problem with this: it requires changes/additions to the Darren original message. This poses some obvious problems when you start Darren adding MAC's of the original message, etc, to what's being sent Darren around. No, it doesn't. It only requires the the information be prepended/appended rather than inserted, and that the signatures be nested if you want the transit information to be authenticated. e.g.: log message(srchost,srctime,...,logmsg) MAC(log message,Key(srchost)) transit(trnhost,trntime,...) MAC(alloftheabove,Key(trnhost)) I'm not sure how much value authenticating the intermediate hops has, but it may be a good option. -- Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cs.columbia.edu/~carson/home.html Queen Trapped in a Butch Body
Draft informational/BCP RFC on historical syslog -- comments welcome!
this MAC in real time so that bogus messages never reach the logfiles, or, if the vendor's syslogd can't be replaced, filtering may take place offline. 7. Cryptographic security enhancement 2: Chained authentication The nonce may be replaced with the last MAC sent from the log client, making it possible to detect a gap in the syslog stream from a client. 8. Other security enhancements 3..n: [TBD] 9. Replacement Syslog should be supplemented or replaced with a more robust standard network logging protocol as soon as is practical. This protocol should recognize the existing prevalence of syslog but may follow a completely different design. Security concerns including the above should be foremost in redesign and implementation. 10. Discussion [TBS] 11. Security Considerations This document is primarily concerned with security issues in network logging. Other related issues in UNIX system and network administration are not within its scope. 12. References [TBS] 13. Author's Address Alexander S Brown 3Com Modular Systems Division Three 3Com Drive Marlborough MA 01752 Phone: (508) 323-2283 EMail: [EMAIL PROTECTED] Appendix syslog(3) syslog.conf(5)
Re: and.. what if we define the goals first?
Iv?n Arce [EMAIL PROTECTED] wrote: "... an auditor client is an agent that retrieves logged data from the syslog server and presents it for visualization either by a human being or a program." This is an important point - in security defense, detection and response should be part of the solution, as well as technology (e.g. crypto). The human analysis task is the most expensive part of a total solution! Also, note that this needs to be far more flexible than other parts of the system, because organization needs and human inclinations vary so much. "... doing yet a bit more of a summary (btw, someone should summarize all the traffic in the list at least once a week)..." Thanks for your summary. I will also try to digest the week's list over the weekend, to produce a high-level issues summary or at least some form of "minutes"; perhaps we can get it onto http://njlug.rutgers.edu/projects/syslog. Alex
Re: Performance?
"Andreas" == Andreas Siegert [EMAIL PROTECTED] writes: Andreas Quoting Roger Marquis ([EMAIL PROTECTED]) on Wed, Oct 20, 1999 at 09:49:00AM -0700: Bennett Todd [EMAIL PROTECTED] wrote: While the focus of this design effort is on security, my biggest concern is performance --- and it bears on security. The biggest performance problem is writing logfiles. Syslogd opens the file for each message and then closes it after writing. This causes serious i/o problems, especially when the files grow quickly or larger than 1 or 2 MB. Andreas I strongly suggest a config option that will allow syslog to write to disc Andreas with syncing to not loose any critical data. Ummm... is there _really_ a syslogd hat is so stupid as to open/close the file every time? Wow... man fsync I agree that calling fsync() after each write() should be _optional_ (I currently LD_PRELOAD a null fsync() in order to get syslogd to do something other that sit in the kernel in IOWAIT). -- Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cs.columbia.edu/~carson/home.html Queen Trapped in a Butch Body
Re: FYI -- Re: XML Digital Signatures (xmldsig) for securing network event logging?
Looks like Notes dropped the body of Reagle's reply. Grrr. -- Alex
Re: updated version of XML doc
Kriss Andsten [EMAIL PROTECTED] replied to my reply: " applications. If you invent your own encoding, you will have to do your own parsers; because coding errors in such things are the most vulnerable feature of existing protocol implementations (esp. syslogd) reusing documented, well-exercised code is an important security feature. "Cant really see how that would be a -security- feature. Yes, some standardization help, not arguing there, but making something XML doesnt neccessarily make people less prone to stupidities. Ymmv, of course.." The really stupid errors happen because the protocol was never designed, was coded as a weekend project by an undergrad, and the first attempt, since it worked, was never reexamined. I strongly suspect this is the story of UNIX syslog, which until fairly recently not only allowed a big UDP packet to cause stack overflow, but allowed that stack overflow to permit attacking code to take over the syslogd process!! By reusing an encoding/decoding library with as broad and complex a population of users as XML has, you draw on a much larger range of requirements for implementations. Many of them are likely to be student projects with similar vulnerabilities, but some are likely to be fully engineered products, either commercial or Open Source. It's again a judgement call, but this is an everyday thing in engineering -- we all make build vs buy/reuse decisions constantly, and experience is the test. (For high security close examination should be added; since that's only possible with Open Source, I would say that an open implementation is also a goal for a syslog replacement.) Again, if there is an alternative to XML for network encoding, that inspires similar confidence, let's hear about it. Alex Brown [EMAIL PROTECTED] +1 508 323 2283 NB: I will be away from my desk much of this week; I can be reached most easily at: Alex Brown [EMAIL PROTECTED] +1 617 504 8761
Re: FYI -- Re: XML Digital Signatures (xmldsig) for securing network event logging?
G! - A. From: "Joseph M. Reagle Jr." [EMAIL PROTECTED] on 10/27/99 04:08 PM GMT Sent by:"Joseph M. Reagle Jr." [EMAIL PROTECTED] At 11:16 99/10/27 -0400, Alex Brown wrote: (1) Comments? Do you know of related work? Alex, I don't know of any XML security (confidentiality) standards and we are not chartered to deliver one. However it has been noted that once we define all the syntax/structures for the signatures one may be able to provide confidentiality with minimal to no changes. This might be something we do in a future rechartering once we've met our current requirements. (2) Are there drafts of the RFCs identified in the "Deliverables" section of the xmldsig charter page? Can I obtain them? For drafts and their history, the best place to look is: http://www.w3.org/Signature/#drafts (3) Would you be interested in providing liason at the syslog BOF meeting? Since it is only a BOF, I assume you are not proposing a formal liason/dependency/requirement, but it certainly makes sense to participate if possible. What day/evening is the BOF scheduled for? _ Joseph Reagle Jr. Policy Analyst mailto:[EMAIL PROTECTED] XML-Signature Co-Chair http://w3.org/People/Reagle/ [EMAIL PROTECTED] on 10/27/99 02:46:03 PM Please respond to [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(Alex Brown/US/3Com) Subject: Re: FYI -- Re: XML Digital Signatures (xmldsig) for securing network event logging? Looks like Notes dropped the body of Reagle's reply. Grrr. -- Alex
Re: timestamps and timezones (was: time-sync)
"Roger" == Roger Marquis [EMAIL PROTECTED] writes: Roger Again, from the perspective of an administrator, 5 bytes of timezone Roger info cab be a great help in a number of ways. For reports it is much Roger easier than determining the source timezone by looking at the source Roger hostname (required with existing syslog format). It's also much easier Roger than doing the same and then factoring the difference bttn UTC. The Roger main benefit would be that an originating timezone stamp would make the Roger logs substantially more human readable (a'la sendmail logs). _My_ requirement is that the timestamp is logged in UTC, so that event correlation doesn't require nasty timezone math. If there is _also_ a timezone offset, great, but _please_ do not log timestamps in local time. -- Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cs.columbia.edu/~carson/home.html Queen Trapped in a Butch Body
FYI: 46th IETF-FINAL AGENDA
I still do not have confirmation of plans to attend and present proposals from anyone, although Darren Reed has written that he will be coming around the planet for the festivities, to present the nsyslog work, and possibly the Schneier material. (RSVP on specifics, Darren.) I will try to fill gaps in presentations, but I must have advance notice. As far as I can tell from reports of previous IETF meetings, we can count on an overhead projector, but not a SVGA projector. Anyone who would like to present material should have at least one transparency, and be ready to provide an electronic written copy of the transparency, or of other material, for the BOF minutes. I will also be serving as BOF secretary -- if there is a volunteer planning to attend who can assist, that would be greatly appreciated. Alex Brown [EMAIL PROTECTED] +1 508 323 2283 NB: I will be away from my desk much of this week; I can be reached most easily at: Alex Brown [EMAIL PROTECTED] +1 617 504 8761 -- Forwarded by Alex Brown/US/3Com on 11/01/99 03:47 PM --- [EMAIL PROTECTED] on 10/27/99 05:38:44 PM Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc:(Alex Brown/US/3Com) Subject: 46th IETF-FINAL AGENDA REMINDER: Agendas for working groups are due by Wednesday 3 November at 12:00 noon ET. Please submit them to [EMAIL PROTECTED] If they are submitted after this time, they will not be posted on the web. Agenda of the Forty-sixth IETF November 7-12, 1999 SUNDAY, November 7, 1999 1200-1900 Registration - West Conference Center 1530-1600 Newcomer's Orientation - Palladian Room 1600-1630 IETF Standards Process Orientation - Palladian Room 1700-1900 Welcome Reception - Regency Ballroom MONDAY, November 8, 1999 0800-1930 IETF Registration - West Conference Center 0800-0900 Continental Breakfast - Bird Cage Walk and Palladian Foyer 0900-0930 Opening Plenary Session - Regency Ballroom 0930-1130 Morning Sessions BlueAPP apparea Applications Area Meeting Embassy INT frnetmib Frame Relay Service MIB WG Empire OPS ngtrans Next Generation Transition WG Ambassador RTG bgmp Border Gateway Multicast Protocol WG * Hampton SEC cat Common Authentication Technology WG Executive SEC ipsp IP Security Policy BOF Palladian TSV rap Resource Allocation Protocol WG Regency TSV sip Session Initiation Protocol WG * 1130-1300 Break 1300-1500 Afternoon Sessions I Executive APP calschCalendaring and Scheduling WG Hampton APP vpim Voice Profile for Internet Mail BOF Palladian INT dnsindDNS IXFR, Notification, and Dynamic Update WG Empire RTG ospf Open Shortest Path First IGP WG Regency SEC ipsec IP Security Protocol WG * Ambassador TSV tsvwg Transport Area Working Group WG * Embassy USV uswg User Services WG 1500-1530 Break (Refreshments provided) - Bird Cage Walk and Palladian Foyer 1530-1730 Afternoon Sessions II Hampton APP nntpext NNTP Extensions WG Ambassador OPS mbonedMBONE Deployment WG * Regency OPS policyPolicy Framework WG * Palladian RTG manet Mobile Ad-hoc Networks WG Executive SEC micropay Micro Payments BOF BlueTSV enum Telephone Number Mapping WG Empire TSV nat Network Address Translators WG Embassy USV run Responsible Use of the Network WG 1730-1930 Break 1930-2200 Evening Sessions Embassy APP webdavWWW Distributed Authoring and Versioning WG Empire INT anycast Anycast BOF Executive INT pppextPoint-to-Point Protocol Extensions WG Hampton OPS dnsop Domain Name Server Operations WG Palladian RTG isis IS-IS for IP Internets WG BlueSEC xmldsig XML Digital Signatures WG Regency TSV diffserv Differentiated Services WG * Ambassador TSV iptel IP Telephony WG * * Designates Multicast Sessions TUESDAY, November 9, 1999 0800-1700 IETF Registration - West Conference Center 0800-0900 Continental Breakfast - Bird Cage Walk and Palladian Foyer 0900-1130 Morning Sessions Empire APP impp Instant Messaging and Presence Protocol WG Executive INT dhc Dynamic Host Configuration WG Embassy OPS grip G R for Security Incident Processing WG Regency OPS policyPolicy Framework WG * Ambassador RTG msdp Multicast Source Discovery Protocol WG * Palladian SEC pkix Public-Key Infrastructure (X.509) WG Hampton TSV spirits Services in the PSTN/IN Requesting Internet Services WG BlueTSV rsvp Resource Reservation Setup Protocol WG 1130-1300 Break 1300-1400 Afternoon Sessions I Executive APP deltavWeb Versioning and Configuration Management WG Embassy APP qualdocs Quality Document Transfer BOF Hampton INT dhc Dynamic Host Configuration WG Ambassador OPS opsarea
Re: draft-syslog-bcp
As usual, Notes mail has got line terminations wrong. Here's an attachment version of the text file. (See attached file: draft-syslog-bcp.txt) Sent by:Alex Brown [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: (Alex Brown/US/3Com) Subject:draft-syslog-bcp Network Working Group A. Brown Request for Comments: 3Com MSD Category: Best Current Practice 25 Oct 1999 Security issues in network event logging Status of this Memo This document is a draft Internet Best Current Practice for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents [tbs] 1. Overview Network systems supporting a variety of protocols and services need to be able to "log" or record those protocols' important events, both locally, in persistent storage within the system where the event occurs, and through messages to a remote system where persistent storage takes place. This logging process has several distinct phases: detection of the event, local storage of event record, construction of remote log message, transmission of log message as log protocol client, reception of log message at log protocol server, timestamping/filtering/manipulation of log message, storage of log pro- tocol message as event record in a file; and finally, filtering, retrieval and analysis of events by a offline program or a human. As a result of the close relationship between the UNIX operating system and the Internet protocols, the UNIX syslog service has become a de facto logging protocol for network systems, despite severe deficiencies as a protocol, either for a persistent storage service or for protection of critical information about device and service status. This is because the syslog service was provided initially only for local event logging within a UNIX host, and only later grew into a general network log service. [Historical details TBS as desired.] Because of this close relationship, the following description assumes a UNIX system environment. Other system environments have also imple- mented syslog clients and servers, notably network devices such as routers, switches, and firewalls. 2. UNIX syslog as a de facto standard logging protocol UNIX syslog is both an API and a very simple protocol, for persistent storage of text messages, used throughout UNIX network service software. It is best described by reference to the syslog(3) manpage documentation (see Appendix). Syslog as an API provides minimal structure for an error or notification message: a user of the API calls openlog() to set an enumerated "facil- ity" identification number and an "options" flag indicating some proper- ties of the UNIX domain socket connection to the local log server pro- cess, syslogd -- including direct write to console if syslogd is una- vailable. The syslog message is formed by the syslog() library routine as a text string formed with sprintf(3S) with an added "%m" format available for insertion of the message associated with the current "errno" error number variable. The facility ID value (upper bits) and an enumerated priority value (lower bits) are IOR'd to form a 16 bit word value which is placed at the head of the message within angle brackets, followed by the string output of ctime() as a timestamp. The message text is concatenated to this header, and the resulting text mes- sage is sent to the local "syslogd" log server process using send(3N). This message may also be written to the user's standard error file out- put, and/or the system console, independent of the syslogd process. Syslog as a network message transport is an extension of local file log- ging by syslogd, through its configuration file, syslogd.conf (see Appendix) which is a semicolon-separated list of priority specifications consisting of a selector followed by an action. A selector is a list of the form "facility.level [ ; facility.level ]", where facility is a sys- tem facility name (as used in openlog(3)) or comma-separated list of facilities, and level is a name of one of the enumerated values (used as first argument to syslog(3)) indicating the severity of the condition being logged. The action is a list of one or more filenames, usernames, or remote host names (identified by prefix "@"). If the action includes a remote host name, the message is forwarded to the named host via UDP, to port 514 (as assigned by IANA, and configurable). The syslogd pro- cess (if any) at that host will receive the message and dispose of it according to its syslogd.conf configuration, possibly including forwarding. Various ad hoc corrective features in this pro
Re: updated version of XML doc
Kriss Andsten wrote: "Again, it's the stuff it sends down the wire that is my concern here. If you can 'force' something to send five, ten, maybe twenty times the data you use to trigger the log entry, you're a good way closer to denial of service. It may be high this, high that, high everything - if it makes something vulnerable from normal usage (logging selective IP traffic could very well be considered normal usage, imo), it's an achilles heel. Of course, I might be barking up the wrong tree myself thinking it's better do use standard stuff than specialities in order to keep stuff running in a somewhat secure way. Am I?" Well, I think it's always better to use something that thousands of people are working with daily, rather than something cobbled together by one or two part-time engineers -- until, of course, thousands of other engineers are also cobbling. (How about Linux as an example?) But you have put your finger on it - we have to make a judgement call about the resources necessary to handle some real-world needs for robust and secure network logging. My feeling is that an organization with real enough needs will spend some money on these resources, so that neither network nor CPU bandwidth nor disk storage is a likely DoS weakness. All three of these are so cheap now, and falling precipitously. However, there are many schools and universities (and, who knows, day-care centers) that need secure logging and cannot afford these resources. Perhaps this is not a solution for them; but I think it's closer than full IPSEC tunnels would be. For these applications I think there should be some consideration of additional extensions to existing syslog that provide some privacy as well as authentication -- perhaps S/MIME, or one of the other secure email message formats? No guarantee any of them would fit in a UDP packet. This is all a ripe topic for discussion around the BOF. Alex Brown [EMAIL PROTECTED] +1 508 323 2283 NB: I will be away from my desk much of this week; I can be reached most easily at: Alex Brown [EMAIL PROTECTED] +1 617 504 8761
Re: Fwd: FYI: 46th IETF-FINAL AGENDA
I'll arrive in DC on Monday afternoon but have to leave on Thursday afternoon. Would you like to get together before the BoF? I'm staying at the Marriott. I'm arriving Monday evening and am booked at the IETF's hotel on New Hampshire Ave - can't remember the name right now. I will give you a call that evening when I get in (assuming it's not too late). We could meet for breakfast or at some point during the conference. I have a fairly busy schedule because I'm expected to report on several sessions to my division, but I think we can probably find some time on Tuesday. I don't have the schedule with me right now, but I'll try to send it to you tomorrow. If you could do the same perhaps we can agree before we arrive. The number I gave for reaching me this week is a cell phone that I'll be carrying, so you can reach me through it at almost any time: (617) 504 8761. I'm on the road this week as well. ;-) Thanks, Chris Same here. As I write I'm spending a pleasant evening snuggled close to a NetBuilder II on a T1 umbilical cord in Schaumburg IL. ... Alex
Typo ( sorry): Re - Informal meeting at 3TF of interested people on key initialization
James Bind (JB) is actually Jim Binder.
Informal meeting at 3TF of interested people on key initialization
This afternoon Dan Nessett (DN), Bill Vroman (WV), Carl Madison (CM) and myself (AB) met with Boby Joseph (BJ) from NSBU and James Bind (JB) from PCBU on key initialization and management. BJ is interested because he's been investigating a similar scheme but based on public key technology; JB is interested because of similar work in NICs. DN described the basics of the simple key initialization procedure, making it clear that the embedded 128b key is never seen on the wire, and is used only once, for authentication, not encryption, in a semi-automatic administrative procedure that enforces a single use of the key in initialization. The procedure uses a simplified Diffie-Hellman key exchange rather than full IKE procedures, to reduce memory footprint and perhaps key exchange time, for small devices with limited CPU resources. BJ described an alternative that uses PK certificates fully, assuming an embedded PK certificate and secret key, and some 3Com PK infrastructure to support recording and retention or possibly derivation of per-device certificates and keys. Among other complexities of the key management problem, DN pointed out that the company assumes a huge legal liability for the confidentiality of this key database in its CA. Moreover the PK approach uses more CPU resources than can be afforded in the smallest devices. JB described a similar embedded key in the Typhoon GE NIC which is intended primarily to serve as a mechanism for enabling software features; it's called a "Crypto Enabling Feature". Some thought has been given to other uses including secure management initialization; he is interested in looking into this key management approach. (BJ also described similar feature enabling crypto applications in the NSBU products.) DN promised more information in the draft 3FC; no commitments on date due to travel and conflicting activities. (AB also reported briefly on progress on the IETF BOF on syslog security.) Alex Brown [EMAIL PROTECTED] +1 508 323 2283
FYI on draft texts
FYI - I have forwarded ASCII text versions of the drafts to Rob Cernak to go on the web page, because voices from the Star Chambers of the IETF have spoken: HTML doesn't cut it. Rob might not get to it before next week. If you want to see it right away let me know tonight or Saturday and I will send it to you. I will also try to get a mirror of Rob's web page up before I leave for DC. Or, of course, I could mail the whole thing to the list, but I understand there are some strenuous objections due to bandwidth waste. In respect of our worldwide participants, many of whom pay a great deal for that bandwidth, I think I should make it available on demand. Alex Brown [EMAIL PROTECTED] +1 508 323 2283 Sent by: Alex Brown - Consulting Engineer, MSD To: [EMAIL PROTECTED] cc: Subject: Revisions, text format files for http://njlug.rutgers.edu/projects/syslog Hi Rob - Sorry to bother you again -- I've been told in no uncertain terms that HTML as the primary form of distribution for these drafts is unacceptable, and ASCII text is necessary even in rough discussion drafts. So, I'm attaching both another uuencoded gzipped tar file of the HTML of tonight's version of my BCP draft, and text file versions of both the BCP and Chris Calabrese's XML encoding draft. Could you post all of them on the web page, both text and HTML? [attachments deleted] Thanks again. Alex Brown [EMAIL PROTECTED] +1 508 323 2283
Re: Fwd: FYI: 46th IETF-FINAL AGENDA
Thanks very much - I appreciate the help, and it will look great to have us working together. Alex Brown [EMAIL PROTECTED] +1 508 323 2283 NB: I will be away from my desk much of this week; I can be reached most easily at: Alex Brown [EMAIL PROTECTED] +1 617 504 8761 "Chris M. Lonvick" [EMAIL PROTECTED] on 11/01/99 04:20:30 PM Sent by: "Chris M. Lonvick" [EMAIL PROTECTED] To: Alex Brown/US/3Com cc: Subject: Fwd: FYI: 46th IETF-FINAL AGENDA Hi Alex, I'll be there and I can scribe/secretary/assist. Thanks, Chris I will also be serving as BOF secretary -- if there is a volunteer planning to attend who can assist, that would be greatly appreciated. Alex Brown [EMAIL PROTECTED] +1 508 323 2283
46th IETF-Breakout Rooms
FYI -- Forwarded by Alex Brown/US/3Com on 11/05/99 12:46 PM --- [EMAIL PROTECTED] on 11/04/99 05:09:49 PM Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] cc:(Alex Brown/US/3Com) Subject: 46th IETF-Breakout Rooms Just a reminder that all meeting rooms will be equipped with an overhead projector and a data projector. Marcia
FTP location of output of IETF46 syslog BOF
For your information re: Security Issues in Network Event Logging BOF Drafts to be submitted from this BOF were posted temporarily last week at: ftp://msg.ne.mediaone.net/pub This material has now been moved to: ftp://ftp.3com-ne.com/pub/syslog The previous anon FTP URL will remain as a mirror of the new location. Alex Brown [EMAIL PROTECTED], [EMAIL PROTECTED] +1 508 323 2283 Access [EMAIL PROTECTED] via: (1) Send "subscribe syslog-sec" to [EMAIL PROTECTED] (syslog-sec-digest also available) (2) Anonymous FTP to ftp.3com-ne.com, directory /pub/syslog-sec, or (3) Web gateway at http://njlug.rutgers.edu/projects/syslog. (Thanks again to Rob Cermak [EMAIL PROTECTED].)
LAST CALL for BOF agenda timeslots
By the end of today (Wed. Nov. 3) I must have all requests for timeslots at the IETF Birds-Of-a-Feather (BOF) meeting to take place at the 46th IETF conference, at the Omni Shoreham Hotel in Washington, DC, 7-12 November 1999.The published agenda is below -- note some small modifications from the published agenda. We may modify details further -- please contact me with concerns and suggestions. All interested participants can contribute comments and proposals to this list, which will remain active through the BOF and until any continuing working group provides a replacement. Results of the BOF will be posted here as available. Thanks again for your interest and participation -- Alex Brown [EMAIL PROTECTED] +1 508 323 2283 SYSLOG - Security Issues in Network Event Logging BOF Security Issues in Network Event Logging BOF (syslog) Wednesday, November 10 at 1530-1730 === CHAIR: Alex Brown [EMAIL PROTECTED] SECRETARY: "Chris M. Lonvick" [EMAIL PROTECTED] DESCRIPTION: Syslog is a defacto standard for network logging of system and network events, but it has never been treated as such by IETF. This WG would briefly describe existing BSD syslog in an informational RFC and proceed to recommend several levels of security mechanisms that could be applied to syslog daemon and client operation to meet various kinds and levels of threat. The WG would also discuss replacement of syslog with network logging systems that are (a) designed, and (b) designed to meet specific security threats with cryptographically strong protocols. AGENDA: UNIX syslog as de facto network event logging standard UNIX syslog origin as BSD local system event logging mechanism Extension to network logging by assignment of UDP port 514 Lack of recorded standard style documentation of syslog History of security defects in design and implementation Security analysis: local vs network threat model; low, medium, high risk environments Proposals and related work TCP/IP based syslog replacements "Universal Logging Messages (ULM)" draft-abela-ulm-05.txt Schneier (http://www.counterpane.com/secure-logs.html) Reed and Assange (http://cheops.anu.edu.au/~avalon/nsyslog.html) Arce (http://www.core-sdi.com/ssyslog) 3Com: simple filtering and authentication methods Calabrese: XML transport encoding of ULM data model XML digital signatures (xmldsig) Alternatives to XML transport encoding Needed work Syslog description RFC (finally) Security recommendations for existing syslog Secure replacement for syslog Discuss IETF approach: New WG? Activity within existing WG? BOF outcome: WG formation? BOF records published?
Re: Guarunteed Delivery and Initial Message Submission
"Mark" == Mark D Roth [EMAIL PROTECTED] writes: Mark Another possible difference between syslogd-syslogd transfers and Mark process-syslogd transfers is the fsync() interval. Since the Mark receiving syslogd cannot send an ACK until it's fsync()'ed its queue Mark file(s), we will probably want to implement a mechanism whereby the Mark server can accept a number of messages before fsync()'ing, and then Mark ACK the last one to tell the client that all of the messages up to Mark that point have been received. This obviously doesn't work for Mark initial message submission, because an application process needs an Mark ACK immediately in order to stop blocking in the library call. Whoa! I don't want to _ever_ guarantee an fsync(). I want to be able to say "I'm a best-efforts server, I got your message, it will be written to non-volatile storage unless I crash". Strict delivery really should be optional. -- Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.cs.columbia.edu/~carson/home.html Queen Trapped in a Butch Body
FYI -- Re: XML Digital Signatures (xmldsig) for securing network event logging?
For your info - Correspondence with chair of "XML Digital Signature (xmldsig)" IETF working group. XML standardization work on encoding of security wrappers seems to be directed at financial transaction applications, primarily for authentication of data with public-key signatures. A simple MAC based authentication tag, using a private key (shared secret) might be a reasonable outgrowth or alternative that's usable in any log client device. However, there's no progress so far on standard tagging for encryption, e.g. the "CRYPT ...ciphertext/CRYPT" suggested by Chris Calabrese, although using the xmldsig work "one may be able to provide confidentiality with minimal to no changes." Alex Brown [EMAIL PROTECTED] +1 508 323 2283 Sent by: Alex Brown [EMAIL PROTECTED] To: "J. Reagle" reagle @w3.org, Donald Eastlake 3rd dee3 @torque.pothole.com cc: Jeffrey Schiller jis @mit.edu (Alex Brown/US/3Com) Subject: XML Digital Signatures (xmldsig) for securing network event logging? Re: http://www.ietf.org/html.charters/xmldsig-charter.html Hello - I'm chair of the BOF on security issues in network event logging (syslog) to be held at IETF-46 next month. An email list for preparation of the BOF agenda ([EMAIL PROTECTED]) has drawn a lot of interesting contributions, including a suggestion that a replacement facility use XML encoding in its transport protocol (over various networks or links, some insecure). I'm interested in this approach because it might seem to permit applying security envelopes over data elements within a message, rather than over whole messages or the full channel. I have not been following XML security activity, however, other than noting a few trade press articles over the past year. The xmldsig activity seems to answer the need for a common approach to authentication, but I wonder if there has also been work on privacy tagging for encryption. (1) Comments? Do you know of related work? (2) Are there drafts of the RFCs identified in the "Deliverables" section of the xmldsig charter page? Can I obtain them? (3) Would you be interested in providing liason at the syslog BOF meeting? Thanks. -- Alex Brown +1 508 323 2283 Consulting engineer - 3Com Modular Systems Divison Three 3Com Drive - Marlborough MA 01752 USA -- Forwarded by Alex Brown/US/3Com on 10/27/99 02:21 PM --- "Joseph M. Reagle Jr." [EMAIL PROTECTED] on 10/27/99 12:08:30 PM Sent by: "Joseph M. Reagle Jr." [EMAIL PROTECTED] To: Alex Brown abrown @3com-ne.com cc: Donald Eastlake 3rd dee3 @torque.pothole.com, Jeffrey Schiller jis @mit.edu (Alex Brown/US/3Com) Subject: Re: XML Digital Signatures (xmldsig) for securing network event logging?
