Subject: [Hipsec] draft-ietf-hip-cert-02-pre00

From: Varjonen Samu <[email-masked]>
Date: Mon, 19 Oct 2009 10:54:53 +0300

Hi,

Here is the pre-version of the hip-cert draft. It has been living a 
quiet life on the list. We have been asking for comments on the list 
before and after IETF 75 (Stockholm). There seems to be little or no 
comments about the draft. The new version contains bigger editorial 
changes, change in the default cert and added type numbers.

Now I ask you to read and comment the draft.

http://www.cs.helsinki.fi/u/sklvarjo/draft-ietf-hip-cert-02-pre00.txt

Few topics for the comments:

- Is the draft sufficient? Do we need to specify something more? Is 
something important missing?

- Is SPKI the right choice for the default format? X.509 is more widely 
deployed and has better support vs. SPKI is simpler but has less 
support. In the pre-version I already changed X.509s as the default, 
because the X.509s are commonly used in the wild and SPKIs are more like 
research curiosity(?).

- Are the hash and URL encodings needed? At least with on-path 
middleboxes they are problematic.

- Are the examples in the appendixes sufficient?

- Should we start the move from a draft to experimental RFC?

BR,
Samu Varjonen

---

From: "Mattes, David" <[email-masked]>
Date: Wed, 21 Oct 2009 11:44:22 -0700

Hi Samu,

As some background, I am focused on using HIP operationally and therefore have a pragmatic point of view of the specifications.  Here are some in-line opinions for your questions below.

Also, what is the purpose of requiring the HIT as part of the X.509 information?  In practice (at least until HIP is a de-facto standard ;-), I think it will be quite difficult to convince Certificate issuers to include new or different information.  I think you should remove that recommendation from the draft.

Page 1, Introduction, Last sentence: Do you mean Section 5.2 of RFC5201?

Minor nit:
Page 3, Paragraph 1, Line 2: s/X.503.v3/X.509.v3

Thank you for your work on this!

Regards,
David Mattes

> -----Original Message-----

I agree that having on-path middleboxes request remote data is problematic (also from a trust point of view!), so what about introducing a mechanism for the middleboxes or responders to request the full certificate when presented with a CERT URL?  This way, middleboxes and responders can cache certs and only request the entire certificate when necessary.  This mechanism could also allow post-mobility-event middleboxes to request endpoint certificates when they start to see a new flow.  

This mechanism is probably outside the scope of this draft, but would the requests themselves be defined here?  Another object I could envision being requested would be a CA chain for a given certificate.

> because the X.509s are commonly used in the wild and SPKIs are more like

I think that X.509 should be the default format.

> middleboxes they are problematic.

I think the hash and URL encodings are important and would even like to see them expanded to include http URL, Distinguished Name, and LDAP path.

> - Are the examples in the appendixes sufficient?

It would be nice to see an example with sending a certificate chain.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 21 Oct 2009 21:13:41 -0700

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Mattes, David
> Sent: Wednesday, October 21, 2009 11:44 AM
> To: 'Varjonen Samu'; HIP
> Subject: Re: [Hipsec] draft-ietf-hip-cert-02-pre00
>
> Hi Samu,
>
> As some background, I am focused on using HIP operationally
> and therefore have a pragmatic point of view of the
> specifications.  Here are some in-line opinions for your
> questions below.
>
> Also, what is the purpose of requiring the HIT as part of the
> X.509 information?  In practice (at least until HIP is a
> de-facto standard ;-), I think it will be quite difficult to
> convince Certificate issuers to include new or different
> information.  I think you should remove that recommendation
> from the draft.

I am guessing that the HIT is mandated because the draft focuses on self-signed certificates.  However, I don't really understand such a use case (self-signed certificate).  Isn't all of the information in the example certificate already provided as part of RFC 5201 HIP messaging?

I had thought that the HIP CERT draft could specify the following:
1) using the HIP HI (public key) as a subject public key, bind a subject Alternative Name (such as email address or other value) to that key, based on the CA signature.
2)  elements of procedure for exchanging CERTs, or requesting that the peer provide a CERT.

So, I'm guessing that David has the first use case in mind, that the CA need not even be HIP aware but is just asked to sign the binding between key and name, and then the host can use the subject key as a host identity.

Regarding elements of procedure, it seemed to me that it would be in scope to specify how to ask the end host to provide a CERT, plus how to handle failure cases (e.g. "I don't recognize the CA", "Bad certificate signature", etc.).  In addition, I agree with David's comment that a HIP-aware middlebox ought to be able to challenge a host to provide a CERT.  I don't know whether just a generic challenge would be needed, or whether the middlebox would be able to identify the CAs that it recognizes in the challenge.

> >
> > - Is SPKI the right choice for the default format?

Do we need a default for this?  What does it mean that "All implementations MUST support the X.509v3 format."  This is an optional, non-critical parameter.

It seems to me that implementations ought to be RECOMMENDED to support one or both formats, and we specify what happens when one side of the exchange does not understand CERT at all, or when it understands CERT but does not support the Type number.

> I think the hash and URL encodings are important and would
> even like to see them expanded to include http URL,
> Distinguished Name, and LDAP path.

Agree.

> It would be nice to see an example with sending a certificate chain.

Agree (a non-self-signed example).

A few small editorial comments are that in section 2, the capitalization is not consistent in paragraph 3, and it seems like the last sentence before the figure should be the lead sentence of paragraph three, so the reader doesn't infer from the existing paragraph three lead sentence that any HIP packet (e.g. I1) carries CERT.

Regards,
Tom

---

From: Samu Varjonen <[email-masked]>
Date: Thu, 22 Oct 2009 09:04:29 +0300

> Also, what is the purpose of requiring the HIT as part of the X.509 information?  In practice (at least until HIP is a de-facto standard ;-), I think it will be quite difficult to convince Certific…

We do not want to enforce all certificates to have HITs encoded as 
subjects and/or issuers. It is there if you need to encode HITs. I will 
rephrase the text to clearly state this.

> Page 1, Introduction, Last sentence: Do you mean Section 5.2 of RFC5201?

Looks like it, will fix it.

> Page 3, Paragraph 1, Line 2: s/X.503.v3/X.509.v3

Typo, will fix it.

> This mechanism is probably outside the scope of this draft, but would the requests themselves be defined here?  Another object I could envision being requested would be a CA chain for a given certi…

We have been discussing this and our solution for this is to use 
draft-heer-hip-service-00 (see Section 4.1. Certificates)to signal the 
end-host about the needed additional credentials.

> I think that X.509 should be the default format.

I agree.

> I think the hash and URL encodings are important and would even like to see them expanded to include http URL, Distinguished Name, and LDAP path.

I'll look into this.

> It would be nice to see an example with sending a certificate chain.

With all certificates included or just the parameter headers and 
parameter payload omitted? This will take loads of space but could be 
usefull.

Thanks for the comments. They were helpfull.

-- 
BR,
Samu

"Programmer is an organism that changes caffeine into code"

---

From: Samu Varjonen <[email-masked]>
Date: Thu, 22 Oct 2009 09:16:51 +0300

> I am guessing that the HIT is mandated because the draft focuses on self-signed certificates.  However, I don't really understand such a use case (self-signed certificate).  Isn't all of the inform…

There is an answer in the earlier mail for this. Rephrasing the text.

> 1) using the HIP HI (public key) as a subject public key, bind a subject Alternative Name (such as email address or other value) to that key, based on the CA signature.

That can be done after I rephrase the mandated HIT text.

> 2)  elements of procedure for exchanging CERTs, or requesting that the peer provide a CERT.

This has been discussed but for some reason we put it into 
hip-service-00. Do you think hip-cert should have its own way of asking 
the certificates or could it use hip-service-00? The functionality would 
overlap with the hip-service-00.

> Regarding elements of procedure, it seemed to me that it would be in scope to specify how to ask the end host to provide a CERT, plus how to handle failure cases (e.g. "I don't recognize the CA", "…

Sounds like hip-service-00 :)

> It seems to me that implementations ought to be RECOMMENDED to support one or both formats, and we specify what happens when one side of the exchange does not understand CERT at all, or when it und…

It was supposed to be like: If you implement this non-critical parameter 
you should at-least implement support for this certificate. But I can 
see your point and I am leaning towards it and here I should refer to 
the hip-service-00 again.

>> Distinguished Name, and LDAP path.

Looking into this and agreeing.

> Agree (a non-self-signed example).

OK. can be done.

> A few small editorial comments are that in section 2, the capitalization is not consistent in paragraph 3, and it seems like the last sentence before the figure should be the lead sentence of parag…

OK, will fix this.

> Tom

Thanks for the helpful comments.

-- 
BR,
Samu

---

From: Miika Komu <[email-masked]>
Date: Thu, 22 Oct 2009 09:36:35 +0300

Samu Varjonen wrote:

Hi,

> Mattes, David kirjoitti:
>> Hi Samu,
>>
>> As some background, I am focused on using HIP operationally and 
>> therefore have a pragmatic point of view of the specifications.  Here 
>> are some in-line opinions for your questions below.
>>
>> Also, what is the purpose of requiring the HIT as part of the X.509 
>> information?  In practice (at least until HIP is a de-facto standard 
>> ;-), I think it will be quite difficult to convince Certificate 
>> issuers to include new or different information.  I think you should 
>> remove that recommendation from the draft.
> 

does the HIT have problems with the planned algo agility mechanism 
described in here:

http://www.ietf.org/mail-archive/web/hipsec/current/msg02661.html

---

From: Tobias Heer <[email-masked]>
Date: Thu, 22 Oct 2009 10:47:36 +0200

Hi.

Comments inline.

Am 22.10.2009 um 08:16 schrieb Samu Varjonen:

> This has been discussed but for some reason we put it into hip- 
> service-00. Do you think hip-cert should have its own way of asking  
> the certificates or could it use hip-service-00? The functionality  
> would overlap with the hip-service-00.
>
The HIP hip-service-00 draft presents a general way of notifying end- 
hosts about requirements and properties of a service and allows some  
simple negotiations. Requesting certain certificates was one of the  
main reasons for writing the draft. However, we felt that more general  
negotiations would be out of scope for the hip-crt draft. The draft  
has not been advanced because we got very little comments on which  
services people would/could use. If needed we can narrow down the  
types of services that can be negotiated and focus on the signaling of  
the certificate first but I wouldn't really want to abandon a more  
general use of the HIP service parameter.

>> So, I'm guessing that David has the first use case in mind, that  
>> the CA need not even be HIP aware but is just asked to sign the  
>> binding between key and name, and then the host can use the subject  
>> key as a host identity.
>> Regarding elements of procedure, it seemed to me that it would be  
>> in scope to specify how to ask the end host to provide a CERT, plus  
>> how to handle failure cases (e.g. "I don't recognize the CA", "Bad  
>> certificate signature", etc.).  In addition, I agree with David's  
>> comment that a HIP-aware middlebox ought to be able to challenge a  
>> host to provide a CERT.  I don't know whether just a generic  
>> challenge would be needed, or whether the middlebox would be able  
>> to identify the CAs that it recognizes in the challenge.
>
>> Do we need a default for this?  What does it mean that "All  
>> implementations MUST support the X.509v3 format."  This is an  
>> optional, non-critical parameter.
>> It seems to me that implementations ought to be RECOMMENDED to  
>> support one or both formats, and we specify what happens when one  
>> side of the exchange does not understand CERT at all, or when it  
>> understands CERT but does not support the Type number.
>
> It was supposed to be like: If you implement this non-critical  
> parameter you should at-least implement support for this  
> certificate. But I can see your point and I am leaning towards it  
> and here I should refer to the hip-service-00 again.

If needed we can flesh out the certificate handling in the hip-service  
draft to support the hip-cert draft. So far, the hip-service-00 draft  
was discussed in the RG. Should we expand this to the WG and process  
hip-cert and hip-service as a bundle?

BR,
Tobias

>> A few small editorial comments are that in section 2, the  
>> capitalization is not consistent in paragraph 3, and it seems like  
>> the last sentence before the figure should be the lead sentence of  
>> paragraph three, so the reader doesn't infer from the existing  
>> paragraph three lead sentence that any HIP packet (e.g. I1) carries  
>> CERT.
>
> OK, will fix this.
>
>> Regards,
>> Tom
>
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 22 Oct 2009 07:26:23 -0700

> hip-cert and hip-service as a bundle?

I don't have a strong opinion about where it ends up.  I would most intuitively find the certificate handling behavior within the certificate draft but if there is a need to make it part of a more general framework, the services draft might be OK.  I think it would be most direct to try to agree on or write down the use cases and desired functionality/behavior for certificate handling, then later decide whether it fits better in a service draft or in the cert draft.

- Tom

---

From: Samu Varjonen <[email-masked]>
Date: Mon, 26 Oct 2009 11:13:30 +0200

Miika Komu wrote:
>> subjects and/or issuers. It is there if you need to encode HITs. I 
>> will rephrase the text to clearly state this.
> 

As I have understood the HIT will remain in the present presentation 
format and the hash algo is read from DNS or with I1-R1 exchange from 
the responders HOST-ID. In which, the KEY RR would just have a new 
algorithm number. This affects the public-key and signature sequences in 
the certificates but they are defined in their own respective documents 
(or need to be defined). HIP-cert only describes the parameter, how to 
carry the certificates in side HIP control messages, and how to encode 
and use HITs in certificates as entities like issuer and/or subject.

At least, now I do not see any problems, but if something comes up 
please let me know.

BR,
Samu