--------------------------------------------------------------- Minutes CSI WG @ IETF 71 MONDAY, March 10, 2008 1740-1950 --------------------------------------------------------------- Chairs: Gabriel Montenegro Marcelo Bagnulo Scribe: Iljitsch van Beijnum ------------------------------- Minutes: ------------------------------- SeND charter related items ------------------------------- Proxy SND Problem Statement draft-daley-send-spnd-prob-02 JM Combes SeND/ND proxy SeND: two parts: RS/RA security, NS/NA security Two mechanisms: certificate based and CGA based Ifdentified scenarios IPv6 mobile nodes, two nodes need to be able to advertise a same address, i.e. daad, neighbor resolution, impact on ns/na messages Potential approaches - Trusted ND proxy - Relax send policy - Authorization delegation - Generation of certificates - Crypto based - Ring group signatures - Point to point link model Dave Thaler (DT): Two very different approaches - per address certificates, get it from who generated the address - other model the proxy is trusted like a router is trusted for anything that comes off-subnet both are mentioned briefly, worthwhile that these are different approaches Suresh Krishnan (SK) Specific case of ND proxy: you don't know that it exists so it's hard but you're right, two cases possible, but second case more probable except maybe in a home network DT: if you have configuration for the host, if you have a key for the router then you can also have a key for the proxy, not as nice, but it's an alternative with different tradeoffs Marcelo Bagnulo (MB): We want text about this for the problem statement Cont. presentation Generalization case where n nodes advertise the same addres: anycast, PMIPv6 case (i.e. ingress MAG's LLA) Recognize two issues even if you're not going to address them DT: Anycast is important, multicast isn't, because anycast is like a normal address so it's important for the problem statement, multicast doesn't belong in there Good to have high level recognition of the issues even if we don't implement it, documenting is good MB: read document, see on the mailinglist if it's in good shape Gabriel Montenegro (GM): one more spin of the draft ------------------------------- Symbiotic' relationship for SeND proxy draft-haddad-cgaext-symbiotic-sendproxy-00 Wassim Haddad Suresh will present Wassim's solution Secure neighbor discovery proxiyng using symbiotic relationship With this approach you use the certificate of the node that will proxy for you This is a very spefic case of a ring signature What you're trying to do is take the relationship with other node to prove that you're authorized to proxy for the other node DT: Can you say how you communicate the relevant info to the proxy without anyone seeing this? answer: Encrypt with public key of the proxy DT: identity is known to the router and the node this wouldn't be appropriate for a topology where you proxy in downstream direction a host that's upstream applicable some scenarios not all ------------------------------- Proxying Secure Neighbor Discovery Messages draft-krishnan-cgaext-proxy-send-00.txt S. Krishnan Proxy becomes part of the trusted infrastructure RFC4389 changes link addresses SeND assumes the owner of the address is the person advertising Doesn't have to be true, break this assumption and you have possibilities If you have a proxy on a subnet give a certificate that covers the whole subnet replace mac address on the fly DT: why keep the original contents? SK: only way to get from you to me is through him DT: when he's a bridge original contents is no good, if he's not a bridge it's not useful either SK: can check if the proxy only changed the mac address Iljitsch van Beijnum (IB): so data traffic goes through the proxy? you shouldn't want that at layer 2, make it a router DT: SeND proxy is useful if you have MIPv6 or if you need to both subnets together because you can't get more IP subnets Jari Arkko (JA): if you do this, what needs to be changed on hosts that go into the proxy? SK: all the nodes have to change MB: if you do that, how do you make hash2 work? modifier can't be assigned as a hash function because of the SEC. modifier is not the right place for this, need new public or whole new profile DT: my request: pictures are good last presentation and this one have different trust models, both good but for different use cases, they're complimentary, not competitive Question: any reason why you've chosen subnet granularity rather than individual addresses? can imagine hosts delegating authorization to node SK: idea is to hide multiple link thing from the nodes DT: ND proxy has two sides: to router and to leaf the trust models are very different. leafs know it's there on the other side the proxy is seen as a host without things on the outside being aware of it ------------------------------- Certificate profiles and Management draft-krishnan-cgaext-send-cert-eku-00.txt S. Krishnan, K. Ahmed, A. Kukec - 15 min Need to narrow down what certficates can be used for, need to be backward compatible Three new purposes: router, proxy, client Open issues: how do you revoke certificates? isn't done now. JM: want to make this compatible with sidr work (their certificates) MB: this is what we're chartered to do in this area if people are working on this let us know or start working ------------------------------- DHCPv6 Delegation of Certificates Option draft-popoviciu-dhc-certificate-opt-01.txt C. Popoviciu, R. Droms, E. Levy-Abegnoli Question: slide two organization, don't need certificate here the trust anchor would be the requesting router DT: two models SK: first thing: the subject of the cert is the DUID Answer: if only a pointer is returned it can be anything in the second case the DUID SK: but the DUID can be anything, how does the SEND host what the DUID is? Answer: but it's signed by the trust anchor, the name doesn't really matter SK: first messages are all the clear: how do you stop someone who sees the messages form requesting the prefix? Answer: there is some manual work involved to avoid this Question: what about revocation? Answer: sort of covered in the draft through some dhcp message, Ralph? what's the dhcp message when you want to revoke a prefix? force renew? Ralph Droms (RD): reconfigure cause the requesting router to contact the delegating router DT: how do you get it to the host? RD: you don't DT: so you have to wait for it to expire MB: we are chartered for certificate provisioning, this is one approach, read the draft then we can figure out what to do with it ------------------------------- Hash Threat Analysis for SeND and Send Crypto Agility A. Kukec, S. Jiang, S. Krishnan Researchers showed attacks against md and pkix cert with md5 signature, sha-1 attacks not (yet) feasible but could be in the future So change hash algorithms or enable hash agility Impact on SeND Conclusion cga-based protocols including send are not affected by collision attacks For routers attractive attack is against middle certificates, one cert and you can launch attacks on multiple routers Bottom line: no new vulneratibilities / input hard to predict so in practice little concern, however, attacks only get better over time Moving to sha-256 only provides temporary relief, really need hash function agility. But then still vulnerable to bidding down attacks MB: We need text for this. Ana? are you going to write a draft? Ana: yes MB: we need two things, this analysis and then how to put in hash agility. Does it make sense to put this in the update of rfc 3971, make sense jari? Jari Arkko (JA): yes GM: none of these attacks are currently doable some people want networks to be unspoofable ------------------------------- Update for RFC3971: support in SEND for non-CGA addresses E. Levy-Abegnoli Non-cga addresses in SeND Proposal to update 3971 to allow non-cga addresses Why do we want this? Some nodes really like hand crafted addresses CGA may not be considered secure enough Proving address ownership may not be good enough, want to authorize an address. IPR on cga may be a problem JMC: why is it better to use a certificate than cga addresses? Eric Levy (EL): not saying it's easier, sometimes you want to authorize an address, can't do that with cga JMC: do we need that? EL: yes, sometimes you only want to talk to authorized people JMC: use IPSec EL: sometimes I don't want the system to generate an address for me Question: cga requires changing key from time to time, sometimes you don't want to do that. and I like ::1 JA: not sure what you tried to do with this. if you nail down the address you can't move supports servers and routers, not sure how it supports hosts that move around SK: can't tell when an address is a cga address JA: host knows, other side doesn't SK: need to specify that either cga or new option is present now it's a circular definition DT: it's clear for senders, receivers is a different thing EL: it's easier to comment on the complete text GM: wondering where this text needs to go MB: updating the base spec is critical two comments: need to handle process very carefully second:timing, this is the last thing we're going to do JA: it's clear that we messed up in the first version of the rfc don't think we are at the stage that we know where the text goes ------------------------------- Public key algortihm agility in SeND S. Shuo MB will present for Sean We want to use ECC because they use shorter keys Good for constrained devices What do we need to do? change cga spec, it's all rsa now Need to look at backward compatibility in that case Probably want to have a level of indirection Sean is interested in working on this, if others, let me know ---------------------------------------------------------------