> >> The RFC3118 authentication from one session could be used in the > >> other. > >> > >> e.g. do full DHCP + EAP for IPv4, get a key. Use the same key to > >> sign > >> the DHCPv6 packets. The NAS has the key and the clients identity > >> (MAC), > >> so all it has to do is lookup the MAC in it's table of allowed keys, > >> check the signature, and forward the packet if the signature is OK. > > > > We need to see the details documented. It is hard to understand what > > it > > looks like reading the above paragraph. > > > >> Their are drafts on key derivation from EAP to drive RFC 3118. > > > > I know, we wrote the one long time ago. But I cannot immediately see > > how you > > use achieve what you are describing above. Again, let's see some > > documentation/detailed description on that. > > http://www3.tools.ietf.org/html/draft-salowey-dhc-eapkey-3118-00
There is a huge gap between what you are vaguely describing above and what this I-D describes. You need to fill in that gap for us to understand how this works. > >>> ------------------- > >>> > >>> > >>> The client sends a DHCP Discover > >>> message with an option specifying the authentication protocol as > >>> EAP > >>> to find an available DHCP server. Any server that can that can > >>> authenticate and address it responds with a DHCPEAP-REQ message. > >>> > >>> A "DHCP server" sending a "request" to the "DHCP client"? This is so > >>> not-DHCP. Current DHCP state machine does not allow that. So, > >>> basically you > >>> are making a very significant change to the DHCP. > >>> > >> No actually DHCPFORCE in the Forced renw may have been the first to > >> do > >> this but so does Rebind in a way. > > > > What I'm saying is, DHCP client sending out a DHCPDISCOVER and > > receiving a > > DHCPEA-REQ is not compliant with standard DHCP state machine. > > > > You have also said that the proposal in effect pauses the state > between the Discover and the Offer. > In implementation we seem to have had no problem understanding this > pause. You can implement anything and make it work. That's not same as making it a standard for the whole industry. > >>> ------------------- > >>> > >>> I-D allows the DHCP server to respond to DHCPDISCOVER with "DHCPEAP- > >>> REQ" -- > >>> a brand new message (a request) sent in response. Again, breaking > >>> the state > >>> machine and effectively inventing a totally new protocol that does > >>> not look > >>> like DHCP anymore. > >> Ahh, what broke? It seems to work. > > > > See above. > > > >>> ------------------- > >>> > >>> In Figure 3, it seems like there is one DHCP client and two DHCP > >>> servers. > >>> Within the same DHCP flow, some messages are responded by one > >>> server, some > >>> by the other. This is certainly not standard DHCP. > >>> > >> > >> Actually this is commonly deployed DHCP as I have pointed out in many > >> messages. > > > > (Again) Please point to a IETF document that describes this. There > > is a > > whole lot of stuff happening out there, I don't think we can take > > them as-is > > without proper IETF buy-in. > > I am sorry but I do not buy that at all. We have implementations that > behave this way > and we now need to somehow pretend for your academic reasons that they > do not exist? This is IETF, not me. Not everything that got implemented somewhere get the free ticket to be rubber-stamped as an RFC. > >>> ------------------- > >>> > >>> > >>> How is EAP-reauth initiated by the network is handled? The DHCP > >>> client needs > >>> to receive an unsolicited DHCP request from the DHCP server out of > >>> blue. > >>> This does not look like standard DHCP at all. > >>> > >> > >> I do not see reauth in the requirements. If it was we could put a > >> mechanism in to handle it. > > > > It's not only a standard EAP behavior that needs to be accommodated, > > but > > also explicitly stated in the requirements: > > > > IPAuth-15 Must offer an option to re-authenticate periodically or on > > demand. > > Fine. DHCPFORCE message can out the client into rebind and then > reauth can be initiated from the client or > we can simply check the key. Please show us the detailed call flow. > >>> ------------------- > >>> > >>> How does DHCP satisfy the "orderly delivery" requirement imposed on > >>> the EAP > >>> lower layers by RFC 3748? > >>> > >>> > >> > >> Same as PPP. > > > > I don't think PPP and DHCP are the same protocol. I was asking how you > > handle this. A technical response would be appreciated. > > > Technically there is no difference in terms of orderly delivery of EAP > over PPPoE than EAP over DHCP. You are not really answering the question. Does DHCP ensure orderly delivery? If yes, please point out how (not by giving reference to other protocols)? If not, then you have an additional problem to solve. > >>> An overall observation: > >>> > >>> If we step back and look at the call flows, it is apparent that an > >>> EAP > >>> call-flow is wedged into regular(*) DHCP call-flow, which freezes at > >>> some > >>> point and resumes later. The wedged-in part is so different than > >>> DHCP, I > >>> don't understand the value of using DHCP as the transport for that > >>> part (why > >>> bother having such an impact on DHCP to the extent that it looks > >>> like a new > >>> protocol?). But worse than that, the wedged-in part also leaks into > >>> the > >>> regular DHCP call-flow (see how EAP Success/Failure gets transported > >>> over > >>> DHCPOFFER) -- hence not so regular anymore (*). > >>> > >> > >> I made pretty much the same observation on Pana for DSL yesterday. > > > > Nope. There is no modification to DHCP at all when PANA is used. No > > new DHCP > > options, messages, changes to the state machines, etc. > > > > And you propose a whole new protocol that is not supported on all the > network devices in question. Yes, and that's a fair statement. On one side there is a brand new protocol (RFC 5191) standardized by IETF specifically for this problem, and on the other side there is a legacy protocol (DHCP) that has nothing to do with "subscriber authentication" that needs to be extended beyond recognition (effectively giving birth to a new protocol). I cannot wrap my head around on how IETF would do such a thing. Alper > > - Ric > > > > Alper > > > >> > >> - Ric > >> > >> > >>> Alper > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Alper > >>> > >>>> -----Original Message----- > >>>> From: Alper Yegin [mailto:[EMAIL PROTECTED] > >>>> Sent: Saturday, July 26, 2008 2:28 AM > >>>> To: 'Richard Pruss' > >>>> Cc: '[email protected]'; '[EMAIL PROTECTED]' > >>>> Subject: RE: [Int-area] dhcp-auth > >>>> > >>>> I don't appreciate your comments. Let's stay on the technical > >>>> course. > >>>> > >>>>>> Let's start just looking at the issues about Figure 3... > >>>>>> > >>>>>> - What is the DHCP-wise functionality of the NAS? Text claims > >>>>>> it is > >>>>>> a "DHCP > >>>>>> relay" but I see it terminating some of the DHCP messages and > >>>>>> also > >>>>>> generating some other messages. This is not compliant with DHCP. > >>>>>> > >>>>> > >>>>> As we explained to you many times most vendors BRAS's act as a > >>>>> DHCP > >>>>> proxy and terminate all messages and look like a server to the > >>>>> client. > >>>> > >>>> > >>>> That's not accurate according to Figure 3. I see "some" DHCP > >>>> messages > >>>> terminating on the NAS (e.g., DHCPEAP*) and "others" going through > >>>> (e.g., > >>>> DHCPDISCOVER) within the same DHCP flow. > >>>> > >>>> I don't think it is as simple as your two-sentence explanation > >>>> anyways. As > >>>> requested earlier, IETF needs to see a document where this DHCP > >>>> proxy > >>>> model is defined. I'm aware of one DHCP proxy model and it is > >>>> nothing like > >>>> what your document is suggesting. > >>>> > >>>> Can you please send us a document that describes the DHCP proxy > >>>> model? > >>>> IETF needs to buy in the DHCP proxy model before any other proposal > >>>> built > >>>> on top of that gets accepted. > >>>> > >>>> > >>>>>> - How does the NAS handle EAP retransmissions? It needs to send > >>>>>> unsolicited > >>>>>> DHCP messages to the DHCP client. This is not compliant with > >>>>>> DHCP. > >>>>>> > >>>>> Actually that issue is open and we can discuss what a compliant > >>>>> implementation would mean in terms of retransmission timers so > >>>>> that > >>>>> right thing always happens at the right layer. > >>>> > >>>> OK, please explain. > >>>> > >>>> > >>>>>> - I see NAS inserting additional DHCP option (EAP Success) on > >>>>>> DHCPOFFER as > >>>>>> it forwards that message from DHCP server to DHCP client. This > >>>>>> again > >>>>>> breaks > >>>>>> DHCP. > >>>>>> > >>>>> As we explained to you many times most vendors BRAS's act as a > >>>>> DHCP > >>>>> proxy and terminate all messages and look like a server to the > >>>>> client. > >>>> > >>>> Again, NAS does not really terminate "all" messages (see above). > >>>> And this > >>>> "box in the middle" inserting DHCP options towards the DHCP client > >>>> breaks > >>>> DHCP. > >>>> > >>>>> Lets take this to the dhcwg list as that is where the review > >>>>> happens > >>>>> next week. > >>>> > >>>> Really? What happened to the escalation of this discussion to int- > >>>> area and > >>>> the outcome of the poll from last IETF? I hope Jari can clarify > >>>> this. > >>>> > >>>> Alper > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> - Ric > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> Alper > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Int-area mailing list > >>>>>> [email protected] > >>>>>> https://www.ietf.org/mailman/listinfo/int-area > >>> > >>> > > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
