Subject: [dhcwg] pana-bootstrap-rfc3118

From: Alper Yegin <[email-masked]>
Date: Tue, 05 Aug 2003 11:36:20 -0700

From the DHC WG meeting notes:

    RFC3118 Delayed Authentication Using PANA          H. Tschofenig
    <draft-tschofenig-pana-bootstrap-rfc3118-00.txt>

    This document describes a mechanism for establishing a DHCP SA
    (between client and server) through PANA (assuming PANA is invoked
    before DHCP).  The scenario is:

       * host establishes SA with PANA
       * PAA does key distribution to host and DHCP server
       * host and server use key for authenticated DHCP

    There was some discussion about the mechanism through which the PAA
    would get keying information to the DHCP participants.  The WG
    requested that the draft be revised to provide additional detail,
    and will reconsider the draft after the revisions are published.

Before we produce the next rev of the draft, we'd like to fully understand
what should go in. So, let's continue the discussions from where we left at
the meeting.

Here are the points we discussed at the meeting. We are sure we missed some,
please add...

- How is the DHCP SA key transferred from DHCP relay (PAA) to DHCP server?

  The DHCP architecture already has the concept of carrying client-specific
  data from the dhcp relay to dhcp server after the network access AAA
  (draft-ietf-dhc-agentopt-radius-02.txt). This client-specific key should
  also be carried along with that data. Our draft is missing the details of
  this sub-option, we should include this in the next version.

  Security of the keys can be ensured by using IPsec with ESP as outlined in
  draft-ietf-dhc-relay-agent-auth-01.txt.

- What module is running where?

  PAA has to be on the same IP-hop as the client. It can be colocated with
  the DHCP server if the server is on the last hop. If DHCP server is
  somewhere behind, and there is a DHCP relay on the last hop, then PAA can
  be colocated with the DHCP relay. PAA module has to communicate with the
  colocated DHCP module (server or relay) in order to pass the DHCP SA. They
  don't have to be implemented in the same module, they can be (and would
  be) separate processes. We shall clarify this better in the next rev.

Are there any other concerns/comments/questions?

Alper, on behalf of the authors of the draft

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

---

From: John Schnizlein <[email-masked]>
Date: Tue, 05 Aug 2003 15:04:15 -0400

>what should go in. So, let's continue the discussions from where we left at

My impression was that the concerns about this draft went much deeper
than editing-in more text could repair.

There is the issue that PANA does not have Security Area endorsement
to be a key-distribution protocol.

There is an irony in that PANA, which was justified as different from
IEEE 802.1X by hosts having IP addresses first (not layer 2), is 
proposed to operate before DHCP, which provides the IP address.

There is (at least) intolerable complexity in the cooperation of
the DHCP relay agent, which does not participate in the client-server
message authentication for which PANA proposes to provide keys.

I thought the consensus was that the WG not take on this work.

John

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 05 Aug 2003 13:55:36 -0700

> message authentication for which PANA proposes to provide keys.

Could you elaborate more on the complexity?  This is because I'm
interested in implementing the proposed scheme and I am viewing that
the complexity is acceptable and reasonable.

Bootstrapping DHCP authentication from AAA is useful and needed where
PKI (via DNSSEC) is not available (and DNSSEC is not available in many
situations).  I believe that pana-bootstrap-rfc3118 is a practical
solution and would like to see it becoming a WG item.

Yoshihiro Ohba

---

From: John Schnizlein <[email-masked]>
Date: Tue, 05 Aug 2003 16:58:02 -0400

As I understand what was proposed, PANA would provide the keys
necessary for DHCP authentication (message integrity) between
the DHCP client and DHCP server. 

The complication is that this does nothing to protect the 
integrity of the relay-agent information options. To protect
those options also, there must be some interaction between
PANA components and the relay agent. Nobody has shown how this
would work, and entanglements of multiple intermediate parties
is known to be a complex problem in networking.

John

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 05 Aug 2003 14:25:29 -0700

> is known to be a complex problem in networking.

As Alper mentioned in the previous mail,
draft-ietf-dhc-relay-agent-auth-01.txt can be used for securing the
relay agent options and that seems to be enough.  Why interaction
between PANA components and the relay agent is needed for securing the
relay agent options?  I believe securing the relay agent options can
be independent of PANA.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 05 Aug 2003 14:59:55 -0700

Hi John,

> to be a key-distribution protocol.

PANA is not "a key distribution protocol", it does not carry keys. It
carries EAP. A set of EAP methods are capable of deriving/distributing keys.

There is an EAP key framework (draft-aboba-pppext-key-problem-07.tx ) that
explains how the EAP SA keys (such as MSK) can be turned into some
purpose-specific keys (TSKs). This is what IEEE 802.11i is already using.
Creation of a DHCP SA from EAP SA is just another instance of this
framework.

> proposed to operate before DHCP, which provides the IP address.

Well, we discussed this at least couple of times by now. The relevant
question is: Can PANA be used before the client has an IP address? The
answer is yes.

> message authentication for which PANA proposes to provide keys.

I don't understand where this intolerable complexity is coming from, I'll
follow the other thread for this...

> I thought the consensus was that the WG not take on this work.

... yet. The decision was not to reject this work, but to consider it later.
I think this was due to the on-going (or, just-started :) discussions and
lack of eligible voters.  How can that consensus call result be useful
anyways, when there were only 7 people's hand raised when the chair asked
who read the draft :)

Alper

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 06 Aug 2003 09:22:49 +0200

--On Dienstag, 5. August 2003 15:04 -0400 John Schnizlein 
<[email-masked]> wrote:

[...]
|
| I thought the consensus was that the WG not take on this work.

The consensus was not to take the document as working group draft as this 
point
of time, but to consider it later after a revision.

Martin

|
| John
|
|
| _______________________________________________
| dhcwg mailing list
| [email-masked]
| https://www1.ietf.org/mailman/listinfo/dhcwg

Martin Stiemerling

NEC Network Laboratories

---

From: Mark Stapp <[email-masked]>
Date: Wed, 06 Aug 2003 10:34:16 -0400

> > to be a key-distribution protocol.

John's point about the pana charter is accurate. The ietf has not chartered 
pana to do key-distribution, nor has it ensured that the appropriate expert 
review will take place. If pana would like to go through a re-charter, 
expanding in this way, then that's a process that should take place 
explicitly, with the iesg, the security directorate, and the pana wg. That 
would give other groups confidence in pana-centric solutions. It's not 
appropriate for this expansion to take place implicitly.

>Creation of a DHCP SA from EAP SA is just another instance of this

I'd like to see a draft describing the use of EAP to address the 
authentication and 3118 issues. This would allow dhcp to leverage any 
carrier of EAP, which would be much more attractive than tying dhcp to 
pana. If the EAP-based mechanism could be successfully and convincingly 
described, various EAP carriers could then propose more specific drafts 
detailing the use of their protocols within the broader framework. The 
pana-only draft puts the cart before the horse. The implication - 
intentional or otherwise - is that the only way to use EAP is to use pana. 
That is not correct.

Since there are many millions of EAP-speakers who are also dhcp clients, a 
broad EAP-based approach would be more practical and more appropriate to 
standardization. I would expect us to consider something like 'to leverage 
the broad deployed base of EAP-capable clients' on any list of dhcp 
security or authentication requirements. I would not expect to find 'to 
leverage the world's pana speakers' on that list.

It concerns me that the working group will expend security effort on the 
'pana-only' approach, when all of the clients are speaking something else. 
I think that will distract us from the broader effort to make dhcp more 
secure in practical, deployable ways. And that needs to be the goal of work 
that the group invests time on, not making dhcp more secure in a world 
filled with pana speakers. Pana is sort of like esperanto - it's not that 
it might not work as well as the alternatives one day, and it's not that it 
doesn't have _any_ merit at all, but it's still entirely marginal.

>question is: Can PANA be used before the client has an IP address? The

But the rest of the world has sort of spoken up here, hasn't it? The fact 
that people in the ietf can make up more 'me too' EAP carriers doesn't 
change the situation in the field.

>follow the other thread for this...

This issue was raised during the wg meeting as well, I believe. What was in 
the draft that I read did not contain any details about this interaction, 
except that it would be best if all the dhcp relays were pana agents too. I 
didn't find that to be convincing.

>anyways, when there were only 7 people's hand raised when the chair asked

Well I read the draft, and if you can tell me why it's pana that I want, 
I'm all ears. And it's consensus, not a vote. If there isn't interest in a 
proposal, if there isn't consensus that a draft solves the problem it 
claims to solve, it goes away. If there were seven people who read the 
draft that I read, I didn't hear any advocates for it at the working group 
meeting, and I haven't seen any advocates for it on the list.

-- Mark

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 06 Aug 2003 09:33:05 -0700

As you mentioned, PANA is not the only way to bootstrap a DHCP SA from
an EAP SA.  IEEE 802.1X could also be used in the same way if relay
agents are co-located with IEEE 802.1X Authenticators.  Then one
constructive approach might be to work on "Bootstrapping RFC3118
Delayed authentication using EAP" (where s/PANA/EAP/), which can cover
broader EAP usage models.

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Wed, 06 Aug 2003 11:42:13 -0700

> appropriate for this expansion to take place implicitly.

Please see my response to John. The mechanisms behind your so-called key
distribution are EAP methods and EAP keying framework.

> intentional or otherwise - is that the only way to use EAP is to use pana.

Well, our draft shows how this is done using PANA and EAP. It is not meant
to prove this is the only way possible. Both relevant PANA details and EAP
key derivation details are in the draft. As such, this is a complete
solution. I don't see a problem with that.

If you believe doing the same for 802.1X/PPP/IKEv2 is possible and
beneficial, please write a draft and show us the same can be done there.
This would be more productive.

> leverage the world's pana speakers' on that list.

This doesn't seem to point any technical issues with the proposal.
 
> doesn't have _any_ merit at all, but it's still entirely marginal.

A couple of things are confused here. We are showing how you can enable DHCP
security by using PANA. This draft does not dictate the world to move away
from whatever else they were doing for AAA. If they do, that'd be their
choice, but not a requirement of this solution.

> change the situation in the field.

I don't see the relevance of this to what we are discussing above.

> This issue was raised during the wg meeting as well, I believe.

Saying a solution is complex is for-free. We are still waiting for an
explanation why some said so. You don't seem to explain either.

> What was in 

What part is not convincing? Please see my first message on this thread.

> meeting, and I haven't seen any advocates for it on the list.

None of the things you mentioned in this message is about technical problems
with our proposed solution. Do you see a technical problem with the
solution, do you think it fails to solve the problem? Let's discuss them.

On the other hand, the issue you are raising is more like why not do the
same with other EAP transports. Well, please write a draft and we can talk
about them too. 

Alper