Re: RFC4283bis progress..
Brian Haberman <[email protected]>
| Newsgroups | gmane.ietf.mip6 |
|---|---|
| Message-ID | <55A55562.8010607__46631.5813050189$1436898693$gmane$org@innovationslab.net> |
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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
signature.asc
(application/pgp-signature, 481 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVpVVnAAoJEBOZRqCi7goqb54H/jUYZQNHc7IUyJUb37BIk54w /n0bdPt3DZOUC78CF4Zwi9eJLXOMbrdPdc7ohx6lWgOLbb/ZIRtXIzlvBnChwVlr YF1pOhm/DOgxXcsPpgWkSWqkD+xzPG27LhFHI0wBdADCfK0qX1M1afzZzxkWgR9M 7gqK9SZXlVqYCOGGcv5zfoAoE3254ziyqvCwIKH2vxGjq8B1C+LZiHcP6r7St4Zj sZqtRiLWCbM1NxSFjuNuZZenSPZokoscZCAYwHwUIWvandGYmnF5oAe5E0/onB2e 6BIFAWuhfFlzoeoXQ7sURlM3Gp25DeZW3zvdrTMslVyXBnuCKnSMebAYkztHMhY= =oNA8 -----END PGP SIGNATURE-----