Re: [VIPR] Identity certificate segregation for VIPR

[Marc Petit-Huguenin <[e-mail]>]

-----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.

- -- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPMXFWAAoJECnERZXWan7E5GYP/1kIwCVuzCBGVsAOpnkzcYD9
9ypZnQAe/9JolbQfNqMcU80DrvW8oTaax7ncoPunRVxXTAZWgnFuCYa49NUGd55d
zyYmWgk+tN+szu7GZnpbfFP+jTY93A/KRwHacMDfm3BjukWU8lfk+IexG3+TO2GH
BZ7pCWVsnou4ANVjGhY3RkhB8d4m7TC2aCzjVtj3hQP8f36JPRzFprMNUs0hWmMz
tdRd/2k9ni/Li+fe7MCUL6k4QqaGmci4boUmsaChftlALh3dUj3rGRpU8qfnZT3u
/kbkJEjbyaerBLwKssFe0EnHXpew72tK4Ub30k9uWTVe7mkIhUdTM8tqauiR2Gaq
xyKrLn/rWPnd/ek0ZJAh4gyI2uSfDFEMtQPDFU4bmh/KCW3A9/xRa7ZyCtHotpQH
spBnE8Zf26na+06o3qgVxBgH7xvvcW7SJ0YuI7TPOB2WYV6hN9LiurvFEVrY8/EU
LbKVeJM5MBCwCNQDOe96RixDoSEQOyFP6zxzaDIseQq11E0m5izi86VaQH6fF+YR
sMRd1S7AzmoTPfFNe1GwhcMivaLzY6xY7g2e1I1T9SdgfBwBlbUO5pIcfdYhS+v7
LroQhPIhUSyYpi9FBezmOOPqLgH8FUcRT6scYWfcx8LfhFY82G/N+uVLbUheu5SE
TTftVuZJzhNuawAYXeT8
=QfH4
-----END PGP SIGNATURE-----