Subject: [HOKEY] Re: EAP Pre-authentication Problem Statement: Review request

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 9 Oct 2007 23:59:12 -0400

Hi Ajay, 

Thank you for posting your comments to the HOKEY list.

Please see my comments inline.

> Yoshi,
> 
> As desired sending these comments to the HOKEY list as well.
> 
> Best Regards,
> -ajay
> 
> ------------------------------------------------------------------------
> Comments:
> 
> *Section 3, Page 4, second paragraph:*
> 
> In the sentence “For example, if a mobile only requires….” The word
> “require” implies it is a requirement whereas the implication is a
> “need” so change the word to “needs”.

Sure, s/requires/needs/.

> 
> *Section 5.1:*
> 
>  - The argument regarding authenticator discovery in the second
> paragraph seems to be circular. The problem is to discover candidate
> authenticators. If the candidate authenticator uses link-layer EAP
> transport then how it would use the link-layer based EAP transport for
> pre-authentication until the link-layer association has been
> established. However, for inter-technology case (which is being
> considering here) one could not assume that a link-layer has already
> been established, in fact the pre-authentication is to initiate
> link-layer association, so the above would not be a valid case for
> inter-technology pre-authentication.

The first sentence of the second paragraph is for link-layer
pre-authentication such as 802.11i pre-authentication.  On the other
hand, Section 3 explicitly mentions that link-layer pre-authentication
is out of the scope of the document.  So I agree that Section 5.1
should be revised to exclude link-layer pre-authentication discussion
which is out of scope of this document.  How about revising Section
5.2 as follows?

"
5.1.  Authenticator Discovery

   In general, pre-authentication requires an address of a candidate
   authenticator to be discovered either by a mobile node or by a
   serving authenticator prior to handover.  An authenticator discovery
   protocol is typically defined as a separated protocol from a pre-
   authentication protocol.  When pre-authentication is used for
   inter-technology or inter-subnet handover, a mechanism for
   discovering an IP address of a candidate authenticator is needed.
   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 discovering an IP address of a candidate
   authenticator.
"

> 
>  - Pre-configuration of some sort is always an option. This could be
> either achieved by storing information in a DHCP server, DNS server,
> 802.21 IS server, etc. However, the notion that authentication discovery
> is a problem implies that it needs to be solved with dynamic discovery
> protocols and not with static configuration; else it can pose a scaling
> issue.

I agree that provisioning of the servers that provide the
authenticator discovery service is always an issue.  We can mention
this issue in Section 5.1 as an open issue.

> 
>  - Does one have to have pre-defined security associations between the
> serving and the candidate networks to achieve pre-authentication? If so,
> would we encounter scaling issues due to pre-defined SAs?

There is no need for security associations between the serving and
candidate authenticators basically because EAP is designed to operate
over unprotected links.  Considering that the actual threat here is a
DoS attack by attackers in arbitrary networks trying to start a large
number of pre-authentication sessions with a candidate authenticator,
I think that non-cryptographic traffic filtering is sufficient for the
serving authenticator to accept pre-authentication signaling messages
received from a specific set of serving authenticators only.

> 
>  - Besides, scalability would be an issue for inter-security-domain
> pre-authentication, where the two authenticators (serving and candidate)
> are attached to two different authentication servers. 

This scalability issue is generally solved by use of AAA proxies
between the domains.  On the other hand, there is an (open) issue in
key distribution with AAA proxies.  However, this draft would not be
the right place to discuss this specific issue.

> 
>  - In the same section, it is mentioned that an IEEE 802.21 Information
> Server provides an IP address of a Point of Attachment (PoA). An 802.21
> IS would not be able to provide an IP address of a PoA unless a PoA is
> also an L3 point of attachment, (e.g., most APs in 802.11 network are L2
> access points). Similarly, if the access network has its own private
> network then a private IP address does not serve any useful purpose and
> would not be provided by the Information Server.

I agree that a PoA may not have an IP address and pre-authentication
scenarios described in the draft cannot be supported for such a PoA.
I also agree that IP addresses provided by authenticator discovery
would need to be global ones.  We can clarify those points in the next
revision.  On the other hand, I don't think a PoA that has an IP
address has to be an L3 PoA or an access router, or I may be
misunderstanding the definition of L3 PoA.

> 
> *Appendix:*
> 
> In the statement "access mechanism (e.g., CDMA, CSMA/CA, TDMA)," CSMA/CA
> is not an access mechanism, rather it is a probabilistic MAC protocol.
> The others, such as CDMA, TDMA, etc. are Physical layer access methods.

OK.  We will revise the text accordingly.

> 
> *General Comment:*  One question regarding pre-authentication that has
> not been addressed in this draft as part of the problem statement is the
> fact that currently most link-layer technologies have layer-2
> authentication mechanism embedded in the implementation of that specific
> link-layer. In this draft it seems that it has been assumed that there
> are common authentication credentials across all link-layer
> technologies. Is that a practical assumption? What is the basis of our
> pre-authentication over the target technology ? i.e., is it a layer-2
> credential such as X.509 certificate used in 802.16 or some generic MN-ID?

The draft does not assume common authentication credentials across all
link-layer technologies.  It assumes a common authentication mechanism
(i.e., EAP) that works across multiple link-layer technologies.  As
long as EAP is supported, any types of authentication credentials that
usable in EAP methods can be used in this pre-authentication
framework.

Best Regards,
Yoshihiro Ohba

> 
> -----------------------------------------------------------------------
> 
> Yoshihiro Ohba wrote:
> > Ajay,
> >
> > Thank you for accepting the review request.  
> >
> > Please send your review comments to me or directly to the HOKEY
> > mailing list where the comments will be discussed.
> >
> > Yoshihiro Ohba
> >
> >
> >   
> >
> 

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

---

From: Ajay Rajkumar <[email-masked]>
Date: Mon, 08 Oct 2007 13:20:18 -0400

Yoshi,

Best Regards,

-ajay

Comments:

Section 3, Page 4, second paragraph:

In the sentence “For example, if a mobile only
requires….”
The word “require” implies it is a requirement whereas the implication
is a
“need” so change the word to “needs”.

Section 5.1:

- The argument regarding authenticator discovery
in
the second
paragraph seems to be circular. The problem is to discover candidate
authenticators. If the candidate authenticator uses link-layer EAP
transport then
how it would use the link-layer based EAP transport for
pre-authentication until the link-layer
association has
been established. However, for inter-technology case (which is being
considering here) one could not assume that a link-layer has already
been established, in fact the pre-authentication is to initiate
link-layer association, so the above would not be a valid case for
inter-technology
pre-authentication.

- Pre-configuration of some sort is always an
option. This
could be either achieved by storing information in a DHCP server, DNS
server,
802.21 IS server, etc. However, the
notion that authentication
discovery is a problem implies that it needs to be solved with dynamic
discovery protocols and not with static configuration; else it can pose
a
scaling issue.

- Does one have to have pre-defined security
associations
between the serving and the candidate networks to achieve
pre-authentication?
If so, would we encounter scaling issues due to pre-defined SAs?

- Besides, scalability would be an issue for
inter-security-domain pre-authentication, where the two authenticators
(serving and
candidate)
are attached to two different authentication servers.

- In the same section, it is mentioned that an
IEEE
802.21
Information Server provides an IP address of a Point of Attachment
(PoA). An
802.21 IS would not be able to provide an IP address of a PoA unless a
PoA is
also an L3 point of attachment, (e.g., most APs in 802.11 network are
L2 access
points). Similarly, if the access network has its own private network
then a
private IP address does not serve any useful purpose and would not be
provided by
the Information Server.

Appendix:

In the statement "access mechanism (e.g., CDMA,
CSMA/CA, TDMA)," CSMA/CA is not an access mechanism, rather it is a
probabilistic MAC protocol. The others, such as CDMA, TDMA, etc. are
Physical
layer access methods.

General Comment:  One
question regarding pre-authentication
that has not been addressed in this draft as part of the problem
statement is
the fact that currently most link-layer technologies have layer-2
authentication mechanism embedded in the implementation of that
specific
link-layer. In this draft it seems that it has been assumed that there
are
common authentication credentials across all link-layer technologies.
Is that a practical
assumption? What is the basis of our pre-authentication over the target
technology – i.e., is it a layer-2 credential such as X.509 certificate
used in
802.16 or some generic MN-ID?

Yoshihiro Ohba wrote:

Ajay,

Yoshihiro Ohba