Re: [VIPR] Identity certificate segregation for VIPR

[Eric Rescorla <[e-mail]>]

On Tue, Feb 7, 2012 at 10:45 AM, Marc Petit-Huguenin <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 02/07/2012 10:33 AM, Eric Rescorla wrote:
>> On Tue, Feb 7, 2012 at 10:20 AM, Marc Petit-Huguenin <[e-mail]>
>> wrote: On 02/07/2012 09:51 AM, Eric Rescorla wrote:
>>>>> On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin
>>>>> <[e-mail]> 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.
>>>>>
>>>>> Or, you could just use a dummy (random) username, e.g., a hash of
>>>>> the node-id.
>>>>>
>>
>> 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:
>>
>>> 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)
>>
>
> 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.

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