-----Original Message-----
From: Alan DeKok [mailto:[EMAIL PROTECTED]
Sent: Friday, April 13, 2007 6:08 PM
To: Curtis Sherbo
Cc: [EMAIL PROTECTED]
Subject: Re: [Int-area] Discussion of subscriber authentication
Curtis Sherbo wrote:
... The BRAS will not install a
forwarding entry for a subscriber that it has not learned
through the
DHCP process. Forwarding entries are then built based on
the assigned
IP address and the requesting MAC.
Ah. That wasn't clear from the draft.
3) Service providers typically do not want to allow
configuration of a
client until they are authenticated. Often because they
will provide
alternate configuration depending on their identification.
That's fine. Can they use EAP?
4) The goal of draft-pruss-dhcp-auth-dsl is to provide an
option for
service providers to maintain their investment in their current AAA
infrastructures with little or no changes to them. I don't
believe it
is intended to alter DHCP server implementations, but rather
proxy/relays/servers that are implemented in BRAS platforms. I
suppose this is really the area for debate.
The draft could be implemented by having the relay filter &
edit DHCP requests. That's awkward, though, and possible
only because the DHCP packets are unsigned....
5) Client side implementations that would require modification are
typically in the control of the service provider. They may be a
managed residential gateway, or a dsl modem. User owned
equipment is
typically not allowed to authenticate the PPPoE session
today, I would
see this as being no different.
An alternate solution that would achieve the same goal, but
wouldn't require piggy-backing authentication onto DHCP would
be to use EAP.
EAP-MD5 is already supported by all supplicants, and is just CHAP.
Using EAP also permits the authentication methods to be
updated without modifying DHCP.
The only problem is that wired authentication does not have
the equivalent of wireless systems broadcasting SSID's. That
problem can be addressed via the following method.
1) Client sends a DHCP DISCOVER or DHCP request
2) relay (BRAS) responds with "DHCP AUTH required"
This would be a new DHCP message, containing a list of
authentication domains (read: SSIDs).
3) Client does EAP to BRAS
4) on EAP success, client performs DHCP again.
The downside to this approach is that it requires more code
on the client and on the BRAS than just putting CHAP into
DHCP. The upside is that I think it may get wider acceptance
than CHAP inside of DHCP. It leaves authentication to EAP,
and network configuration to DHCP.
i.e. one of the widely acknowledged problems in performing
EAP authentication for wired networks is the inability to
know that EAP is a requirement. A related problem is that
even if the client knows EAP is required, it doesn't know
which network it is connected to, and therefore which
credentials it should present.
With this approach, it's clear that the BRAS is blocking
all DHCP traffic, and not rewriting packets. It's also clear
that DHCP servers do not have to change. DHCP clients have
to change, but hopefully minimally, and only to kick-start an
EAP session when a DHCP "Auth required" packet is received.
The existing client DHCP timers for retransmits, etc. could
even be left alone, as the EAP session *should* finish before
the next DHCP request is sent.
If this appears to be a viable approach, I can write up a
draft this coming week.
Alan DeKok.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
