Re: RFC4283bis progress..

Brian/Fred,

This is exactly what I was thinking. Conveying identity and validating
identity are two different things. What is carried in NAI (RFC4283) is
just un-authenticated identity. What is needed for validation is a
protocol extension such as in RFC4285.

Regards
Sri


On 7/14/15, 11:30 AM, "dmm on behalf of Brian Haberman"
<[email protected] on behalf of [email protected]> wrote:

>
>
>On 7/14/15 12:19 PM, Templin, Fred L wrote:
>> Hi Brian,
>> 
>>> -----Original Message-----
>>> From: dmm [mailto:[email protected]] On Behalf Of Brian Haberman
>>> Sent: Tuesday, July 14, 2015 8:37 AM
>>> To: [email protected]
>>> Subject: Re: [DMM] RFC4283bis progress..
>>>
>>> Hi Fred,
>>>
>>> On 7/14/15 10:54 AM, Templin, Fred L wrote:
>>>> Hi Sri,
>>>>
>>>>
>>>>
>>>> Reason for the X.509 certificate is that, in some environments, an
>>>> attacker can
>>>>
>>>> spoof a DHCP Client Identifier and receive services that were intended
>>>> for the
>>>>
>>>> authentic client. With X.509 certificate, the certificate holder has
>>>>to
>>>> sign its DHCP
>>>>
>>>> messages with its private key so the DHCP server can authenticate
>>>>using the
>>>>
>>>> public key and therefore defeat any spoofing.
>>>>
>>>
>>> Can you suggest an X.509 format/profile that can be represented in 254
>>> bytes?
>> 
>> Probably not, but I think I have a better understanding of my
>>requirements
>> now. A mobile node can use an X.509 certificate to prove ownership of
>>the
>> DHCP Client Identifier, so it is the Client ID and not the X.509
>>certificate
>> itself that identifies the mobile node. Do I have that right?
>
>The client ID identifies the node.  An X.509 certificate provides the
>means of mapping identities to public keys and have that information
>verified by a third-party (CA).
>
>So, one could do something like:
>
>1. Client sends client-id to the server
>
>2. Server looks up X.509 cert by the client-id
>
>3. Server sends a challenge to the client based on the public key in the
>cert
>
>4. Client responds to the challenge by signing the response with the
>private key
>
>5. The server verifies the response with the public key
>
>
>Brian
>
>