Subject: [DMM] RFC4283bis progress..

From: jouni korhonen <[email-masked]>
Date: Thu, 9 Jul 2015 13:49:35 -0700

Charlie, WG,

In last IETF and slightly after that there was discussion about missing
MN-IDs in the current -00 version. Have these been or rather will these be
addressed? I'd like to move this trivial document forward.

- Jouni & Dapeng

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 10 Jul 2015 01:30:44 +0000

I can review and provide comments. I think its ready for publication, may be after a minor edit.

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of jouni korhonen <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 9, 2015 at 1:49 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Subject: [DMM] RFC4283bis progress..

Charlie, WG,

In last IETF and slightly after that there was discussion about missing MN-IDs in the current -00 version. Have these been or rather will these be addressed? I'd like to move this trivial document forward.

- Jouni & Dapeng

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 09 Jul 2015 19:44:51 -0700

Hello folks,

The last discussion about the document was related to whether or not 
Vehicle ID should be included in the draft.  No resolution was reached 
for that discussion.

However, the draft may still be considered ready for publication. Other 
ID formats can certainly be added in the future.

Regards,
Charlie P.

On 7/9/2015 6:30 PM, Sri Gundavelli (sgundave) wrote:
> From: dmm <[email-masked] <mailto:[email-masked]>> on 
> behalf of jouni korhonen <[email-masked] 
> <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, Charlie Perkins <[email-masked] 
> <mailto:[email-masked]>>
> In last IETF and slightly after that there was discussion about 
> missing MN-IDs in the current -00 version. Have these been or rather 
> will these be addressed? I'd like to move this trivial document forward.
>
> - Jouni & Dapeng
>
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 13 Jul 2015 17:50:16 +0000

Hi, I would like to suggest one additional identifier before publication:
X.509 certificate as per Section 5.2 of Secure DHCPv6:

https://www.ietf.org/id/draft-ietf-dhc-sedhcpv6-08.txt

Thanks - Fred
[email-masked]

From: dmm [mailto:[email-masked]] On Behalf Of Charlie Perkins
Sent: Thursday, July 09, 2015 7:45 PM
To: Sri Gundavelli (sgundave); jouni korhonen; [email-masked]; Charlie Perkins
Subject: Re: [DMM] RFC4283bis progress..

Hello folks,

The last discussion about the document was related to whether or not Vehicle ID should be included in the draft.  No resolution was reached for that discussion.

However, the draft may still be considered ready for publication.  Other ID formats can certainly be added in the future.

Regards,
Charlie P.

Charlie, WG,

dmm mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 13 Jul 2015 18:08:20 +0000

HI Fred,

MIP NAI structure is some what designed for carrying an identifier that can be represented in a simple structure. It is bound by the 1-octet size limit defined in RFC6275. X.509 is a complex structure, it includes the signed public key, serial number and number of other parameters and based on the key size it can be in Kbytes. Wondering, why a simple DHCP Client Identifier is not sufficient here. Support for EUI based identifiers is already present and that allows us to map to DHCP client identifiers ?

Regards
Sri

From: "Templin, Fred L" <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 13, 2015 at 10:50 AM
To: Charlie Perkins <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, jouni korhonen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Charlie Perkins <[email-masked]<mailto:[email-masked]>>
Subject: RE: [DMM] RFC4283bis progress..

Thanks – Fred
[email-masked]<mailto:[email-masked]>

From: dmm [mailto:[email-masked]] On Behalf Of Charlie Perkins
Sent: Thursday, July 09, 2015 7:45 PM
To: Sri Gundavelli (sgundave); jouni korhonen; [email-masked]<mailto:[email-masked]>; Charlie Perkins
Subject: Re: [DMM] RFC4283bis progress..

Hello folks,

Regards,
Charlie P.

Charlie, WG,

dmm mailing list

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Jul 2015 14:54:48 +0000

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.

Thanks - Fred

From: Sri Gundavelli (sgundave) [mailto:[email-masked]]
Sent: Monday, July 13, 2015 11:08 AM
To: Templin, Fred L; Charlie Perkins; jouni korhonen; [email-masked]; Charlie Perkins
Subject: Re: [DMM] RFC4283bis progress..

HI Fred,

Regards
Sri

Thanks - Fred

Hello folks,

Regards,
Charlie P.

Charlie, WG,

dmm mailing list

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Jul 2015 11:36:56 -0400

Hi Fred,

> public key and therefore defeat any spoofing.

Can you suggest an X.509 format/profile that can be represented in 254
bytes?

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Jul 2015 16:19:31 +0000

Hi Brian,

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Tuesday, July 14, 2015 8:37 AM
> To: [email-masked]

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?

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Tue, 14 Jul 2015 14:30:58 -0400

> 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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 14 Jul 2015 18:34:04 +0000

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-masked] on behalf of [email-masked]> wrote:

>>>> authentic client. With X.509 certificate, the certificate holder has
>>>>to
>>>> sign its DHCP
>>>>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 14 Jul 2015 12:05:03 -0700

This is doable using "Hash and URL of X.509 certificate" used in IKEv2 
certificate payloads. See RFC 7296 Section 3.6. That should fit into 254 
bytes assuming the URL is not extra long.

- Jouni

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 14 Jul 2015 19:25:37 +0000

Hi Brian,

> Sent: Tuesday, July 14, 2015 11:31 AM
> To: [email-masked]

I think we are basically thinking the same way, but at least in the
case I have in mind the client would send both the client ID and
the X.509 certificate in the same message while signing the message
for the server to verify. So, one round trip instead of two. Or, at
least that is how I understood how Secure DHCPv6 works.

Thanks - Fred