summary for CERT/IRT object proposal [3]

  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 at 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 at 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 at CC.UniVie.ac.at
mnt-by:       ACONET-LIR-MNT            # use the regular mntner: mech.
remark:                                 #  to protect the irt object
changed:      woeber at 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 at UniVie.ac.at
mnt-nfy:      Domain-Admin at UniVie.ac.at
auth:         MAIL-FROM .*@cc\.univie\.ac\.at  # a *very* bad example
auth:         PGPKEY-DBC579D4
notify:       Woeber at CC.UniVie.ac.at
mnt-by:       ACONET-LIR-MNT
referral-by:  RIPE-DBM-MNT
changed:      woeber at 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 at 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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~