2006-07-10 13:00
Geoff Huston & Sandy Murphy
Shane Kerr
A. SIDR Session
Administrivia
Certificate Discussion
Transport Security
B. Joint PKIX/SIDR Session
Address Space & As Number PKI
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).
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 Bellovin: 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 Kent: yes, I did answer that question. PKIX structures allow precisely that. The 3779 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.
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 Kent: 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 Kent: Keep a very clear separation between validation procedure and name model.
ROA Specification (Steve Kent)
[This agenda item was covered in the joint PKIX / SIDR session]
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]
Re-keying the TCP MD5 Option (Steve Bellovin)
A New TCP Authentication Option (Ron Bonica)
Key Selection for TCP Authentication (Brian Weiss)
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 Bellovin: 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 Touch: 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 Bellovin: 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 (TCPM).