Subject: [HOKEY] comments on draft-ietf-hokey-preauth-ps-00

From: komarova <[email-masked]>
Date: Mon, 08 Oct 2007 16:42:13 +0200

Dear Yoshihiro,
I have some comments and questions on the draft-ietf-hokey-preauth-ps-00.

*Abstract*

EAP pre-authentication is defined as the utilization of EAP to pre-

   establish EAP keying material on an authenticator prior to arrival of the peer at the access network managed by that authenticator.

Does the authenticator manage the access network? Wouldn’t it be better 
to use the word “served” or “belongs to”?

*Section 3. *
Figure 1 : with respect to Section 6 (AAA issues) the second AAA server 
can be added.

*Section 4.2* Indirect pre-authentication

Indirect pre-authentication
 is needed if ... IP communication is not allowed between the candidate authenticator and unauthorized nodes for security reasons.

In this case the assumption about the absence of trust relations between 
the serving and the candidate authenticators (Section 3) is not valid.
Several assumptions and usage scenarios are needed to be added to this 
section. Under what conditions the serving authenticator will transmit 
pre-authentication signaling to the candidate authenticator?
Why the serving authenticator is authorized to the candidate 
authenticator while the MN is unauthorized?

The serving authenticator may not be trustworthiness in case of indirect 
pre-authentication. The serving authenticator is able to modify the 
information coming from the candidate authenticator. Should end-to-end 
integrity protection be added to communication between the MN and the 
candidate authenticator?

*Section 5.1* Authenticator discovery
Are there any other mean to discover a candidate authenticator besides 
802.21 IS?

*Section 5.2* Context binding
When the security context is transferred as an opaque data, the 
candidate authenticator should be able to interpret it. Are any changes 
to the authentication protocol and to the authenticator functionality 
needed?
If normal EAP authentication is performed after handover, what are 
recommendations for the authentication session lifetime? Any security 
violations related to re-using the key material?
What exactly does it mean “on use of normal EAP authentication after 
handover”? Should normal authentication start after setting up L2 or L3 
connectivity or after session resumption? What party (the authenticator 
or the peer) initializes normal EAP authentication?

Thanks

Best regards,
Maryna Komarova

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

---

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

Hi Maryna,

Thank you for reviewing the draft.   Please see my comments inline.

On Mon, Oct 08, 2007 at 04:42:13PM +0200, komarova wrote:
>   establish EAP keying material on an authenticator prior to arrival of the 
>   peer at the access network managed by that authenticator.
> 

I agree that the term "served" is better.

> Figure 1 : with respect to Section 6 (AAA issues) the second AAA server 

Since Figure 1 is describing Functinoal Elements, I think single AAA
server functional element is ok to cover multiple AAA server nodes.

> is needed if ... IP communication is not allowed between the candidate 
> authenticator and unauthorized nodes for security reasons.
> 

Those are good points.  I agree that the serving authenticator may not
be trustworthy in the case of indirect pre-authentication.  On the
other hand, there is not much difference between indirect and direct
pre-authentication (and between any pre-authentication and normal
authentication) with regard to message modification attack.  Since EAP
is supposed to work over unprotected links, I don't think we need a
cryptographic protection mechanism for pre-authentication forwarding
between the serving and candidate authenticators.  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 from arbitrary networks, 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.

I think that end-to-end protection between the MN and the candidate
authenticator is needed for context binding.  This protection can be
made after establishing keying material between the serving and
candidate authenticators.

We can clarify those points in the next revision.

> Are there any other mean to discover a candidate authenticator besides 

In 3GPP, Network Discovery and Selection (NWDS) function is added in
their architecture (as far as I know it's an optional function).
Although an actual solution for NWDS has not been defined yet, such a
function could include authenticator discovery as well.

> to the authentication protocol and to the authenticator functionality 

In this case, I would not expect to change over-the-wire behavior of
link layer authentication protocols such as 802.1X and PKMv2 while
some primitive may be needed to pass the security context and the
keying material generated by pre-authentication signaling to the lower
layer entity.

> violations related to re-using the key material?

I guess you meant authorization lifetime.  The authorization lifetime
should be no different from that is provided by normal authentication
during initial attachment.  In this case, pre-authentication generates
the keying material to be used by the normal EAP authentication after
handover.  This forms a key hierarchy within the candidate
authenticator, but this should not cause a Domino Effect problem in
terms of RFC 4962 as long as the keys are used by the same pair of MN
and candidate authenticator.

> or the peer) initializes normal EAP authentication?

"Normal EAP authentication after handover" is EAP authentication
performed at the link layer between the MN and the candidate
authenticator.  The way how it is performed (including who initiates
the authentication) depends on the link layer.  Note in the second
approach that the normal EAP authentication after handover uses
short-term credentials generated by pre-authentication.  We can
clarify those things in the next revision.

Best Regards,
Yoshihiro Ohba