Re: [VIPR] Identity certificate segregation for VIPR

Marc Petit-Huguenin <petithug@acm.org> Tue, 07 February 2012 19:38 UTC

Return-Path: <petithug@acm.org>
X-Original-To: vipr@ietfa.amsl.com
Delivered-To: vipr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EC521F88E5 for <vipr@ietfa.amsl.com>; Tue, 7 Feb 2012 11:38:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.344
X-Spam-Level:
X-Spam-Status: No, score=-102.344 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bX6od+B-kvpz for <vipr@ietfa.amsl.com>; Tue, 7 Feb 2012 11:38:12 -0800 (PST)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 6369B21F88DC for <vipr@ietf.org>; Tue, 7 Feb 2012 11:38:12 -0800 (PST)
Received: from [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08] (unknown [IPv6:2406:a000:f007:6f00:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 863B120D52; Tue, 7 Feb 2012 19:23:05 +0000 (UTC)
Message-ID: <4F317D9D.3020903@acm.org>
Date: Tue, 07 Feb 2012 11:38:05 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <4F315AA1.9030703@acm.org> <CABcZeBPqqo9WoFfT7N8GrwWDyE20_Jk=rNSFwuBaZLgny4skNg@mail.gmail.com> <4F316B6F.7020308@acm.org> <CABcZeBMmFrcmF6sZp+F+93=v9k=1Mis7xHR3pdQfrB8_NtWNGQ@mail.gmail.com> <4F317157.9040303@acm.org> <CABcZeBNLDmqJjhQsuwMW_BLYaTJA1vohCQYJBZ+VooDikyXPJw@mail.gmail.com>
In-Reply-To: <CABcZeBNLDmqJjhQsuwMW_BLYaTJA1vohCQYJBZ+VooDikyXPJw@mail.gmail.com>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "vipr@ietf.org" <vipr@ietf.org>
Subject: Re: [VIPR] Identity certificate segregation for VIPR
X-BeenThere: vipr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Verification Involving PSTN Reachability working group <vipr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vipr>, <mailto:vipr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vipr>
List-Post: <mailto:vipr@ietf.org>
List-Help: <mailto:vipr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vipr>, <mailto:vipr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2012 19:38:13 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/07/2012 10:53 AM, Eric Rescorla wrote:
> On Tue, Feb 7, 2012 at 10:45 AM, Marc Petit-Huguenin <petithug@acm.org>
> 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
>>> <petithug@acm.org> wrote: On 02/07/2012 09:51 AM, Eric Rescorla wrote:
>>>>>> On Tue, Feb 7, 2012 at 9:08 AM, Marc Petit-Huguenin 
>>>>>> <petithug@acm.org> 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.
> 

OK.

Thanks.

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

iQIcBAEBCAAGBQJPMX2bAAoJECnERZXWan7EHUgP/1RHhtOOV/MGRYILdD+0x3Hw
bdsZs+G8WNLlvrZ8HtE4aF76wluSH91q5r5w46agG/262nkjLQXqHvD3hsrPsHUE
ULKAR0SGj4CZJSTNdT7nVEchI8uAD3TzkyIvdn8aRkrQHbsiB6PDZtFA01440IYT
i28o6fBsKWSJ02ze848HL25hle/K4QWiui6lqN6/gLA2F6qdPDe9raI1f/pBliD0
tXIcUmMIYqfR5i8dFsGYd04noLWEXdsVWCqrAgvXkAS0UP9nqu3UtKE7r1sDWnWw
n9gyJK+Gwo8Ooja6tBR5KM3VsB7BO/x4LVtGUesmzq2qMQxIlt1Px1ag9Ei5hIJr
c9aEHdpBImS8qVb4qxNEfChIBRzbTnN/pK/klOZ/uIV4o9xMRicmzoq6GOR460AL
43tQ0KvWGuCGZbSPhEqBouscll0GI6HruooB4SU0eyM6ZWWNgP7yQDyr6FQbQ0Cd
4Up0KLNP7Q4j8r8rc/RViqoj57U1xWwWvJoPRzJEUd7flZDnYjsXRU9QLv12XCrV
kz5JLVn/oanwnWlsH0ruwXNAEwB8zuUlJd31kpXj8+qadtxnHb/0dJEPqfWRiATo
gLilC4BR5NjEtjzloHbKAeXceLiYTLiQzsPMT0S7xrazwdkeztB9P8vIw3ivKnme
/pSc5XpkL4z8QR/EVla4
=Fk4v
-----END PGP SIGNATURE-----