[CGA-EXT] Draft CSI meeting minutes

Please find attached the minutes.
Send comments if you want to change something

------------------------------------------
Minutes CSI WG meeting
IETF72
------------------------------------------
MONDAY, July 28, 2008
1300-1500 Afternoon Session I
------------------------------------------

Proxy SeND PS
http://www.ietf.org/internet-drafts/draft-daley-csi-sndp-prob-00.txt
Jean Michel - 15 min

Marcelo: Do all the solutions address the complete problem space?

JMC: Yes

Suresh: Not really, all solutions together would do that but individual

solutions do not.

JMC: Wants to know if we should add references to potential solutions?

Marcelo: thinks the answer was yes last meeting

JMC: thought the answer was no

Dave: Thinks no. but it is ok to describe classes of solutions. But
there is no need to do so

Gabe: Is it OK to add multicast?

Dave: They are not used in ND

Marcelo: OK to adopt unless there is no objection.

(ADOPTED)

Proxy SeND
http://www3.tools.ietf.org/html/draft-krishnan-csi-proxy-send-00
Julien/Suresh -  15 min

This version updates previous version to generalize it for more than
proxy ND

Marcelo: What about if the owner himself delegates the authority
instead of trust anchor?

Suresh: That is another class of solutions

MArcelo: is not talking about ring signatues but each host individually
delegates authority

Suresh: The host does not know about the presence of the nd proxy at all.

Julien: It is simpler to do it this way

Marcelo: Easy way

Dave: Solution looks good. There is two cases here

Two trust models in ND proxy. This draft solves one but leaves the other
one out.

host->proxy->lan : The host can delegate the authority itself.

Show of hands.

(Seems to be about 15-20 hands)

Chairs thinks that this draft looks OK for adoption but will check on ML

Hash Agility for SeND
http://www3.tools.ietf.org/html/draft-kukec-csi-hash-threat-02
Sheng - 10 min

Marcelo - Is the option vulnerable to downgrading attacks
Sheng - yes
Marcelo - if the method for CGA and RSA signature is the same. then
downgrading is not possible
Sheng - this could be possible for just some messages
Julien - this approach does not work. You need to encode some how in the
address the hash function you want to use.
Marcelo - there is no way to avoid downgrade attacks in this way
Suresh - just make public that an algorithm is no longer secure.
Marcelo - I don't like this conclusion
Julien - define nCGA, not cryptographic (requiring certificates from other
parties), but with the algorithm encoded in the address.
Gabriel - go forward with the analysis part, but not with the solution.
Separate analysis and proposal.
Julien - we have to agree on the requirements wanted. Should be analysis and
requirments. All addresses must be CGAs (even the routers one's, because
then it cannot test for reachability.

Marcelo and Gab: Split the draft in two parts, one with the analysis and
another one with the recommendation of how to encode the hash function
in SeND. The first one is adopted and we need more discussion about the
second one.

(discussion to continue offline for the way to encode the hash function)

ECC support for SeND
http://www.ietf.org/proceedings/staging/draft-shen-csi-ecc-00.txt
Sean/Michaela - 20 min

An option is presented to support signature to include an ECC signature,
both in the SEND signature and in the CGA parameter data structure.

Marcelo: Parameter For sEND or for CGA?

Shen: for SEND

Gabriel. Is this aligned with the work made for TLS?
Sean. Yes
Gabriel. 256 is not too much for low capability devices? 160 may be fine
Sean. Yes.
Marcelo. Is any point in the CGA that says that the key is ECC?
Sean. Not in the parameter data structure format
Alberto. It is signaled in the DER-encoding of the public key.
Marcelo. Why is this approach backward compatible? Does not agree that
there is backward compatibility. If one  node supports ECC and the other
supports only RSA what happens. He wants multiple keys

Marcelo. People should read the document, and think how it should be manage
pki agility, that it is not obvious

Certificate Management
http://www.ietf.org/internet-drafts/draft-krishnan-cgaext-send-cert-eku-01.txt
Suresh - 20 min

Needed semantics to adapt certificates to SEND use. How is performed
Certificate revocation? CRL is bad idea if there are large numbers of
elements. Certificate extensions that must be implemented.

EKU field
to specify any of 3 purposes:
·        router
·        proxy
·        client (addr owner)
·        useful if not a CGA address, but still
wish to prove ownership of your address

items in
the cert
SAN - ip
addr
EKU
key usage
basic
constraints
auth info
access

ready for review by security directorate
nod from Tim Polk, to be continued off line

"Requirements for configuring Cryptographically
Generated Addresses (CGA) and overview on RA and DHCPv6-based approaches",
http://www.ietf.org/internet-drafts/draft-jiang-sendcgaext-cga-config-01.txt
Sheng - 10 min

Gabe: wants to know about "validate IID"

Sheng: mentions that it just avoids reserved IIDs

Jari: why the focus on configuring parameters? IS it useful and/or
required. You can just register the CGA with the dhcp server.

Marcelo: we are chartered to identify useful things to make cga and
dhcp work together. Not to identify parameters.

Jari: wants to narrow down the scope.

Dave: talks about Marcelo's question about proxy SEND. DHCP generates
the address and delegates the authority to the receiving node

CGA and SeND MIB
http://www.ietf.org/internet-drafts/draft-garcia-martinez-cgamib-00.txt
http://www.ietf.org/internet-drafts/draft-garcia-martinez-sendmib-00.txt
Alberto - 15 min

CGA mib

Jari: Are you creating an address by creating an entry in a MIB?

Alberto: Yes.

Where is the private key?

Alberto: That is a good point. Should only be used to manage

Dave: It can be used to request a remote node to generate a
public/private key pair

Jari: That is fine to do, but why?

Alberto: From central mgmt point.

Dave: Uses Sec=2 to request preceomputation or for algorithm change

Alberto: Is it valuable to use SNMP to configure CGA

Jari: is not convinced that this is necessary.

SEND mib

Gabe: wants to wait a little bit until all the other work that is
aiming to modify SEND is complete.

Thomas: thinks the work is premature. How much experience do we have
with SEND. Who will use this MIB. Even IP and TCP mibs on hosts are
not used. If we want to use this on devices like set top boxes, we
need buyin from some operator.

Gabe: we might have a better answer at a later time when the wg
progresses.

Dave: It is possible to split the draft into router config and host
config and we can then go forward with the router part.

Distributing a Symmetric Neighbor Discovery Key Using SEND"
http://tools.ietf.org/id/draft-xia-csi-symmetric-key-00.txt
Frank - 5 min

Gabe: 6lowpan has l2 security. Are there any residual threats?

JMC: Not clear from 6lowpan docs. Also can use this with netlmm.

Gabe: netlmm is also used on carrier based networks which may also
have l2 security

JMC: refers to the security analysis draft in 6lowpan which does
not have much info

Janos: How can we prevent a node from faking the router?

Suresh: The host still verifies the router certificate as usual.

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