Re: [dhcwg] FW: New Version Notification for draft-brzozowski-dhcp-eap-analysis-00

["Alper Yegin" <alper.yegin at yegin.org>]

Hello,

I just read this I-D. I'd like to thank authors for putting this analysis
together. 

I'd like to note that there were several points raised on the mailing lists
before. Since I didn't see them being covered in this I-D, I was wondering
what the analysis authors think/thought about them. Can we get their opinion
on these specific issues:


- The role of NAS with respect to DHCP is unclear. For some part it is
acting as a DHCP relay, for others as a DHCP server (as it terminates DHCP
messages and generates DHCP messages -- for EAP). Is the NAS playing two
distinct DHCP roles within the same DHCP session? How well does that fit
DHCP?

- NAS (acting as DHCP relay) is inserting DHCP options towards the DHCP
client. I'm not aware of DHCP relays inserting options in that direction. To
say the least, that breaks the end-to-end security, such as the one using
RFC 3118.

- " The client sends a Solicit message with an Option specifying the
   session authentication protocol as EAP to the
   All_DHCP_Relay_Agents_and_Servers address to find available DHCP
   servers.  Any server that can authenticate and address it responds
   with a DHCPEAP-REQ message."

This is talking about a DHCP server sending a "request" to the DHCP
"client", quite the opposite of current DHCP architecture. How well does
that fit the state machine?

- According to EAP, the EAP authenticator has to be able to retransmit EAP
requests. That means the NAS has to rexmit DHCPEAP-REQ to the DHCP client
until it receives a DHCPEAP-RES. How does this fit "DHCP"?

- EAP re-authentication may be initiated by the network. How would this be
handled? It requires the DHCP client to receive an unsolicited DHCP request
message from the NAS (a DHCP relay??). "DHCP client receiving a request from
relay" sounds quite non-standard to me.

- Finally, I wonder how orderly delivery of EAP (as mandated by RFC 3748) is
satisfied by this proposed EAP lower layer. 


Regards,

Alper











> -----Original Message-----
> From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
> Of John Jason Brzozowski
> Sent: Thursday, March 26, 2009 3:41 AM
> To: dhc WG
> Subject: [dhcwg] FW: New Version Notification for draft-brzozowski-
> dhcp-eap-analysis-00
> 
> FYI
> 
> John
> 
> ------ Forwarded Message
> From: IETF I-D Submission Tool <idsubmission at ietf.org>
> Date: Wed, 25 Mar 2009 16:12:31 -0400
> To: <mellon at nominum.com>
> Cc: "Brzozowski, John" <john_brzozowski at cable.comcast.com>, Geoffrey
> Holan
> <geoffrey.holan at telus.com>
> Subject: New Version Notification for
> draft-brzozowski-dhcp-eap-analysis-00
> 
> 
> 
> A new version of I-D, draft-brzozowski-dhcp-eap-analysis-00.txt has
> been
> successfuly submitted by Ted Lemon and posted to the IETF repository.
> 
> Filename:        draft-brzozowski-dhcp-eap-analysis
> Revision:        00
> Title:           DHCP Authentication Analysis
> Creation_date:   2009-03-25
> WG ID:           Independent Submission
> Number_of_pages: 9
> 
> Abstract:
> This document analyzes and technically evaluate the techniques
> proposed to support end-user authentication using extensions to DHCP.
> 
> 
> 
> The IETF Secretariat.
> 
> 
> 
> ------ End of Forwarded Message
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg