I think the confusion and complexity that I perceive comes from the
fact that the framework problem treats all the tasks (user
authentication, network selection, and securing the network
connection as being of the same significance or same relationship to
the solution.
I think that most of the discussion of IPSec and pre-post PANA
addresses does not belong here at all.
Let me suggest an approach that might simplify and shorten the document:
[Unfortuantely, I can't promise that it will fix everyone's problems.]
2. Describe the primary goal of PANA, and approach thereto. This
would state that the goal is to authenticate the user using an IP
level protocol. This would probably state that the primary approach
is to proivde a transport for EAP that meets the requirements for an
EAP transport [cite RFC.]
3. Describe very briefly the interaction between the EP and the
PAA. State that the protocol between them is out of scope. Note
that the EP must allow PANA messages to the PAA before authentication
is completed. (Yes, that's obvious, but it is actually worth stating.)
4. Describe that PANA protocol needs to provide for negotiation of
information before authentication. List briefly some of the things
to be negotiated (services available, algorithms available.) Also
indicate that the PANA protocol can provide additional
post-authentication information to the client (in the PANA response)
and to the EP.
Securing the data channel between the PCC and the EP should be out of
scope. If you want to say anything about that, you might note that
this may be done in a link specific fashion, in may be done with an
unauthenticated IP exchange before PANA, or PANA may be used to carry
additional credentials / keys to be used to establish an
authenticated secure association. The reason I would not include
this is that the question of why I need an authenticated exchange
will complicate the document. The other reason for not describing it
is that it does not change the framework at all, and should be
documented as a usage of PANA capabilities, in its protocol RFC.
I would then probably dramatically reduce section 10. Trying to
describe all those cases does not actually help the reader get the
mental model. And I think they are too deployment specific.
The real key here is to focus on the primary goal. The resulting
document ought to be clearer, and focused on the problem that needs
to be solved. It can indicate that PANA can be used to help other
things, but that those things are not the purpose / point of PANA.
At 12:29 AM 5/30/2006, Yoshihiro Ohba wrote:
Hi Joel,
Thank you for spending your time reading the framework document and
sending your feedback. Please see my response below.
On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote:
> In reading the PANA Framework document, what I read seemed to me to
> be more of a "system" or "solution" document than a clean IETF
> protocol framework.
I think your reading is correct. The document describes how different
types of access network deployments are enabled by PANA.
>
> I saw efforts to address three different problems:
> 1) Securing an otherwise unsecured link, when the access node is not
> known to the client in advance.
> 2) Selecting an authorization (charging, possibly packet handling) service
Just to make sure, do you mean by 2) network selection that is
described in Section 8 of pana-framework draft?
> 3) Authenticating the user
>
> EAP over IP (or UDP, or link) is about authenticating the user. If a
> media independent technique better than just using a browser is
> needed, then solve that problem.
This is surely one problem PANA is trying to solve, and has been
clarified from the beginning of the work and more in this dicussion, I
believe.
> Personally, I would find the work
> far more persuasive if it did not also try to solve the problem of
> creating an IPSec association to the access device, nor of the
> authorization selection problem.
Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering)
from EAP-based network access authentication is another problem. When
a lower-layer does not provide EAP service, it is clear that PANA is a
standard way to solve the problem. Perhaps the main confusion is
coming from the fact, as a side effect of solving this bootstrapping
problem, that it is possible to use PANA to bootstrap lower-layer
ciphering *even if the lower-layer supports EAP*. While I understand
the confusion but let me explain several reasons for why I think this
is still viable for lower-layers that support EAP.
- Use of PANA for bootstrapping IKEv2. I explained several reasons
for why doing this while IKEv2 can carry EAP, in my response to Vidya:
http://www1.ietf.org/mail-archive/web/ietf/current/msg42002.html.
- Use of PANA for bootstrapping IEEE 802.11i PSK mode. This makes APs
and non-AP STAs that support 802.11i but do not support 802.11r can
transit from one AP to another without necessarily perform EAP for
every AP transition as long as the APs are acting as EPs of the same
PAA. One may argue that this usage becomes useless when all APs and
non-AP STAs are migrated to 802.11r, but it is still possible to use
PANA for inter-ESS transition which is not covered by 802.11r.
>
> And spell out in clear English what use case needs that problem
> solved. I can read between the lines and start to guess. But the
> document is quite unclear. The appendix about DSL is not helpful in
> that regard.
One of the reasons for this may be that the problem statement and
requirements are described in a separate RFC (i.e., RFC 4058) not in
the pana-framework draft. Of course another reason may be that I, the
editor of the draft, am not a native English speaker.
BTW, there is no appendix in pana-dramework draft. So you may refer
to Section 10.1 about DSL. Is this correct?
I hope this sheds some light on the discussion.
Yoshihiro Ohba
>
> Yours,
> Joel M. Halpern
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf