--------------------------------------------------------------------------------------------- CSI WG meeting minutes MONDAY, March 23, 2009 1740-1940 Afternoon Session III --------------------------------------------------------------------------------------------- Minutes from Gabriel Montenegro and jabber from Roque Gagliano --------------------------------------------------------------------------------------------- Summary: The Proxy Send problem statement will go soon to the IESG, the hash analysis draft is waiting on the PK agility draft. We had two official presentations (as well as one on an implementation). The PK agility in SeND draft is adding other PK families other than the current only option for SeND: RSA. This brings in the possibility for ECC (e.g., for limited capacity nodes), but adds complexity in that there are now several possible combinations as to what families are supported by each node. Further complications arise if one allows several families to generate one single CGA. It might make sense to simplify by assuming that a single CGA address corresponds to a single principal (i.e., a single cert for a given family). This would avoid the larger compound proposals. Steve Kent brought up the point that we don't have any deployment so we have the luxury of not having a backwards compatibility requirement. We could just change the RSA option to a universal option and allow non-RSA instead. This work needs simplification. The certificate profile for SeND has been re-written to use RPKI (being used to secure routing). RPKI has been modified to allow the use of EKU's, of which we'll need at least the "router", "proxy" and "client" EKU's and perhaps a "notary" one as well (part of the previous presentation, more complexity). There is still no specification as to how to provision these certs, however. We adopted this as a WG document (to be confirmed on the mailing list). --------------------------------------------------------------------------------------------- WG document status Update * hash analysis - waiting on PK agility * Proxy Send PS - about to go to IESG * PK agility, certificate format, DHCP stuff: all ongoing --------------------------------------------------------------------------------------------- - Public Key agility in SeND http://www.ietf.org/internet-drafts/draft-cheneau-cga-pk-agility-00.txt 20 min - Michaela Vanderveen Presentation Work done, try to cathegorize routers and hosts by their ability to support crypto algorithms Router can: have certs (to act as routers and have a CGA). Router can have a signature and veritication capability Hosts normally handle CGAs (marcelo) there are multiple situations CGA that have both an RSA an other keys or a CGA that has just other kind of keys we have a wide variety of type of algorithms supported in hosts what do the WG opinion? should we support all the algorithms? (Jean Michel Combes) we should consider a basic set RSA CGA (marcelo) the point of being here is that some devices wants shorter keys (Jean Michel Combes JMC) you need to consider back-compatibility (Stephen Kent) The docs are not implemented, you have flexibility This is not IPSEC. There is an asymmetric, hosts (mobile devices) will be more likely to use less CPU, but RSA is asymmetric (marcelo) what about Neigh. Solicitation? In this case a host will need to sign the messages. (SK) yes, that is correct (marcelo) You other statement is that in this scenario we do not need to worry abour back-compatibiliy as has not be implemented (SK) yes. "time passed we are thinking thing differently, we want to change" you need to be able to do this. Original doc. where RSA specifics. (presentation continues) We need 2 things to get agility: CGA update & SEND update CGA Update: New CGA parameter data structure extention. Old: CGA generating multiple keys went through packet description for support of multiple keys open to discussion if the extension should be located here (marcelo) two things to discuss. Public key agility will work in CGA today, the only problem is that is says that SHOULD be RSA. What this extensions allow is to have MULTIPLE Public keys. Two questions: how to support multiple algorithms and how to support multiple public keys. (francis dupont) you only need to extend the sec parameter "new things inside the CGA" (marcelo) why do you believe that there attacks? (francis) if you have two public keys and you break the weakest one, you break the all thing. (francis) I do not see the case that more than one key is usefull (marcelo) a router with multiple PK algorithm support to communicate with different hosts. we can use the same CGA using different algorithms you do not need another address. (francis) disagree. you should not have different level of security. (marcelo) it is not about level of security but different algorithms (SK) The motivation to change to a different algorithms is because it normally saves battery power in mobile devices. (francis) good to be able to switch algorithms but not to use different algorithms at the same time. (marcelo) the problem is that if you change the key, you change the address. once you change the address, you need to do new ND (francis) imagine SEND and CGA in public internet. Deployment will come when security is important. (Sean)first concern, how can I say that one algorithm is weaker than other?. (marcelo) the problem that francis is describing is that you have multiple instance of SEND, where is one instance do not work you can try the other one and try to attack the weaker part (francis) maybe describing, first try this king of algorithm with this kind of hash... second, etc. (Michaela) too many combinations (gabriel) There may be a host that implement "instance A" and another next to that one that implement "A and B" and you see it as two hosts. Also, there should be recommendations about how to select from A to B. (francis) It must be a different address, to show that it is a different "thing" if it is a property of the CGA you do not need to negotiate. (marcelo) suppose that your application cannot do SEND with the algorithm....you need to come back to ND plain (JARI) we are not moving information from ND to other layers that would be bad. (michaela - presenter) there is no way to bind one address to more than one key (gabriel) there is no limit on the numbe of keys? (michaela) we can change that to the next version. should we limit the length of the packet or the number of keys? (presentation continues) CGA Update as per RFC3972 Classification of Nodes for Algorithm Negotiation (H1 and H2 hosts) (H3 and H4) Routers classification: R1 and R2 R3 and R4 for next version SEND Update: optional router assisted BD mechanism New/Modified ND options: Supported Signature Algorithm Oprions: indicates which signature algorithm is available. update RSA Signature Option to a new Option: Universal Signature Option Supported Signature Algorithm Options (SSA) (marcelo) what is the signature type? (michaela) we will assign bits 3-7 to RSA, etc.... (Stephen kent) Signature Algorithm Type and the specific algorithm may not be the same as in ECC you need to know the curve that it is used. Small number widely used today, that may change in time. (michaela) we have 5 bits, we believe they are enough (presentation continues) Universal Signature Option: uses the Reserved filed in the RSA Signature Option to support multiple signatures. () is this the same type or a different? if it is the same type what about the back-compatibility? (michaela) it will thing that it is RSA and if it is not, it will fail we are open to suggestions negotiation process two cases shown homogenus and heteregeneous netowork (dave thaler) two question. Any reason this two phases not be done in paralel? (michaela) no reason (dave thaler) if B do not want to respond to A there is not need to enter phase 2. (michaela) correct. Just ilustration examples not requirement (dave) if this fails you go back to plain ND? answer yes (dave) the r flag is not necessarily? (michaela) not necessary we are willing to take it out (presentation continues) Adding a router the "notary function" (question in the floor) is this a sign message inside another signed message? What about the MTU? (michaela) we think that it needs to be shorter that the MTU :-) (floor) it may be difficult in some cases, please do the maths. (jary) same order of size I believe it can work from an MTU perspective (dave thaler) any threat analysis done? (jari) do not mather you can send other packets. (dave thaler) need security consideration section (question floor) I would not use the router as notary (Jean Michel Combes JMC) what about DAD? Address Duplication detection? (michaela) you need a valid address. (marcelo) the draft a great work, have analyze a super set of support do we want to reduce the scope of things we want to support? question to the floor...or the jabber room (francis) simple proposition please rename security parameter and number (dave thaler) simpler is better unless there is a real need for things like the "r" flag lets eliminate it and try to identify what else to simplify (marcelo) what about the kind of nodes? issue moved to the list and next meeting (ups- additional comment form Gabriel) addresses come and go, and have more addresses can simplify things giving that we do not have much deployment can we call the previous SEND docs as an "experiment"? --------------------------------------------------------------------------------------------- - Certificate profile for SeND http://www.ietf.org/internet-drafts/draft-krishnan-cgaext-send-cert-eku-03.txt 20 min - Suresh Presentation SEND uses X509 certs but not particular info on the Certs. desition to use SIDR profile and not continue with the work there was a minor issue that SIDR Certs did not allowed EKU that was changed and the work is much lower now EKU still needs to be specified. in CSI Three EKU: Router/Proxy/Client (dave thaler) wonder if there is a fourth, as a notary incremental deployment Open issues: How to authorize a particular router to be the default router? backward compatibility CRL transport for SEND (marcelo) the certificate must contain the prefixes that you use for address autoconf. not the ones you are allow to route. (jari) the problem is the wording. authorize to advertise is clear, what about authorize to route? (stephen kent) RPKI is authorizing them to originate routes from a particular ASN, not looking for local problems to get to a destination. (dave thaler) the authorization to route any route even the default should be explicit and can be say that way in the doc. (marcelo) SEND does not currently make this distinction and the explicit mechanism is what is in place today. (jari) agree with marcelo. (greg daley) problem with CRL, the only path to verify the CRL is through the router. Most CRL are large. we may want customer to do verification techniques but not in SEND (marcelo) does anybody think we need to make a distinction that a router is a default router? (gabriel) I rather say default router, but nothing more about other routes. Other documents dealing with this issue. (suresh) does not go far enough thing about 2191 (gabriel) unless otherwise specified you can assume that is a default router. (deve thaler) it is not only the default router but also any other route, there is no reason for a distinshment. The collection of specific = default (gabriel) what about the size of the CRL? a well design sistem should not have large CRLs as certificate should expire (greg) if we can get a trusted part we can offload the work (stephen kent) you need to get the network to route you to get the CRL CRL tells you when the next one will be issued when you deny the possibility to get the CRL you get in a bizarre situation (suresh) this break backward compatibility....is this an issue? (same question as before). (marcelo) propossal to support only CRL and not present SEND prefix validation. consensus. (marcelo) is the document ready for adoption? 8 in favor no opossition. (Jean Michael) How to provisioning of certificates? there was something about DHCP... (marcelo) now, only the profile, if someone wants to talk about and write about DHCP great (roque) what we are working at this moment is not in that stage, maybe when facing secure BGP and needs to issue certiicates to routers it may make sense to use same mechanism. --------------------------------------------------------------------------------------------- - A SeND Implementation report 10 min - Sean SEND SGA and DHCPv6 - student work implementation based in linux 2.6.24 kernel Router based in Quagga and dibbler as DHCP server Question for Sean, what's the licence of the new part of the software that we be written ? Are some of the presented thing already available ? GPL licence will be a web page to download the sources ---------------------------------------------------------------------------------------------