Re: [Int-area] dhcp-auth, part 2
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Int-area] dhcp-auth, part 2


On 29/07/2008, at 10:04 AM, Alper Yegin wrote:
If multiple DHCP exchanges are occurring with multiple servers, both 
 IPv4 and IPv6 each needs to authenticate separately.

So, the same host needs to get authenticated twice if it is using
both IPv4
and IPv6. This is a very unusual model for AAA. You need to update AAA 
servers to allow "double login." And with that, it is already
violating the
following requirement:

	IPAuth-2	Must re-use existing SP Authentication
infrastructure (use
	Radius Database)  and allow mixed mode operation (eg PPP and IP) on
	the same L3 edge device


 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






-------------------


 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. 



-------------------

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? 








-------------------


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.






-------------------

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. 





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. 

- Ric



Alper



- Ric



Alper

















Alper


-----Original Message-----
From: Alper Yegin [mailto:alper.yegin at yegin.org]
Sent: Saturday, July 26, 2008 2:28 AM
To: 'Richard Pruss'
Cc: 'int-area at ietf.org'; 'dhcwg at ietf.org'
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
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area








_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.