[techsec-wg] Draft minutes TechSec, RIPE 46, Amsterdam

Comments, fixes, additions, etc., either to the list
or to the chair <ted at tednet.nl>

Draft Minutes of Techsec-WG meeting at RIPE46
==================================================
Location: St. Johns II, Krasnopolsky, Amsterdam
Chair:  Ted Lindgreen
Scribe: Maximo Alves/Tim McGinnis
Date:   03 September 2003, 16:00


A. Administrative Matters

    * scribe:  Tim McGinnis, backup: Maximo Alves
    * list of participants: list passed and given to chair after being circulated
    * agenda
    * minutes -minutes of last 2 previous tech-sec WG meetings are not online. 
      Action on Chair to chase these down.

B. DISI report (20 minutes), Olaf Kolkman, RIPE NCC.
Olaf is fairly optimistic that DNSSEC will be rolled out in Q1 of 2004.

Other DNS presentations in DNS and NCC-Services WGs on Thursday.

NLnet Labs doing experiment with DNSSEC, they have operational experience, 
and have run workshops to spread knowledge and test protocol in live 
environments.

Key signing tools in development, RIPE NCC courses running monthly.

ns.ripe.net has had a DNSSEC experiment, 8 hours to sign the zone, 
this is largely due to key size.  There are memory requirements for 
DNSSEC. Zonefiles grow, be prepared.

Q: George Jones: What is the status of bind regarding the latest DNSSEC protocol changes?
Susanne from ISC gave Answer: Some developments, tests and workshops have been done. 
It should be released soon (Q1).

C. Internet draft draft-jones-opsec-01.txt presentation and discussion, George Jones, Mitre.
 
The goal is to secure large scale IP infrastructure devices. Very informative presentation.

Presenter asked for feedback and community needs, especially around CLI interface requirements.

Comment from room:  Yes, I wanted a CLI on all the boxes I adminned in the past, because no CLI 
meant (in those days) that you can't remotely manage them out-of-band.

In-band key management is unsolved.

More feedback needed, especially around filtering requirements.

Question;  most of these things are available commercially, yes?
A: No, that why the draft is proposed: to force the vendors
to pay more attention to these requirements.

Q: BCP status of document itself will it be informational or BCP?

A: For pragmatic reasons I intend to separate the unambigious requirements
  from the less urgent and/or debatable wishes. The former will then go in
  a BCP and the latter into informational RFC.

No definition of what should be logged, firewall and F-secure people are talking about this.

Comment from room: You only listed authentication, not authorization things.

It would be nice to have a list of messages and what they mean, but proprietary conflicts abound.

Many work area tensions being resolved,

4 likely outcomes:

1 nothing
2.publish BCP 
3.publish informational RFC
4 go to working grouup

Comments from Chair: doc too big, split it into informational and strict requirements is a wise decision.

Comments: 01 is better than 00
Comments: 2 issues:
Comments: 1. in secure network accountability/auditing is better terminology.
Comments: 2. network op has to log traffic AND events
A: lets talk

D. TF-CSIRT update, Baiba Kaskina, TERENA.

They have meetings and training courses held throughout the year

IRT object is now in RIPE Db after lots of hard work.

Q: Who is 3rd party who you have outsourced to?
A:  S-CURE B.V.

Do you have any relation to the EU Committee for network Security information Agency

Yes and no, more yes than no.  CSIRT folk talk in Brussels, and in CSIRT meetings sent to 
comission in July 2003.  We hope to have an attendee from Brussels in Amsterdam in Sept 25-26.

Jaap Akkerhuis made a comment about the public-private partnetrship with EU.

Other comments:  EU wants to centralize management of net security.


E. Update on Fonkey and PKI related developments at IETF (15 minutes), Yuri Demchenko, NLNetLab

Yuri described a system to distibute cryptographic keys and reference attribute 
information bound by digital signature.

Java key management tool is now available.

Q: none