"Chris M. Lonvick" wrote: > Hi Chris, > > At 01:57 PM 10/25/00 -0400, Chris Calabrese wrote: > > >Chris Lonvick wrote: > >> > The IDWG has defined their own format which meets their requirements. > The ULM work and your proposal look viable for defining the contents > and format of event messages. I've heard from very many people that > they would like to see that work started again. However, it is outside > of the scope of this WG. Please get together and propose a BoF. If > not that, then get together and submit an internet draft. Since my original proposal was basically a superset of what's in COOKED, I think the best choice here is to make sure all the base needs are met in the base ID and then have an extension ID. Most of what I think is missing so far has to do with crypto/authentication capabilities, though I think we could probably stretch things to include attributes that the sending system might know about the message even if they weren't explicitly set by the originating process. Things like the process name, process ID, user name, and a time stamp (that last one's probably provided by BEEP). In MLS environments, this would even include security labels. > >CONFIDENTIALITY - Oops, nothing going on there. > > > >You can get on-the-wire confidentiality through SSL/TLS or IPsec. > > Confidentiality and transmission integrity is fundamental to BEEP. See: > http://www.ietf.org/internet-drafts/draft-ietf-beep-framework-05.txt > >However, that still leaves the possibility of rogue/trojan relays or even > >collectors. Ideally we want to be able to send the logs anywhere and > >still make sure only authorized people/processes can see them. > > TLS can use bidirectional authentication through the use of authoritatively > signed certificates. If that's too much of a problem to set up, it can > fall-back to single sided authentication or null authentication. That's > just the way that it's working in most browsers today. It doesn't help to know that the relay/collector is the real one if it isn't authorized to see the data or not trusted not to modify the data in transit. You need end-to-end solutions here. This is a familiar scenario in places where untrusted groups run the infrastructure (such as universities) or where there are very strict guidelines regarding who can do what and take credit for it (health care, military, banking). > >The only way to do that is to encrypt the sensitive data and leave it > >encrypted. Something like this: > >--some deleted-- > > Are you proposing that the device generating the message have the > capability of encrypting all messages? Yes. This may not be necessary for all applications (and may not be feasible for all hardware), but the capability should be defined in the protocol, IMO. > >> This brings up some architectural questions that I'd like to pursue. > >> > >> 1. Should some wording go into the Authenticated and Reliable IDs that > >> explicitly states what is to be done with messages received? Perhaps > >> the Authenticated relay must wrap the Traditional message into an > >> Authenticated format using its own credential (T-[TA]-A)? Perhaps the > >> Reliable relay must do the same (T-[TAR]-R)? > > > >Be careful that you're not mandating that Relays sign data > >injected into the stream by attackers! > > I think that there is the same concern with all syslog messages today. > Having them wrapped/signed by the first relay doesn't mean that any > confidence should be put into their origin. It would only mean that > the first relay received them. OK, we're thinking the same thing here, then. The relay would sign that it received the message. It wouldn't sign the message on the sender's behalf. > >Ideally the implementation would allow you to tune what IP's > >you're willing to sign stuff for and maybe put in support for the > >lightweight authentication stuff the router guys are working on > >(i.e., sign stuff that came in authenticated in the other format). > > umm.. I didn't catch that. Maybe I missed something, but I thought some folks were working on a 'lightweight' authentication protocol that could be used by low-computing-power embedded systems (like routers and switches). This statement related to the idea that a relay might sign data as authentic that came in under this protocol as the authentication data couldn't be forwarded
begin:vcard n:Calabrese;Chris tel;work:201-703-7218 x-mozilla-html:TRUE org:Merck-Medco Managed Care, L.L.C.;Internet Infrastructure and Security adr:;;1900 Pollitt Drive;Fair Lawn;NJ;07410;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Internet Security Administrator fn:Chris Calabrese end:vcard
