Subject: One more example for draft-ietf-6man-text-addr-representation

From: Heikki Vatiainen <[email-masked]>
Date: Tue, 25 Aug 2009 22:32:08 +0300

In case examples of problems with address presentation are useful, here
is one more.

RFC 5280 "Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile" section 4.2.1.6. "Subject
Alternative Name" says that IPv6 addresses can be contained in
subjectAltName. No news there.

When actually using a certificate that has an IPv6 address the following
behaviour was seen with various SSL related components:

Perl library Net::SSLeay returns the IPv6 subjectAltName in this format:
fdf1:a315:9433:27:0:0:0:27

Perl Socket6 library contains inet_ntop that returns address in this
format: fdf1:a315:9433:27::27

OpenSSL utility that dumps the certificate in text format shows the
address like this: FDF1:A315:9433:27:0:0:0:27

Just recently I was debugging a perl program that had a problem with
certificate verification. Certificate verification failed when the
certificate presented by peer had subjectAltName with IPv6 address
fdf1:a315:9433:27:0:0:0:27 and this did not match the address where the
connection came from: fdf1:a315:9433:27::27.

Same address but different presentation was the cause here too since the
comparison was done using text strings.

Thanks for documenting these issues!

-- 
Heikki Vatiainen, Arch Red Oy
+358 44 087 6547

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 27 Aug 2009 12:55:20 +0900

Hi Heikki

Thanks for taking the time to review the document,
and your point is something that I think is worth
mentioning in the draft. How about we add a sub-section
like this

3.2.5 verification and validiation

[RFC 5280] section 4.2.1.6 states that X.509 certificates may
contain IPv6 addresses in the SubjectAltName field.
When these fields are verified against actual connection status, if
verification was done with a simple text comparison, the certificate
may be mistakenly shown as being invalid. Similar problems can occur
in any protocol that embeds IPv6 addresses which have to be verified
or validated.

I admit word smithing needs to be done, but does this seem reasonable?

> Thanks for documenting these issues!

and thank you for your comments.

Regards,
Seiichi

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Aug 2009 16:15:30 +1200

On 2009-08-27 15:55, Seiichi Kawamura wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Heikki
> 

As far as X.509 certificates go, this point is correct, but using
IP addresses in subjectAltName (lower case s) is a really bad idea anyway.
We recommend against this in section 5.3.5 of draft-carpenter-renum-needs-work-03
(which is under AD review for Informational status).

     Brian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> 
> iEYEARECAAYFAkqWA6gACgkQcrhTYfxyMkKhxACfbOUzBkSO4D4iSkOHeNf+sTrb
> rqYAoIdRo/69HU6tA/l1lDQI35JriE+3
> =EkIU
> -----END PGP SIGNATURE-----
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 27 Aug 2009 13:48:27 +0900

Hi Brian

>> (which is under AD review for Informational status).

Yes. I agree. I did have doubts about
focusing on subjectAltName as a common example,
but I could not come up with a better one right now.
I did think the verification problem that Heikki mentioned
is important and can happen in other protocols so I might
fix the wording to focus on the problem.

Regards,
Seiichi

>>>> Thanks for documenting these issues!
- --------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
- --------------------------------------------------------------------

- --
================================================
NEC BIGLOBE Ltd.
   Seiichi Kawamura <[email-masked]>
   +81 3 3798 6085  (FAX: +81 3 3798 6029)
   +81 90 1547 4791 (mobile)

---

From: Heikki Vatiainen <[email-masked]>
Date: Mon, 31 Aug 2009 12:49:57 +0300

Seiichi Kawamura wrote:

>>> IP addresses in subjectAltName (lower case s) is a really bad 
>>> idea anyway. We recommend against this in section 5.3.5 of 
>>> draft-carpenter-renum-needs-work-03 (which is under AD review for
>>> Informational status).

> Yes. I agree. I did have doubts about focusing on subjectAltName as a
> common example, but I could not come up with a better one right now.

If there is a subsection that touches certificates, I think Subject and
Issuer fields should also be mentioned, since CNs (common name)
sometimes contain addresses. Mentioning them all should make a better
example.

I noticed Brian's draft does not mention this explicitly, but I take
"Any other use of IP addresses in cryptographic material is likely to be
similarly troublesome." is there to cover CNs too.

I have added a Cc: to Stefan Winter, since Stefan is author of
draft-ietf-radext-radsec-05 "RADIUS over TCP/TLS (RadSec)". The reason I
noticed the address presentation problem with subjectAltName was when I
was experimenting with RadSec.  Part of the draft describes how to
verify certificates when subjectAltName or CN contains IP addresses.

> I did think the verification problem that Heikki mentioned is 
> important and can happen in other protocols so I might fix the 
> wording to focus on the problem.

Certificates with IP addresses are sold and used, so I would not be
surprised if address presentation leads to verification problems.