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-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.