Subject: [Sidr] Agenda for SIDR WG meeting at IETF 66

From: Geoff Huston <[email-masked]>
Date: Tue, 04 Jul 2006 07:56:46 +1000

Secure Inter-Domain Routing WG (sidr)
IETF 66, Montreal

Session I - SIDR Meeting

Monday, July 10, 2006 1300-1500 (Afternoon Session I)
====================================================

CHAIR(s): Geoff Huston <[email-masked]>
           Sandra Murphy <[email-masked]>

AGENDA:

  1) Administriva                                             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

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

  3) Transport Security

     Rekeying 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"
     draft-bonica-tcp-auth-04.txt
     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"
     draft-weis-tcp-auth-auto-ks-01.txt
     http://www.ietf.org/internet-drafts/draft-weis-tcp-auth-auto-ks-01.txt

Session II - Joint Meeting with PKIX

MONDAY, July 10, 2006 1850-1950 (Room 513b)
===========================================

  4) Joint PKIX/SIDR Meeting

     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).

_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Jul 2006 11:08:15 +0200

>     http://www.ietf.org/internet-drafts/draft-weis-tcp-auth-auto- 

Three new drafts trying to improve on RFC 2385! There are some good  
ideas in there, but I see major problems.

draft-bonica-tcp-auth-04.txt:

    However, TCP implementations MAY omit TCP Options from the MAC
    calculation.  When implementation do so, they MUST set the T-bit in
    the TCP Enhanced Authentication Option.  See Section 9 of this
    document for details.

Huh? Why would this be necessary or useful? Seems to me this only  
adds unnecessary complexity.

Using identifiers to identify MAC keys seems like a good idea, but it  
doesn't preclude two sides from entering different keys, and it only  
adds more stuff that must be agreed upon. To avoid these problems, I  
suggest using a hash of the key as the key id. Such a hash would be  
too long to include in a TCP option, but I don't think this is too  
much of a problem: rather than include the key id in every segment,  
implementations can agree on the key that's used in-band.

draft-weis-tcp-auth-auto-ks-01.txt:

This draft can use some more spelling and grammar checking. I also  
find the draft hard to follow. I'm not sure whether this is because  
of my relative unfamiliarity with the matters discussed, the frequent  
references to things defined elsewhere or because of poor organization.

    Using an additional four TCP option bytes for a sequence number
    dedicated to the MAC option is required in order to satisfy the
    cryptographic requirement of unique nonces.  No other value in a TCP
    packet is guaranteed to be unique.  At first glance, the TCP  
Sequence
    Number would appear to be suitable.  However, the TCP Sequence  
Number
    can wrap, after which it increments back through the same sequence
    number space.

Yes, after transmitting 4 GB worth of data... TCP already has a  
window system that makes sure only part of the sequence space is  
acceptable at any given time so it would be relatively simple to look  
at the TCP sequence number as a 64 bit or even longer value and keep  
the upper bits in sync with the other side when the lower 32 bits  
wrap with no need to actually transmit the upper bits.

Is it worth all this complexity to avoid having to use the same  
actual MAC key for prolonged periods but rather use different MAC  
keys based on the same underlying key? In my not cryptographically  
trained opinion this is only the case when the MAC algorithm is  
significantly weaker than the encryption algorithm used to exchange  
new MAC keys. And _that_ should only be necessary when the encryption  
algorithm can't be used to generate a MAC or uses too much processing  
time.

draft-bellovin-keyroll2385-00.txt:

I have a big problem the notion of blindly switching to a new key at  
a predetermined time. If one side is unable to enter the key before  
that time, or one side enters the key incorrectly, the session will  
break at the moment that the switch to the new key happens. Since  
this happens some time _after_ both sides (are supposed to) have  
entered the new key, operators aren't actively monitoring the session  
at that moment, so there will be a delay before the problem can be  
corrected.

I suggedsted this alternative approach on the north american network  
operators mailinglist:

If you want benefits when only one end is upgraded, your mechanism  
for concurrent keys could be used like this:

- the upgraded side installs the new key
- the upgraded side keeps using the old key
- the non-upgraded side installs the new key
- the upgraded side detects that the other side uses the new key and  
switches over itself
- the old key is removed from the upgraded side

This way, it all goes down when the non-upgraded side installs the  
key: they can immediately see the problem if there is some kind of  
issue with the key (for instance someone entered it incorrectly).

It still makes sense to add stuff that allows both ends to manage the  
key rollover when they're both upgraded (by adding a new BGP message  
to coordinate all of this in-band), since in that case something like  
the above won't work. I think something like this would work well:

- announce key rollover capability at session connect
- when a new key is configured, send a hash of it to the other side
- other side doesn't have the key yet so says "reject"
- other side is also configured with the new key, sends a hash
- first side sees hashes match, starts sending with the new key and  
says "accept"

Finally, as someone who works with BGP with MD5 passwords in  
practice, I can tell you that operators in general don't even think  
about changing keys. Yes, coordinating changing a key on both sides  
at the same time is a pain, but coordinating changing a key PERIOD is  
almost as big a pain because even ASes that aren't very big can  
easily have 100 peers or more and only the middle sized ones are easy  
to work with, the smaller ones barely have a clue and the larger ones  
have huge bureaucratic NOCs where it's hard to find the right person.  
And of course everything stretches across timezones and there are  
often language barriers. Exchanging the key securely is also a big  
problem. Making key rollover easier isn't going to change all that  
much here, and there is no perception of immediacy anyway.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Jul 2006 13:56:19 +0300 (EEST)

On Tue, 4 Jul 2006, Iljitsch van Beijnum wrote:
> Finally, as someone who works with BGP with MD5 passwords in practice, I can 
> tell you that operators in general don't even think about changing keys. Yes, 
> coordinating changing a key on both sides at the same time is a pain, but 
> coordinating changing a key PERIOD is almost as big a pain because even ASes 
> that aren't very big can easily have 100 peers or more and only the middle 
> sized ones are easy to work with, the smaller ones barely have a clue and the 
> larger ones have huge bureaucratic NOCs where it's hard to find the right 
> person. And of course everything stretches across timezones and there are 
> often language barriers. Exchanging the key securely is also a big problem. 
> Making key rollover easier isn't going to change all that much here, and 
> there is no perception of immediacy anyway.

I can agree with this statement.  There is very little need to change 
MD5 keys once set.  I'd be interested in hearing the reasons why other 
operators might consider this critical.

Personally, I would like to avoid the BGP transport security issues 
for now.  Those are a distraction from the real work this WG is 
chartered to do.  Before we have at least an inkling about the 
inter-domain routing security framework which we are chartered to 
produce, all of this seems premature at best.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 5 Jul 2006 10:09:29 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Iljitsch van Beijnum" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 04, 2006 11:08 AM
Subject: [Sidr] Transport security

> On 3-jul-2006, at 23:56, Geoff Huston wrote:
<big snip>

> much here, and there is no perception of immediacy anyway.
True, but working with enterprises teaches me that noone takes security
seriously until they have felt sufficient pain, millions of euros or dollars.

Not long ago, noone used MD5 for BGP, suddenly they were, I understand because
of an incident (at a large European IX?).  When there is the next incident, we
should have the technology ready, and it is not difficult.  All we need is the
ability to invoke key generation dynamically, with an exchange of pseudo-random
numbers etc leading to a new key pair, so that all the operator sees is two
knobs, one saying generate key change now, and the other saying accept key
change request from peer; the rest is protocol.

Tom Petch
.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Jul 2006 15:12:10 +0200

On 5-jul-2006, at 10:09, Tom Petch wrote:

>> Making key rollover easier isn't going to change all that

> seriously until they have felt sufficient pain, millions of euros  

:-)

> of an incident (at a large European IX?).

"Noone" is overstating it a bit, but yes, suddenly very many wanted  
to do MD5 because some guy claimed he had found a big vulnerability  
in TCP so he could reset TCP sessions with only a few packets. Turned  
out that the "vulnerability" in question assumes very large TCP  
windows: only if someone uses the biggest TCP window allowed by RFC  
1323 (nearly a gigabyte) and IP addresses and port numbers are known  
to the attacker, the attacker can fake an in-window TCP reset within  
about four tries. Since no other application of TCP is both of  
internet-wide importance and keeps a single session around for a  
significant amount of time, this was assumed to be a bad thing for  
routers running BGP. The fact that no router vendors even use the RFC  
1323 window scale option in the first place apparently got lost in  
the fracas.

For more details, see:
http://www.bgpexpert.com/article.php?id=89
http://www.bgpexpert.com/article.php?id=90
http://www.bgpexpert.com/article.php?id=93

But it was good advertising for the MD5 option.  (-:

> When there is the next incident, we
> should have the technology ready, and it is not difficult.

I agree. I was just trying to deflate expectations of operator  
deployment to reasonable levels.

One important question is whether all of this makes sense in the  
first place, though, given the existance of IPsec.

> All we need is the
> change request from peer;

Wouldn't this perpetuate a key compromise?

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 5 Jul 2006 14:38:13 +0200

----- Original Message -----
From: "Iljitsch van Beijnum" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 05, 2006 3:12 PM
Subject: Re: [Sidr] Transport security

<snip>

> Wouldn't this perpetuate a key compromise?

Yes, but then you change the key; the security credential, be it pre-shared key,
private/public key pair etc, is what matters and that is what you must keep
secret.   You only ever use it, along with other material, some predictable,
some not, to generate keying material for a session, keying material which you
then use as MAC key, encryption key etc  At regular intervals, or when you
suspect your keying material has been compromised, generate fresh keying
material using your security credential and different other material.  (PKI does
of course insist on refreshing the security credential as well, but I see that
as a longer timescale, like years).

draft-clancy-emu-eap-shared-secret-01.txt is an example of key derivation in the
context of EAP (which lacks, AFAIK, the ability to regenerate keying material
later).  TLS is another example of key derivation and also has the capacity for
current and pending Cipher Specs which can be changed at will.

I would regard these building bricks as the current state of security, in no way
leading edge.

Tom Petch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Jul 2006 21:27:36 +0200

> material using your security credential and different other material.

I know this is best practice, and RFC 2385 as it is today doesn't  
support this to any useful degree, but I wonder whether any effort to  
rectify this situation is worth the effort in practice. The way I see  
it, the easiest way to compromise such a key is to gain control of  
the router in question and read it from the configuration. This is  
MUCH easier than gaining access to the communication channel between  
two routers, intercept packets and then do a collision attack on MD5  
(or, if MD5 is really dead at some point (now?)), a stronger  
algorithm. Don't forget that in many cases, routers are located at  
shared sites so physical security isn't always as good as it could be.

And when someone has the key, they mostly get to reset BGP sessions.  
Injecting bad information is MUCH more difficult, unless there are  
additional attack vectors such as access to a shared LAN. In any  
event, such attacks will generally be discovered very quickly so in  
practice this is not a very rewarding exercise for the attacker.

Of course there can be situations where a higher level of security is  
warranted, but why not simply use IPsec in those cases?

> I would regard these building bricks as the current state of  
> security, in no way leading edge.

Well, how much security do we need and/or can we stand?

To avoid misunderstandings: I think it would be useful to improve  
upon RFC 2385 for a variety of reasons:

- MD5 is a sinking ship
- adding MD5 for the first time and rolling over keys is too  
difficult today
- it's too easy to make mistakes and configure non-matching keys at  
both ends

But we need to be careful in drawing the line; reinventing TLS or  
IPsec or big chunks of those is a waste of time both because it's a  
duplication of effort and because the way operators work and the  
(perceived) level of risk make this an exercise in futility.

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 11 Jul 2006 09:43:08 +0200

EKR has sent a paper on this to bts and tcpm lists.  Joe Touch has suggested
that the right place to discuss this is bts.

Tom Petch

----- Original Message -----
From: "Iljitsch van Beijnum" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 05, 2006 9:27 PM
Subject: Re: [Sidr] Transport security

<snip>

---

From: Geoff Huston <[email-masked]>
Date: Fri, 21 Jul 2006 06:58:53 +1000

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

  - 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)

    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)

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