[Sidr] Minutes for SIDR WG meeting at IETF 66

The notes from this meeting were taken by Shane Kerr - thanks Shane. I've attached them to this note.

[The agenda, collection of presentations and notes from the IETF 66 SIDR WG meeting are at now uploaded at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 (scroll down to the routing area, and SIDR is the last WG in the Routing Area list)]

thanks,

  Geoff

==============

Secure Inter-Domain Routing
2006-07-10 13:00

Chairs: Geoff Huston & Sandy Murphy
Minutes: Shane Kerr

AGENDA:

A. SIDR Session

 1) Administrivia                                             5 minutes

  - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html
  - Scribe?
  - Blue Sheets
  - Agenda Bashing

 2) Certificate Discussion                                  60 minutes

  - Certificate Format (Geoff)
    A Profile for X.509 PKIX Resource Certificates
    draft-ietf-sidr-res-certs-01.txt
    http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-01.txt

  - Certificate Repository (George Michaelson)

    A Profile for Resource Certificate Repository Structure
    draft-huston-sidr-repos-struct-00.txt

    http://www.ietf.org/internet-drafts/draft-huston-sidr-repos-
    struct-00.txt

  - ROA Specification (Steve Kent)

  - Status Report on a trial implementation of Resource Certificates
  (George Michaelson)

 3) Transport Security

  - Re-keying the TCP MD5 Option (Steve Bellovin)            20 minutes
    "Key Change Strategies for TCP-MD5"
    draft-bellovin-keyroll2385-00.txt
    http://www.ietf.org/internet-drafts/draft-bellovin-keyroll2385-00.txt

  - A New TCP Authentication Option (Ron Bonica)            20 minutes
    "Authentication for TCP-based Routing and Management Protocols"
    http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt

  - Key Selection for TCP Authentication (Brian Weiss)      20 minutes
    "Automated key selection extension for the TCP Authentication Option"
    http://www.ietf.org/internet-drafts/draft-weis-tcp-auth-auto-ks-01.txt

  - The TCP Simple Authentication Option (Joe Touch)   20 minutes

    http://www.ietf.org/internet-drafts/draft-touch-tcpm-tcp-simple-
    auth-01.txt

B. Joint PKIX/SIDR Session

  - Address Space & As Number PKI (60 min.)
    Stephen Kent (BBN)

    This presentation will review the current plans and status for creating
    a PKI that reflects the allocation of resources through Regional
    Internet Registries. The motivation for creation this PKI is to enable
    better security for Internet routing (BGP).

Notes:

2.1 Resource Certificate Profile (Geoff Huston)

    [comments on presentation]

    Steve Kent: (Comment on key size considerations) Originally 2048 keys
    for top-tier CA, allowing 1024 for bottom-tier CA; do think you should
    recommend at *least* 2048 keys, or not ?

    Steve Bellovin: You don't need a really long key for lower level
    things, because these are not confidentially keys or even really long
    term keys

    Geoff: is 1 year near or long term?

    Steve: 1 year and 1024 bits is about right for today, and you may want
    to go a bit shorter. This is not an S/MIME certificate and the
    considerations are somewhat different.

    Joe Abley: If SHA-1 is not advisable for today, what happens when
    SHA-256 is no longer advisable?

    Steve Kent: That's a fair question, PKIX is working on mechanisms to
    make it easier to do transitions. The security area is looking at
    migrating to different hash functions over time.

    Illjitsch van Beijnum: Is uncomfortable that only LIR may do this,
    because that means hard-coding the IANA  / LIR structure into this
    mechanism and we have to choose between this structure and a complete
    lack of security. We should not hard-code this structure.

    Geoff: there is a different between standards activity and its
    deployment. This draft does not specify the trust structure or the
    players. It nominates a PKIX certificate profile that could be used in
    private context just as easily in a public hierarchy context.

    Illjitsch: So can I construct my own view of security

    Geoff: You can configure you own trust anchors. This is a profile for
    certificate contents, not a Certificate Practice Statement.

    [return to presentation]

    [comments following the presentation]

    Sandy Murphy: this is a routing WG, but there are a lot of details
    about PKIX. Does the draft need an overview section in the beginning?

    Sam Weiler: I found it a bit hard to get my head around the drafts.
    Would like to see a much longer overview and introduction section.

    Sam Weiler: If I understood the draft correctly, this is not useful for
    P2P certification?

    Geoff: The profile does not say who trust anchors are, and it may be
    used in a peer-to-peer context. However the certificate profile
    encompasses resource sub-delegation.

    Sam Weiler: Should be clear that this only satisfies the hierarchical
    use case.

    Geoff: I don't understand the utility of resource use with no visible
    form of trust.

    Steve Kent: This topic issue hinges on the concept of "trust". In PKI
    trust is not magically imbued only to certification authorities. Indeed
    trust is never imbued to certification authorities. In PKIs trust is a
    decision by relying parties, who choose which certification authorities
    they are willing to trust by making those certification authorities
    trust anchors. Each relying party gets to choose which CA they are
    willing to trust, and this has no dependency on the certificate
    profile. Every ISP can choose which CA it wishes to adopt as trust
    anchors. This is a common occurrence, and the characterization is
    clearly evident if one is willing to read the PKIX standards.

    Sandy: Question not directed at who you could trust, but what
    information you could trust them to attest to. Would the certificates
    give the ability to trust people saying "I trust someone to give me
    this information no matter where he got it from".

    Steve: yes, I did answer that question. PKIX structures allow precisely
    that. The 3379 extensions encompass additional information under the
    control of the relying party. You could configure a trust reliance in
    any manner of your choosing.

    George Michaelson: But if you change the trust anchor surely the crypto
    on the certificate fails?

    Steve: Yes, but that's only where trust anchors are certificates. Don't
    forget that trust anchors are not certificates.

    Jeff Schiller: Disagree. Getting the trust anchors right and getting
    the business aspects right are more important than people care to think
    about. We are falling into the "technology trap" without thinking it
    through. In routing, players in the middle affect traffic, and creating
    centralized functions is an asymmetric function in a business sense.
    This does not lead to customer friendly models. The RIRs can't really
    "revoke" an address right now. Within this model, the RIR will be able
    to revoke the certificate, and as a consequence you will be
    disconnected from the network until the dispute is resolved. This is
    not a good idea. The ISP is a better place to put this trust. There is
    choice.

    Stefan Santesson: In practical life, root (CA) configuration is a local
    matter, undertaken by the relying party. Your need to have different
    stores for roots for different purposes. You can actually configure
    information with a root key in your database to tell local applications
    what to use it for. You cannot assume that PKI and X.509 solve it for
    you.

    Steve Kent: Jeff (Schiller) made interesting observations but missed
    some points. We are trying to capture the existing structure for the
    management of this resource. The asymmetry is a fact of life. You
    cannot go to another ISP, if you got your addresses from the ISP who
    was our provider. Jeff's example is not illustrative of the general
    situation with addresses and provider-based address distribution
    structures. Technical standards do allow different people to have
    different views of who they want to trust. It is the ISPs who decide
    where the traffic gets routed. When we are looking at trust anchors, we
    are looking at ISPs.

    Russ White: We can get deeply into the business models, but we have to
    be cautious about the specificity of the model, because the Internet is
    not the only internet in the world. This technology will be rolled out
    in other realms for other reasons.

    Jeff Schiller: We have to come up with some way of managing who the
    trust anchors are. Doing it exclusively for the RIRs as trust anchors
    is not a good idea. We are changing things, so we need to be careful.
    The more configurable we make them, the better off we will be.

2.2. Certificate Repository (George Michaelson)

    [comments on presentation]

    Stefan Santesson: Do you use SKI and AKI as names? You should note that
    RFC 3280 does not enforce that these fields match across issuer /
    subject chains.

    George: Yes, that's what we do. If there are critical issues then we
    can look at that, but it is working for us.

    Stefan Santesson: Does this model depend on SKI and AKI in the root
    certificate?

    George: No. This is not a dependency.

    Stefan Santesson: You need a name in the certificate?

    George: The name is CN="function of SKI" is one option, but if there is
    a name in the request it may be used as the Subject name, and there is
    always the Alt Subject name.

    Steve Kent: Your presentation combined building along with design, for
    instance trust anchors are not certificates. Therefore they are not
    self-signed certificates.

    George: Yes we should tighten language.

    Steve: Since trust anchors are locally managed, not being retrieved
    from repository, I found it confusing when reading.

    George: There is a set of bottom-up and top-down considerations when
    constructing validation paths.

    Steve: Keep a very clear separation between validation procedure and
    name model.

2.3 ROA Specification (Steve Kent)

    This agenda item was covered in the joint PKIX / SIDR session

2.4 Status Report on a trial implementation of Resource Certificates
    (George Michaelson)

    There was no time for this agenda item. The presentation material is
    included in the minutes of the Working Group meeting

3.1 Re-keying the TCP MD5 Option (Steve Bellovin)

3.2 A New TCP Authentication Option (Ron Bonica)

3.3 Key Selection for TCP Authentication (Brian Weiss)

3.4 The TCP Simple Authentication Option (Joe Touch)

    [comments on the TCP MD5 presentations]

    Steve Kent: We need to start with a requirements document

    Illjitsch van Beijnum: Not much harder to change BGP than it is to
    change TCP. BGP negotiates capabilities.

    Steve: not convinced that this is the way to go, BGP is supposed to be
    for reachability not key management.

    Illjitsch: Joe, what about when two ends configure different keys.

    Joe: Should not be a big issue.

    Illjitsch: requirements document is a good idea

    Alex Zinin: convinced we do need something on this line.

    Alex Zinin: Some of us have been working on this had a look and it
    would be interesting to compare the arguments. The motivation that you
    can have a mechanism that does not require and upgrade of software, do
    not know how relevant it is.

    Alex Zinin: Wanted to optimize this for hardware implementation as
    well. Different for real-time code, versus potential N times
    multiplier. Wonder if there are brute force attacks (for Steve's idea).

    Alex Zinin: operations and debugging... having keyid goes a long way
    helping to debug networks when something goes wrong.

    Steve: do not disagree, this is a way to get from here to there

    Lars Eggert: if changes to TCP are required to do this, it needs to be
    in a different area

_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www1.ietf.org/mailman/listinfo/sidr