Dear TF-CSIRT, dear DB-WG community, [ and apologiess to those receiving more than one copy ] I was working with the RIPE NCC recently to finalize the implementation plan for the CERT/IRT Object. We had some interesting discussions (also including Yuri working on IODEF et.al.), and the NCC was checking "our" proposals against some implementation constraints. The result of that process is attached below. I'd ask the CERTs and IRTs in particular, and everyone else being interested, to review the summary. Please try to deploy the stuff "on your desk" and maybe submit your comments. I hope to be able to have a very final and brief discussion, and the technical "go-ahead", in Prague. As I understand from the NCC, we can then expect to see a quick implementation! Regards, and thanks to the NCC for offering very helpful suggestions, and thanks to the IRTs which have been patient for so long! Wilfried. ______________________________________________________________________ inetnum: 193.171.2.0 - 193.171.2.255 netname: ACONET-DEMO-2 descr: ACOnet addresses for demos and transient events country: AT admin-c: WW144 tech-c: UVNA1-RIPE tech-c: WW144 status: ASSIGNED PA remarks: ---------------- remarks: 20000720-20001231: UniVie/PTA ADSL trials - core remarks: ---------------- mnt-by: ACONET-LIR-MNT mnt-irt: ACONET-IRT # use irt object name here changed: panigl@cc.univie.ac.at 20010629 source: RIPE irt: ACONET-IRT address: ACOnet Incident Response Team address: c/o Vienna University Computer Center address: Universitaetsstrasse 7 address: A-1010 Vienna, Austria phone: +43 1 4277 140 00 fax-no: +43 1 4277 9 140 e-mail: Domain-Admin@UniVie.ac.at signature: PGPKEY-<key-id> # IRT team key first (mand.) remark: # member keys next (optional) remark: # messages from the IRT are remark: # signed with this/ese key/s encryption: PGPKEY-<key-id> # use this to encrypt a message remark: # to be sent to the IRT remark: # multiple entries allowed admin-c: WW144 tech-c: WW144 auth: CRYPT-PW bocEHQ0niH52I # checked to authenticate auth: PGPKEY-DBC579D4 # insertion of ref. to this obj. notify: Woeber@CC.UniVie.ac.at mnt-by: ACONET-LIR-MNT # use the regular mntner: mech. remark: # to protect the irt object changed: woeber@cc.univie.ac.at 20000202 source: RIPE mntner: ACONET-LIR-MNT descr: ACOnet Local-IR admin-c: WW144 tech-c: WW144 upd-to: Domain-Admin@UniVie.ac.at mnt-nfy: Domain-Admin@UniVie.ac.at auth: MAIL-FROM .*@cc\.univie\.ac\.at # a *very* bad example auth: PGPKEY-DBC579D4 notify: Woeber@CC.UniVie.ac.at mnt-by: ACONET-LIR-MNT referral-by: RIPE-DBM-MNT changed: woeber@cc.univie.ac.at 20000202 source: RIPE Operations: irt: object creation is manual (like mntner:) Semantics/Security: "auth:" mechanisms specified are used for authenticating the reference insertion. For an irt: object, only CRYPT-PW and PGPKEY SHOULD be used! However, this recommendation is not enforced by the DB software. This is considered to be a BCP issue. The 1st entry in the list of signature: SHOULD be the team-key, any additional entries MAY BE secondary team keys and/or team members' keys. This is considered to be a BCP issue. The key-cert objects for the PGP keys will be stored in the public keyring. More generally, only keys supported by the RIPE DB will be allowed. However, as soon as the DB accommodates additional certificate formats, those should be allowed here as well by default. Lookup and use: $whois iplookup Default behaviour, no irt is returned (as expected) because mnt-irt is more a mntner reference, which is never returned automatically. The user will need to perform a second query to retrieve info about the IRT. This will also reduce the abuse of an irt object by people sending reports to whatever e-mail address they see in an output. $whois -c iplookup This query would do a tree-walk, like the referral mechanism, trying to find an entry with an mnt-irt attribute present. The query will display an object containing the reference, but not the irt object itself. Again, people will need to perform a second query to retrieve info about the IRT. The ideas behind this proposal are: - not to alter the default behaviour for object lookups (only contact info is returned, not mntners) - not to modify the behaviour of -l flag. [ed. comment: during the discussion we were thinbking about modifying the behaviour of the -l flag when a -c flag were present.] Questions/Comments: Q: Do we allow any mntner: object in an irt: object's mnt-by: attribute, even those having weak authentication? A: no special provisions in the software. This is considered to be a BCP issue. A: a more useful approach is to deprecate weak authentication mechanisms altogether. Q: Do we want to have/allow a hierarchy similar to mnt-lower: for .e.g. inetnum: and inet6num: objects? A: no Q: should the reference to an irt: object be it's name or it's handle? A: the irt object is very similar to mntner object, so global uniqueness should not be an issue. Q: Do we want something like a trouble: in the role:, or simply use remark or put an (optional) abuse attribute into the irt object? A: probably not. Including uniform info for spam or abuse contacts is a BCP issue. [ed. comment: see discussion on anti-spam list.] Q: do we want to use more descriptive attribute names for signature and encryption? E.g. irt-sig: and encrypt:, or sig-from: and encrypt-to: Q: no clear preference, no decision in WG... so, what? A: stick with signature and encryption Decisions: Do not implement a url: attribute. Can be done with remark: Interaction with (public) key servers is outside the scope of this proposal. Implement irt object for inet[6]num initially. Extending functionality to e.g. AS number objects [ed. comment: and route objects] leads to the interesting question how to extend RPSL. This is similar to the issue of IPv6-extensions to RPSL. Separate project. Suggested object templates: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] encryption: [mandatory] [multiple] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inetnum: [mandatory] [single] [primary/look-up key] ... mnt-irt: [optional] [multiple] [inverse key] ... inet6num: [mandatory] [single] [primary/look-up key] ... mnt-irt: [optional] [multiple] [inverse key] ... _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~