[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOKEY] WGLC: draft-ietf-hokey-preauth-ps-02
Subir,
Please see my resonse below.
On Thu, Apr 10, 2008 at 01:55:50AM -0400, Subir Das wrote:
(snip)
> >
> >> It is assumed that there
> >> is at least one candidate authenticator in each candidate access
> >> network while the serving access network may or may not have a
> >> serving authenticator.
> >>
> >> SD> Is it true that serving network may not have a serving authenticator?
> >> If it is true, how come in the first case it enters into the network? Is serving network is an open network? If so, is it a valid handover scenario and is EAP pre-authentication applicable there? Also use case scenario does not cover it.
> >>
> >
> > The serving network could be an open access L2 network and may be
> > using http authentication. Also there may be no roaming agreement
> > between the serving and target networks. EAP pre-authentication is
> > applicable to such scenarios.
> >
> SD> This scenario is possible and the target network may require EAP
> authentication and can be done
> via pre-authentication but I was thinking how much it is relevant in
> terms of seamless handover.
> For example, if the two networks does not have roaming agreement, can a
> seamless handover
> possible in real case? Also if it is a managed network, is it not fair
> to assume that both serving and
> target networks will have EAP authentication? Just a point to think.
> >
This is a very good point. I would say it depends on solutions. For
example, a solution such as draft-irtf-mobopts-mpa-framework that does
not require roaming agreement. On the other hand, other solutions
that use interworking gateways will require roaming agreement. We can
add some text about this for fair analysis.
(snip)
> >> 5. Architectural Considerations
> >>
> >> There are two architectural issues relating to pre-authentication,
> >> i.e., authenticator discovery and context binding.
> >>
> >> SD> Is context binding an architectural issue or a general issue? Location of target authenticator may have some architectural implications. How about transport?
> >>
> >
> > The context binding issue is specific to L3 pre-authentication, and
> > not a general issue. Transport (direct or indirect) does not have
> > architectural implications in terms of context binding.
> >
> SD> I did not mean to say that transport has architectural relationship
> with context binding. May be I
> should have been a little bit clear. Three questions: i) If context
> binding is a general issue, does it fit under
> architectural issue section? ii) Does transport of pre-auth parameters
> has any architectural impacts?, and
> iii) Does location of target authenticator has any architectural impacts?
For i), it is specific to L3 pre-auth as I mentioned, so it fits under
this section. For ii), there is no architectural impact. Once
context binding issue is resolved at the architecture level, then
there can be several choices on transport. Designing a new transport
can be one choice, reusing an existing transport can be another. For
iii), as long as authenticator is defined as a logical functional
element as defined in RFC 3748, the location of target authenticator
does not have an architectural impact at logical level. This problem
statement is dealing with architectural issues at that level.
However, when we start to talking about how authenticators are mapped
to physical elements such as BS/AP and access controllers, then there
can be an architectural impact at physical level, but I believe that
architectural issues at that level can be better addressed in SDO that
defines a solution for the L3 preauth problem.
>
> >
> >
> >> When pre-authentication is used for inter-
> >> technology or inter-subnet handover, a candidate authenticator needs
> >> to have a global IP address and a mechanism for discovering the
> >> candidate authenticators IP address is needed.
> >>
> >> SD> Does it always require to have a global IP address even if serving and candidate authenticators are within one operator?s domain
> >>
> >
> > A global address may not be needed for intra-domain handover. We can
> > revise the text to:
> >
> > "
> > When pre-authentication is used for inter-technology or inter-subnet
> > handover, a candidate authenticator needs to have an IP address and a
> > mechanism for discovering the candidate authenticators IP address is
> > needed. For inter-domain handover, the IP address of a candidate
> > authenticator needs to be global unique.
> >
> SD> May we should say "For both intra-domain and inter-domain handover,
> the IP address of a candidate
> authenticator must be reachable by the mobile node that is performing
> the pre-authntication " something
> like that...
> > "
OK.
> >
> >
> >> For example, IEEE
> >> 802.21 Information Service (IS) [802.21] provides a link-layer
> >> independent mechanism for obtaining neighboring network information
> >> by defining a set of Information Elements (IEs), where one of the IEs
> >> is defined to contain an IP address of a point of attachment. IEEE
> >> 802.21 IS queries for such an IE may be used as a method for
> >> authenticator discovery.
> >>
> >>
> >> An authenticator discovery mechanism requires a database on the
> >> neighboring network information. Provisioning of a server with such
> >> a database is another issue.
> >>
> >> SD> The above is a solution and does it require to have in the problem statement document?
> >>
> >
> > The above paragraph was added based on Ajay Rajkumar's review. I
> > think this is a good to have, while I agree with you that it is not
> > mandatory to have in the problem statement document.
> >
> SD> Ok. May be we can say in preamble, if 802.21-based or similar
> mechanism is used.....
We will add such a preamble.
> >> 5.2. Context Binding
> >>
> >> When a candidate authenticator uses different EAP transport protocols
> >> for normal authentication and pre-authentication, a mechanisms is
> >> needed to bind link-layer independent context carried over pre-
> >> authentication signaling to the link-layer specific context of the
> >> link to be established between the mobile node and the candidate
> >> authenticator.
> >>
> >> SD> Is it true that this context binding needs to happen after the handover?
> >> If so it may be appropriate to reflect that in the last sentence of the above paragraph.
> >>
> >
> > Context binding can happen before handover.
> >
> SD> Does this mean it can happen after handover too. If so, may be it
> should clarify both options.
OK, we will add clarification text on this.
> >
> >> The link-layer independent context includes the
> >> identities of the peer and authenticator as well as the MSK. The
> >> link-layer specific context includes link-layer addresses of the
> >> mobile node and the candidate authenticator.
> >>
> >> There are two possible approaches to address the context binding
> >> issue. The first approach is based on communicating the lower-layer
> >> context as opaque data via pre-authentication signaling and perform
> >> the link-layer specific secure association procedure after handover.
> >> The second approach is based on running EAP over the link-layer of
> >> the candidate authenticator after handover using short-term
> >> credentials generated via pre-authentication, followed by the link-
> >> layer specific secure association procedure. In this case, the
> >> short-term credentials are shared between the mobile node and the
> >> candidate authenticator, and hence the EAP server for the post-
> >> handover EAP resides in the candidate authenticator.
> >>
> >> SD> Last part of the above sentence is not clear.
> >>
> >
> > The last part means that post-handover EAP terminates between MN and
> > CA, and does not require AAA signaling.
> >
>
> SD> Does this mean the target network does not have a AAA server? If
> that is the case, it may be good
> to clarify it.
The target network has access to a AAA server, but the target
authenticator does not need to communicate with the AAA server for
authenticating the MN after handover. That is the whole point of
pre-authentication.
> >
> >> In both
> >> approaches, the binding needs to be securely made between the peer
> >> and the candidate authenticator using a security association
> >> established via pre-authentication.
> >>
> >>
> >> 6. AAA Issues
> >>
> >> Most of the AAA documentations today do not distinguish between a
> >> full authentication and a pre-authentication and this creates a set
> >> of open issues:
> >>
> >> Pre-authentication authorization: Many users may not be allowed to
> >> have more than one logon session at the time. This means, when
> >> such users actively engage in an active session (as a result of a
> >> previously valid authentication), they will not be able to perform
> >> pre-authentication. The AAA server currently has no way of
> >> distinguishing between a full authentication request and a pre-
> >> authentication request.
> >>
> >>
> >> SD> The assumption here seems to me that mobile node has performed the network access authentication in the first place. Therefore, the earlier statement saying that serving network may or may not have an authenticator is not correct. Pl. refer to earlier comment on this as well.
> >>
> >
> > I don't think this contradicts with the earlier statement. If there
> > is no authenticator in the serving network, then the mobile node will
> > be able to perform pre-authentication to the target network even if
> > the AAA server does not allow more than one logon session. In other
> > words, there is no logon session before pre-authentication in this
> > case.
> >
>
> SD> Does that mean if the serving network does not have an authenticator
> that interacts with AAA,
> multiple logons is a non-issue? If that is the case and we allow such a
> scenario (e..g, serving network
> does not have an authenticator), this AAA issue is not a general issue.
Multiple logons is a non-issue if MN uses different subscriptons for
the serving and target networks. If MN uses the same subscription for
the serving and target networks, multiple logons can be an issue
regardless of whether there is a serving authenticator or not.
We can add clarification text about this.
Thanks,
Yoshihiro Ohba
_______________________________________________
HOKEY mailing list
HOKEY at ietf.org
https://www.ietf.org/mailman/listinfo/hokey