Subject: [Int-area] Why IETF should not standardize dhcp-auth

From: "Alper Yegin" <[email-masked]>
Date: Tue, 4 Dec 2007 08:44:49 +0200

There are several concerns against standardizing
draft-pruss-dhcp-auth-dsl-02.

1. Architectural

   When it comes to solving "distinct" fundamental problems (e.g., access 
   auth, mobility, configuration, QoS), IETF defines "distinct" protocols 
   for each. Piggybacking one over other for the sake of some optimization  
   (product/performance/etc) conflicts with the strategy we have been 
   following at IETF.

   IAB document draft-iab-ip-config-00.txt is clear on that:

	Network access authentication is a distinct problem from Internet
	host configuration.  Network access authentication is best handled
	independently of the configuration mechanisms in use for the
Internet
 	and higher layers. 

2. IETF principle 

   IETF has already defined a solution for the problem: PANA. As a 
   principle, IETF should first make an attempt to see if it really does not

   solve the problem and consider refining its protocol if necessary.  
   Defining a new protocol each time someone has another solution is not 
   compliant with IETF's principle goal of achieving interoperability.

   PANA already satisfies the requirements we received from DSLF.

3. Breaking DHCP

   EAP and DHCP do not stack up well because none of the end points, state 
   machines, call flows match. And the proposal ends up breaking DHCP.
   Specifically:

   - DHCPOFFER does not deliver IP address, despite RFC2131 saying:

	The server MUST return to the client:

      o The client's network address, as determined by the rules given
        earlier in this section,

   - DHCP relay is inserting DHCP options (CHAP, EAP) when relaying 
     messages to the DHCP client. Relay is not supposed to do that.

   - DHCP server receives the DHCPREQUEST but it does not respond to 
     it. Instead, DHCP relay generates the DHCPACK/DHCPNAK (See Figure 3).

   - DHCP relay is generating DHCP messages (see Figure 5). Relays
     are not supposed to do that. Although not documented yet, same 
     misbehavior is needed for EAP retransmissions, and re-authentication. 
     This is turning DHCP into a 3-party protocol.

   - RFC3118 cannot be used when DHCP relay inserts options towards DHCP
     client, removes options towards DHCP server, consumes some messages,
     generates some messages. Basically, this is breaking the end2end model.

   - DHCP server does not see the DHCPREQUEST, as it is consumed by 
     the relay (see Figure 5).

4. Failing DSLF requirements

   Despite the clear statements in the DSLF requirements, this proposal is
   not supporting authentication of the devices behind the HGW (CPE).
   Instead, authors are denying the requirements:

	IPAuth-8 Must handle L3 CPE device authentication and end-device
(PC) 
               user based authentication (likely with L2 CPEs in the latter 
               case)

	IPAuth-9 Should be simple to implement on client (PC or CPE)

   This is because it is not possible to modify deployed PC stacks with 
   that solution as DHCP is an internal part of the operating systems. On 
   the other hand, PANA can be supported at the application layer and it   
   does not require change to the IP stack.

5. IETF's IPR strategy

   IETF has already produced an IPR-free solution to this problem: PANA. Why

   should IETF not recommend use of PANA but instead rubber stamp an 
   IPR-encumbered solution?

6. Community pushback

   Several people (excluding all PANA-related people) already spoke against 
   it.

Under the light of these issues, it is not clear why IETF is even
considering standardizing such a solution at this point.

DSLF in its liaison letter said they were "seriously considering" using this
solution, not like "demanding it be standardized." It's perfectly fine if
IETF analyzes the solution and concludes it has serious issues, and responds
with another alternative for DSLF's consideration.

Regards,

Alper

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 4 Dec 2007 02:37:55 -0500

With regard to IPR on PANA and DHCP, my company has submitted an IPR
statement related to the ongoing discussion on DSL authentication on
October 23, 2007 (the statement does not seem to have been uploaded to
the IETF IPR disclosure page yet, so let me attach a copy of the IPR
statement).  On the other hand, I am not sure whether the patent
application indicated in the IPR statement is essential to the DSL use
case being discussed.

Regards,
Yoshihiro Ohba

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 4 Dec 2007 13:41:39 +0000

I support strongly Alper below and anytime we can avoid an IPR solution vs. IPR free we should always select the IPR free solution given they both resolve the problem.  I am also not convinced DHCP should be used for net access authentication.

Best,
/jim

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]]
> Sent: Tuesday, December 04, 2007 1:45 AM
> To: [email-masked]
> Subject: [Int-area] Why IETF should not standardize dhcp-auth
>
>
>         independently of the configuration mechanisms in use
> for the Internet
>         and higher layers.
>
>
> 2. IETF principle
>
> Under the light of these issues, it is not clear why IETF is
> even considering standardizing such a solution at this point.
>
> DSLF in its liaison letter said they were "seriously
> considering" using this solution, not like "demanding it be
> standardized." It's perfectly fine if IETF analyzes the
> solution and concludes it has serious issues, and responds

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 4 Dec 2007 09:22:41 -0500

IPR free is better, yes.  

But Alper himself is the sole inventor of US Pre-grant 20070028092:
"Method and system for enabling chap authentication over PANA without
using EAP" 
http://tinyurl.com/38k62e
If he has disclosed this on the IETF IPR site, I cannot find it.  This
is even after I directly emailed him about the problem in October (see
below).

It sickens me to see Alper claiming PANA as "IPR free".  

BTW: Alper's is not the only PANA patent submission you will see at:
http://appft1.uspto.gov/netahtml/PTO/search-bool.html

Eric

-----Original Message-----
From: Eric Voit (evoit) 
Sent: Friday, October 19, 2007 12:00 PM
To: Pekka Savola; Alper Yegin
Cc: 'Internet Area'
Subject: RE: [Int-area] DCHP-based authentication for DSL?

> From: Pekka Savola, October 19, 2007 5:10 AM
> To: Alper Yegin
> Cc: 'Internet Area'
> 
> On Fri, 19 Oct 2007, Alper Yegin wrote:
> > There does not appear to be a strong justification to hack DHCP the 
> > way you are proposing. Many people spoke against that already.
> 
> FWIW, Cisco has claimed IPR on the DHCP solution:
> 
> http://www1.ietf.org/ietf/IPR/cisco-ipr-draft-pruss-dhcp-auth-
> dsl-00.txt
> 
> I wonder if other solutions are similarly affected.
> 
> Just something to chew on when looking at potentially applicable 
> solutions...
> 

Well, since you brought it up...

Binding of DHCP and PANA...
http://tinyurl.com/yvjx9l

Triggering DHCP actions from IEEE 802.1x state changes...
http://tinyurl.com/2avgk2

If you spend ten minutes on the USPTO website, you will quickly see that
all of this technology has claims on it, far more than on the IETF IPR
website.

http://www.uspto.gov/patft/

"Results of Search in US Patent Collection db for:
(DSL AND Authentication): 953 patents."

"Results of Search in US Patent Collection db for:
((EAP AND Network) AND Access): 146 patents."

At least Cisco disclosed its IPR to the IETF.

Eric

> From: Bound, Jim, December 04, 2007 8:42 AM
> 
> I support strongly Alper below and anytime we can avoid an 
> IPR solution vs. IPR free we should always select the IPR 
> free solution given they both resolve the problem.  I am also 
> not convinced DHCP should be used for net access authentication.
> 
> Best,
> /jim
> 
> >    Defining a new protocol each time someone has another 
> solution is 
> > not
> >    EAP and DHCP do not stack up well because none of the 
> end points, 
> > state
> >      it. Instead, DHCP relay generates the DHCPACK/DHCPNAK 
> (See Figure 
> > 3).
> >
> >      generates some messages. Basically, this is breaking 
> the end2end 
> > model.
> >
> >                user based authentication (likely with L2 
> CPEs in the 
> > latter
> >                case)
> >
> >    that solution as DHCP is an internal part of the 
> operating systems. 
> > On
> >    the other hand, PANA can be supported at the application 
> layer and 
> > it
> > DSLF in its liaison letter said they were "seriously considering" 
> > using this solution, not like "demanding it be standardized." It's 
> > perfectly fine if IETF analyzes the solution and concludes it has 
> > serious issues, and responds with another alternative for DSLF's 
> > consideration.
> >
> > Regards,
> >
> > Alper
> >
> >
> >
> >

---

From: <[email-masked]>
Date: Tue, 4 Dec 2007 06:39:49 -0800

A (perhaps naïve) question:

Would the DSL Forum's needs be satisfied by publication of a non-standards 
track
document, specifying the CHAP approach?

If so, this might be worth exploring.  The CHAP approach would involve far 
fewer
(no?) changes to DHCP.   It could probably be completed relatively quickly 
(at
least on IETF time scales).   And if the goal is to enable a transition away 
from PPPoE,
having a solution available on a transitional time scale would seem to have 
some
value.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 4 Dec 2007 17:06:54 +0200

Eric,

Can you find any IPR on the PANA specification draft-ietf-pana-pana or any
other essential specification that is a dependency for DSLF or any other
SDO,etc. to implement PANA?

That's the question.

What you found below, and Toshiba's IPR are not on such specifications.
Those are just derivative works, none of which needs to be implemented by
DSLF. And no IETF work is impacted by them.

So, DSLF can implement the PANA solution without being encumbered by IPR.
That's the bottom line.

The same cannot be said about draft-pruss-dhcp-auth-dsl-02 because the IPR
is right on that I-D.

Alper

> From: Eric Voit (evoit) [mailto:[email-masked]]
> Sent: Tuesday, December 04, 2007 4:23 PM
> To: Bound, Jim; Alper Yegin
> Cc: [email-masked]
> Subject: RE: [Int-area] Why IETF should not standardize dhcp-auth
> 
> IPR free is better, yes.
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 4 Dec 2007 15:23:20 +0000

Eric thanks for sending this and that says a lot and good you said it.  I believe ERic no IPR should be permitted in the IETF at all.  I know I will never win that battle and don't want to start it again.  I think with all the IPR here eventually the IETF will loose yet another founding principle that is not written down but open systems standardization environment.

Alper I think you need to respond to this now in the community ????????????

/jim

> Sent: Tuesday, December 04, 2007 9:23 AM
> "Method and system for enabling chap authentication over PANA
> without using EAP"
> If he has disclosed this on the IETF IPR site, I cannot find
> it.  This is even after I directly emailed him about the
> problem in October (see below).
>
> If you spend ten minutes on the USPTO website, you will
> quickly see that all of this technology has claims on it, far
> more than on the IETF IPR website.
>
> > I support strongly Alper below and anytime we can avoid an IPR
> > solution vs. IPR free we should always select the IPR free solution
> > given they both resolve the problem.  I am also not convinced DHCP
> > should be used for net access authentication.
> >
> > Best,
> > /jim
> >
> > >    When it comes to solving "distinct" fundamental
> problems (e.g.,
> > > access
> > >         host configuration.  Network access
> authentication is best
> > > handled
> > >    principle, IETF should first make an attempt to see if
> it really
> > > does not
> > >
> > >    - RFC3118 cannot be used when DHCP relay inserts
> options towards
> > > DHCP
> > >    This is because it is not possible to modify deployed
> PC stacks
> > > with
> > >    Several people (excluding all PANA-related people)
> already spoke
> > > against
> > >    it.
> > >
> > >

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 4 Dec 2007 15:24:40 +0000

Thanks Alper I concur derivative works are not incumbent and it is actually nice that derivative works are identified and that should not be required by the IETF.  None of the IETFs  business if not in the spec.

/jim

> Sent: Tuesday, December 04, 2007 10:07 AM
> To: 'Eric Voit (evoit)'; Bound, Jim
> Cc: [email-masked]
> Subject: dhcp-auth IPR (was RE: [Int-area] Why IETF should
> not standardize dhcp-auth)
>
> Eric,
>
> Can you find any IPR on the PANA specification
> draft-ietf-pana-pana or any other essential specification
> that is a dependency for DSLF or any other SDO,etc. to implement PANA?
>
> That's the question.
>
> Those are just derivative works, none of which needs to be
> implemented by DSLF. And no IETF work is impacted by them.
>
> The same cannot be said about draft-pruss-dhcp-auth-dsl-02
> because the IPR is right on that I-D.
>
>
>
>
> Alper
>
> > > > There does not appear to be a strong justification to hack DHCP
> > > > the way you are proposing. Many people spoke against
> that already.
> > >
> > If you spend ten minutes on the USPTO website, you will quickly see
> > that all of this technology has claims on it, far more than on the
> > IETF IPR website.
> >
> > > >         Network access authentication is a distinct
> problem from
> > > > Internet
> > > >    This is because it is not possible to modify
> deployed PC stacks
> > > > with
> considering"

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 4 Dec 2007 11:27:50 -0500

I can certainly find a claim which would be needed by the DSLF.  I need
go no farther than Claim 1 of binding of DHCP and PANA... 
http://tinyurl.com/yvjx9l 

"1. A method for binding dynamic host configuration and network access
authentication, comprising: providing a network access authenticator to
authenticate at least one client device; providing a dynamic host
configuration server to dynamically distribute IP addresses for client
devices; maintaining synchronization of an authentication session
between the at least one client device and the network access
authenticator and a dynamic host configuration session between the
dynamic host configuration server and said at least one client device
when either an authentication session or a dynamic host configuration
session is lost."

So while neither DHCP nor PANA are encumbered by this specific claim,
making any usable deployment incorporating the two is.  This puts it in
the exact same position as DHCP-Auth & 802.1af in terms of IPR
implications for deployment.

Eric

> From: Bound, Jim, December 04, 2007 10:25 AM
> 
> Thanks Alper I concur derivative works are not incumbent and 
> it is actually nice that derivative works are identified and 
> that should not be required by the IETF.  None of the IETFs  
> business if not in the spec.
> 
> /jim
> 
> > Subject: dhcp-auth IPR (was RE: [Int-area] Why IETF should not 
> > standardize dhcp-auth)
> >
> > Eric,
> >
> draft-ietf-pana-pana or 
> > any other essential specification that is a dependency for 
> DSLF or any 
> > other SDO,etc. to implement PANA?
> >
> > That's the question.
> >
> implemented 
> > by DSLF. And no IETF work is impacted by them.
> >
> > So, DSLF can implement the PANA solution without being 
> encumbered by 
> > IPR.
> > That's the bottom line.
> >
> quickly see 
> > > > >    auth, mobility, configuration, QoS), IETF defines 
> "distinct"
> > > > > protocols
> > > > >      client, removes options towards DHCP server, 
> consumes some 
> > > > > messages,
> > > > >    Despite the clear statements in the DSLF 
> requirements, this 
> > > > > proposal is
> > > > >         IPAuth-9 Should be simple to implement on 
> client (PC or
> > > > > CPE)
> > > > >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 4 Dec 2007 12:10:35 -0500

Eric,

On Tue, Dec 04, 2007 at 11:27:50AM -0500, Eric Voit (evoit) wrote:
> making any usable deployment incorporating the two is.  

I think a deployment is possible without necessarily maintaining
synchronization between an authentication session or a dynamic host
configuration session when either session is lost, unless the
authentication session generates a key to secure the dynamic host
configuration session.

Yoshihiro Ohba

> This puts it in

---

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Dec 2007 09:22:32 -0800

Time for my be-careful-with-the-IPR-discussion warning again.

Possible IPRs are an important concern in making standardization
decisions. The community needs to take them into account among other
factors in the discussion. However, you are also advised to weigh these
factors only after a careful consideration, not jump into conclusions,
and if needed, employ assistance in evaluating what the implications
might be. Some of the things that you have to take into account include:

- whether the claimed IPR actually would be held up
- whether lack of IPR claims actually means you have no IPR issues
- what the licensing terms are

For instance, I would personally not consider licensing terms such as
non assert (what was used here) a problem at all for doing my vendor or
public domain work. Then again, in an "IPR free" solution there could be
ten other unknown ones that could prove to be blocking for my work.

I would also like to request that generic discussion about IETF IPR
policies be held elsewhere, e.g., in the IPR WG.

Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 4 Dec 2007 19:48:06 +0200

> authentication session generates a key to secure the dynamic host

Even if the authentication session generates a session key for DHCP, I don't
think this IPR gets in the way. We had published an I-D that generates DHCP
keys from EAP, and that predates the aforementioned IPR. As the initiator of
that work I can say my employer at that time did not file any IPR on it, and
I'm not aware of any claimed IPRs on it either.

http://www.watersprings.org/pub/id/draft-tschofenig-pana-bootstrap-rfc3118-0
0.txt

Alper