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:[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
