Subject: [Dhcpv6bis] Delayed auth. protocol supports 2-message exchange?

From: Sheng Jiang <[email-masked]>
Date: Mon, 26 Jan 2015 02:34:19 +0000

Hi, all,

I am handling one of the 3315bis issue ticket regarding to whether the delayed auth. protocol supports 2-message exchange. I felt I need confirmation/discussion from the original 3315 authors. The issue ticket is described below, following by my personal understanding

Issue ticket issue 19 of #14: Section 21.4 speaks only to Solicit/Advertise? exchanges which would imply 4-message exchange. But, can the delayed auth. protocol also work with 2-message exchange (i.e., Solicit/Reply?)? If not, the text should say somewhere early on that this is for 4-message exchange only and explain why. Otherwise, the text should make clear that 2-message exchange under delayed auth is also supported.

My understanding: from the text in RFC3315, it looks the delayed auth protocol cannot work with 2 message exchange. It uses Solicit/Advertise exchange as server validation and selection process. Am I right? However, this looks for me a design choice rather than the ability limitation – it seems no much technical difficult to apply this to 2-message exchange - the advertise message could carry both validation information and response information. Or the response information may also leak of information?

Best regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Jan 2015 21:42:24 -0500

> Issue ticket issue 19 of #14: Section 21.4 speaks only to Solicit/Advertise? exchanges which would imply 4-message exchange. But, can the delayed auth. protocol also work with 2-message exchange (i…

I think this is correct, yes.

> My understanding: from the text in RFC3315, it looks the delayed auth protocol cannot work with 2 message exchange. It uses Solicit/Advertise exchange as server validation and selection process. Am…

Isn't there also an issue with deciding which key to use for authentication?   If you are doing a rapid commit, you don't know what server you're talking to, so you may use the wrong key for authentication.

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 26 Jan 2015 02:58:56 +0000

>> My understanding: from the text in RFC3315, it looks the delayed auth
>protocol cannot work with 2 message exchange. It uses Solicit/Advertise
>exchange as server validation and selection process. Am I right? However, this
>looks for me a design choice rather than the ability limitation – it seems no
>much technical difficult to apply this to 2-message exchange - the advertise
>message could carry both validation information and response information.
>Or the response information may also leak of information?
>
>Isn't there also an issue with deciding which key to use for authentication?
>If you are doing a rapid commit, you don't know what server you're talking to,
>so you may use the wrong key for authentication.

It seems the client key is only relevant to DHCP realm, not per-DHCP-server based.

Quote from section 21.4.3: " Each key is identified by <DHCP realm, client DUID, key id>." However, there seems be a key selection process in solicit/advertise, quote from section 21.4.4 " The server selects a key for the client based on the client's DUID."

One explanation may be "The client does not include any authentication information in the Authentication option in solicit message". So solicit/advertise exchange cannot complete the authentication process. Therefore, the server should not reply response information. These information should only available after client provide authentication information in the follow-up request message and pass the authentication process.

If so, these design choice are complicated hard embedded to this protocol. We should not change it for no essential requirements.

Best regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Jan 2015 08:27:59 -0500

> If so, these design choice are complicated hard embedded to this protocol. We should not change it for no essential requirements.

Right, the DHCP server is in a somewhat privileged position, because it knows what administrative domain it's connected to, whereas the client perhaps does not.   So the client just says "hey, give me an address, and I can authenticate!"   And then the server says "ok, okay, last time we talked, we used this key, please use this key."   And then presumably the client has that key, and uses it to authenticate.   Aside from the key distribution problem, it's not a bad system.   But it does rely on a four-way handshake, so I don't think we can change that.