Subject: [VIPR] Identity certificate segregation for VIPR

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 07 Feb 2012 09:08:49 -0800

The current version of RELOAD requires that the certificates used contain one
or more Node-IDs and one username.  This username plays no role in VIPR, so it
is not only useless, but can also be a source of privacy leak.

A proposal was made in the p2psip WG some time ago for Identity certificate
segregation[1] (see also [2]), but the author is waiting for the final version
of RELOAD to publish a draft about this.

My proposal is to say in the RELOAD usage document that VIPR must not use
certificates with username, and to put a placeholder for the reference to the
upcoming draft about Identity certificate segregation.

Opinions?

Thanks.

[1] http://www.ietf.org/mail-archive/web/p2psip/current/msg06005.html
[2] http://ieeexplore.ieee.org/iel5/4105970/5783356/05783372.pdf?arnumber=5783372

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Feb 2012 09:51:08 -0800

On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>

Or, you could just use a dummy (random) username, e.g., a hash of the node-id.

-Ekr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 07 Feb 2012 10:20:31 -0800

On 02/07/2012 09:51 AM, Eric Rescorla wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
>> The current version of RELOAD requires that the certificates used contain
>> one or more Node-IDs and one username.  This username plays no role in
>> VIPR, so it is not only useless, but can also be a source of privacy
>> leak.
>> 
>> A proposal was made in the p2psip WG some time ago for Identity
>> certificate segregation[1] (see also [2]), but the author is waiting for
>> the final version of RELOAD to publish a draft about this.
>> 
>> My proposal is to say in the RELOAD usage document that VIPR must not
>> use certificates with username, and to put a placeholder for the
>> reference to the upcoming draft about Identity certificate segregation.
> 

Yes, although that would still require an enrollment server that slightly
deviates from what is described in section 10.3 of RELOAD...

...or more precisely from what I understand from section 10.3, which is that
the user name stored in the certificate returned is the concatenation of 1)
the username passed as parameter of the HTTP POST, 2) the '@' character and 3)
the overlay name (there is at least one implementation I know of that assumes
that the username parameter is already in RCF822 form, thus permitting a
domain name different from the overlay name).

- -- 
Marc Petit-Huguenin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Feb 2012 10:33:31 -0800

> domain name different from the overlay name).

I don't read 10.3 as restricting the user name to be what is in the POST. The
requirement is:

   o  A single name this user is allowed to use in the overlay, using
      type rfc822Name.  Enrollment servers SHOULD take care to only
      allow legal characters in the name (e.g., no embedded NULs),
      rather than simply accepting any name provided by the user.

As authentication may not be required at all, I don't see how there
can be a requirement that these two usernames be the same.

   o  If authentication is required, there is an form parameter of
      "password" and "username" containing the user's name and password
      in the clear (hence the need for HTTPS)

-Ekr

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBCAAGBQJPMWtuAAoJECnERZXWan7E5iMP/i8USAqHFD8yhxAE8w2PKgyl
> CqWALShBV36pfMWojjQnNXDrLRPj0hnBoz9mQmBne03GQPof9x/uqDNdbc0BGm5+
> xmEWpQr4ZHqPm1L0pZRmg2o/7X3M+61Byc1x+WjOda0weZX8qg6xEgOyRgpFPlsa
> GowkfMgFj69xk5bvH+wXI27a1cWBeR5ocrICkWwHCwrVmmysQzixD4bGmb8+wmLX
> QZ9CiL77cGxRzvGSULl0smqIyGR2WkrIzErpdVoqvFIXAV12AMEKZAGjMjReCX2B
> OOsxtfpz2xLKpqgHdLCcV65Gvd4dEM8jChZAIRPG1WhanpM/rYlrUt0gF9SFX5cC
> DRcM5II8vKqgwPQ2yb42tNekYpWicxcK09T5U7ghMsJttMbfEpK3vb8lAmAfpt6h
> /n/VmgxqocMgRSIYHWPOFiJ69fbMml4Hn31DKUc9IrVYN5IlTT/zg4ILEww0sLdI
> KqDDboDS9FZB1pBrEiAeCDcGIz0rKKheGH95iedAdkcp0lFP6p3SrzaFzIKtjq/r
> ME+PBUjMjXPROz5m/w/BL8TAtwGfbbv3GDlkIXtM0aSybHCjhZSEtK8ng457sd3u
> 6Lv/WV8i2hlMj5guYV8rI1J+S3r7mm+31O4NxyVXVBpy1DDRnMNyfV8xJJt6dqfM
> h7UHwT2A5OoNOtdZgsn7
> =XWUE
> -----END PGP SIGNATURE-----

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 07 Feb 2012 10:45:43 -0800

On 02/07/2012 10:33 AM, Eric Rescorla wrote:
> On Tue, Feb 7, 2012 at 10:20 AM, Marc Petit-Huguenin <[email-masked]>
> wrote: On 02/07/2012 09:51 AM, Eric Rescorla wrote:
>>>>> The current version of RELOAD requires that the certificates used
>>>>> contain one or more Node-IDs and one username.  This username plays
>>>>> no role in VIPR, so it is not only useless, but can also be a
>>>>> source of privacy leak.
>>>>> 
>>>>> certificate segregation[1] (see also [2]), but the author is
>>>>> waiting for the final version of RELOAD to publish a draft about
>>>>> this.
>>>>> 
>>>>> My proposal is to say in the RELOAD usage document that VIPR must
>>>>> not use certificates with username, and to put a placeholder for
>>>>> the reference to the upcoming draft about Identity certificate
>>>>> segregation.
>>>> 
> ...or more precisely from what I understand from section 10.3, which is
> that the user name stored in the certificate returned is the concatenation
> of 1) the username passed as parameter of the HTTP POST, 2) the '@'
> character and 3) the overlay name (there is at least one implementation I
> know of that assumes that the username parameter is already in RCF822 form,
> thus permitting a domain name different from the overlay name).
> 
>> I don't read 10.3 as restricting the user name to be what is in the POST.
>> The requirement is:
> 
>> o  A single name this user is allowed to use in the overlay, using type
>> rfc822Name.  Enrollment servers SHOULD take care to only allow legal
>> characters in the name (e.g., no embedded NULs), rather than simply
>> accepting any name provided by the user.
> 
>> As authentication may not be required at all, I don't see how there can
>> be a requirement that these two usernames be the same.
> 
>> "password" and "username" containing the user's name and password in the
>> clear (hence the need for HTTPS)
> 

Hmmm.  So I guess that this means that the following is in fact a conditional
MUST:

"The enrollment server MUST authenticate the request using the
 provided user name and password."

Anyway, in the same paragraph we have this:

"If the authentication succeeds and the requested
 user name is acceptable, the server generates..."

I understand "requested user name" as the one that must be used as rfc822Name
in the returned certificate.  At best it is ambiguous.

- -- 
Marc Petit-Huguenin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Feb 2012 10:53:11 -0800

> in the returned certificate.  At best it is ambiguous.

Regardless, I don't see a problem from the VIPR perspective. The VIPR client can
simply request a username that doesn't leak private information.

-Ekr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 07 Feb 2012 11:38:05 -0800

On 02/07/2012 10:53 AM, Eric Rescorla wrote:
>>> On Tue, Feb 7, 2012 at 10:20 AM, Marc Petit-Huguenin
>>> <[email-masked]> wrote: On 02/07/2012 09:51 AM, Eric Rescorla wrote:
>>>>>>> The current version of RELOAD requires that the certificates
>>>>>>> used contain one or more Node-IDs and one username.  This
>>>>>>> username plays no role in VIPR, so it is not only useless, but
>>>>>>> can also be a source of privacy leak.
>>>>>>> 
>>>>>>> A proposal was made in the p2psip WG some time ago for
>>>>>>> Identity certificate segregation[1] (see also [2]), but the
>>>>>>> author is waiting for the final version of RELOAD to publish a
>>>>>>> draft about this.
>>>>>>> 
>>>>>>> My proposal is to say in the RELOAD usage document that VIPR
>>>>>>> must not use certificates with username, and to put a
>>>>>>> placeholder for the reference to the upcoming draft about
>>>>>>> Identity certificate segregation.
>>>>>> 
>>> Yes, although that would still require an enrollment server that
>>> slightly deviates from what is described in section 10.3 of RELOAD...
>>> 
>>> ...or more precisely from what I understand from section 10.3, which
>>> is that the user name stored in the certificate returned is the
>>> concatenation of 1) the username passed as parameter of the HTTP POST,
>>> 2) the '@' character and 3) the overlay name (there is at least one
>>> implementation I know of that assumes that the username parameter is
>>> already in RCF822 form, thus permitting a domain name different from
>>> the overlay name).
>>> 
>>>> I don't read 10.3 as restricting the user name to be what is in the
>>>> POST. The requirement is:
>>> 
>>>> type rfc822Name.  Enrollment servers SHOULD take care to only allow
>>>> legal characters in the name (e.g., no embedded NULs), rather than
>>>> simply accepting any name provided by the user.
>>> 
>>>> "password" and "username" containing the user's name and password in
>>>> the clear (hence the need for HTTPS)
>>> 
>> 
>> Hmmm.  So I guess that this means that the following is in fact a
>> conditional MUST:
>> 
>> "The enrollment server MUST authenticate the request using the provided
>> user name and password."
>> 
>> "If the authentication succeeds and the requested user name is
>> acceptable, the server generates..."
>> 
>> I understand "requested user name" as the one that must be used as
>> rfc822Name in the returned certificate.  At best it is ambiguous.
> 
> Regardless, I don't see a problem from the VIPR perspective. The VIPR
> client can simply request a username that doesn't leak private
> information.
> 

OK.

Thanks.

- -- 
Marc Petit-Huguenin