[CGA-EXT] IETF 71 CSI meeting minutes

Hi,

these are the minutes for the CSI meeting at IETF71

If you have comments corrections additions, please let me know and we 
will update them

Regards, Gabriel and marcelo

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

---------------------------------------------------------------
_______________________________________________
CGA-EXT mailing list
CGA-EXT@ietf.org
https://www.ietf.org/mailman/listinfo/cga-ext