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" <dmm-boun...@ietf.org on behalf of br...@innovationslab.net> wrote: > > >On 7/14/15 12:19 PM, Templin, Fred L wrote: >> Hi Brian, >> >>> -----Original Message----- >>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman >>> Sent: Tuesday, July 14, 2015 8:37 AM >>> To: dmm@ietf.org >>> 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 > > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
