Subject: [CGA-EXT] Comments on draft-dong-esp-sa-cga-00

From: Sean Shen <[email-masked]>
Date: Wed, 03 Jun 2009 11:13:15 +0800

Hi, Zhang Dong,
I read draft-dong-esp-sa-cga-00 and find it gives a interesting idea. I have
a few questions and comments:
 
#1.
The incentive of the draft is to provide a alternate way to negotiate esp
sa, it will be helpful if more merits of this new approach can be discussed,
especially compared with IKEv2.
 
#2. 
I noticed that IKE and IKEv2 were used alternately in the draft, and some
sentense like "CGA-SA MAY be used in all the scenarios where IKE is
available. The usage scenarios of IKE are stated in [RFC4306]." is
confusing. It will be good if you clarify which one you are talking about or
both.
 
#3
The draft did not tell what contents will be protected by CGA signature.
Also I go to check section 3.3 (CGA Signature) of
draft-dong-savi-cga-header-01, I did not find the signature coverage either.
Maybe I missed something? 

#4
I notice that Cert is optional in message exchange since they are in
brackets. Does it mean that Certs are not REQUIRED in your trust model? 
When [CERT] is carried, is it the chain of all certificates on trust path or
just a single Cert? 
Also I did not see which option will carry Cert.  

#5
What if the message size exceed IPv6 MTU? For example, when carrying
certificate.  

Best,
 
Sean

---

From: ZhangDong <[email-masked]>
Date: Fri, 05 Jun 2009 14:53:15 +0800

Hi Sean,

Thank you for your questions and comments.
Please see below.

>  especially compared with IKEv2.
[Dong] Ok, I will consider it and add this part in the following version.
   
>  confusing. It will be good if you clarify which one you are talking 
> about or both.
[Dong] Yes, this problem will be revised.

>  Maybe I missed something? 
[Dong] Hmm, in the draft, there is no statement about this question. IMHO, signature coverage may be the hole packet. Is that ok?

>  Also I did not see which option will carry Cert.  
[Dong] Yes, the CERT is not required in my approach. I just intend to put it here for future use. But how to use the CERT may need further consideration.

>  What if the message size exceed IPv6 MTU? For example, when carrying
[Dong] The CERT is a reservation temporarily. Then I feel that this problem could not be a big deal. Right?

Thanks.
Best Regards.

Dong Zhang
Huaweisymantec Technologies Co., Ltd

---

From: Sean Shen <[email-masked]>
Date: Fri, 05 Jun 2009 15:37:20 +0800

Hi, Zhang Dong,
Please check in lines:

> >  #1.
> >  The incentive of the draft is to provide a alternate way 
> to negotiate 
> > esp  sa, it will be helpful if more merits of this new 
> approach can be 
> > discussed,  especially compared with IKEv2.
> >  I noticed that IKE and IKEv2 were used alternately in the 
> draft, and 
> > some  sentense like "CGA-SA MAY be used in all the 
> scenarios where IKE 
> > is  available. The usage scenarios of IKE are stated in 
> [RFC4306]." is  
> > draft-dong-savi-cga-header-01, I did not find the signature 
> coverage 
> > either.
> [Dong] Hmm, in the draft, there is no statement about this 
> question. IMHO, signature coverage may be the hole packet. Is that ok?
[Sean] Depend on what you want to protoect and different scenarios, for a
end-to-end scenario (which I imagin is what's this proposal might be good
at), you may want to make sure to leave out fields which could be modified
during transportation.

> >  When [CERT] is carried, is it the chain of all 
> certificates on trust 
> > path or  just a single Cert?
> [Dong] Yes, the CERT is not required in my approach. I just 
> intend to put it here for future use. But how to use the CERT 
> may need further consideration.
[Sean] I see, I understand this is a initial version and there will be more
updates. Since CGA's pub/priv keys are the only authentication choice for
this SA negotiation mechanism, whether CERT is required in the trust model
should be carefully considered and discussed.

> [Dong] The CERT is a reservation temporarily. Then I feel 
> that this problem could not be a big deal. Right?
[Sean] If CERT is required in message "I" and "R", MTU should be addressed.
Of course, there should be ways to mitigate the problem, for example, use
"hash and url" format.

Best,

Sean

---

From: Ana Kukec <[email-masked]>
Date: Fri, 05 Jun 2009 10:48:57 +0200

Hi Zhang Dong,

> [Dong] Ok, I will consider it and add this part in the following version.

What you are suggesting is an opportunistic approach. If CERTS are not 
used, how do you plan to solve the initial leap of faith? If CERTS are 
used, what is the advantage in using your approach?

> [Dong] Yes, this problem will be revised.

In case of IKEv2, it would be good to replace links to RFC2401 with RFC4301.

Regarding RFC4301 and SPs, i fail to understand why did you omit the 
traffic selector payload from the negotiation? How will the traffic 
selector negotiation be done?

Ana

---

From: ZhangDong <[email-masked]>
Date: Wed, 10 Jun 2009 10:55:36 +0800

Hi Ana,

Thank you for your comments.
I am sorry for the late response. I was absent several days.

>  ZhangDong wrote:
>  >>  #1.
>  >>  The incentive of the draft is to provide a alternate way to 
> negotiate 
>  >> esp

The current 00 version of draft provide a rough proposal of negotiating SA via CGA, more details will be added. Cert is root of trust in CGA usage and is necessary in trust model. At the same time, we will consider various ways to mitigate packet size problem. Would you mind giving some advices?
 
>  >>  #2. 
>  >>  I noticed that IKE and IKEv2 were used alternately in the draft, 
> and 
>  >> some

Yes, will take care of this problem. Currently, the document just shows an idea of this area in order to find out whether anybody is interested in it. The following drafts will be more perfect.
Thanks again for your supplements.

Dong Zhang

---

From: Ana Kukec <[email-masked]>
Date: Wed, 10 Jun 2009 16:00:59 +0200

> The current 00 version of draft provide a rough proposal of negotiating SA via CGA, more details will be added. Cert is root of trust in CGA usage and is necessary in trust model. At the same time,…

Well, you could go for the usage of the Hash and URL CERT. In case of 
CRL, probably OCSP could be more suitable. Or, carefully chosen 
certificate lifetimes could reduce the size of revocation lists. But 
again, what is then the advantage of this approach?

Ana

---

From: Dong Zhang <[email-masked]>
Date: Thu, 11 Jun 2009 11:40:55 +0800

Hi Ana,

>again, what is then the advantage of this approach?

Imho, in CGA, the hosts already have a pair of public/privat keys. Now that the key pair is may provide protection for the negotiation messages. I think that it will let the negotiation more simple. Is is right?

Thank you.

2009-06-11 

Dong Zhang