Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RE] stds-802-16-mobile: [sah] Contribution on EAP support uploaded

Title:
Vladimir hi,

Thanks for your (lengthy) comments.  To briefly address what I think are the main substantive issues that you raise:

1. EAP-based authentication as an extension to existing Privacy Layer

    EAP-based authentication is described in the contribution as an extension to the Privacy layer.  In practice,
    it can become a replacement for the authentication algorithm portion (only) of the current Privacy
    Layer.  Currently, TEK management remains as it has been (though we may need to use the
    EAPOL-Key model for fast post-HO reauthentication). 

    In any event, the functional definition of the Privacy layer remains intact; so do the basic features (ie. ciphersuites,
    security associations etc.).  Higher-layer security can still be established over it, and it still provides per-packet
    encryption and integrity protection.

2. Whether EAP exchanges should be performed inside the MAC or on top of it: 

    Simply running 802.1x on top of 802.16 would obviously be the most appealing approach as you say.  The
    problem is that doing this would  require significant changes in the MAC because the authenticated identity
    and the Security Associations  (for which authentication is a prerequisite step) are used in link initiation.

    Specifically:.

      - DSx messages reference the SAIDs which are (currently) provisioned in the PKM step. 
      - Registration requires data origin integrity (ie. HMAC) and uses the authenticated Identity to provision connections. 
      - Handover completion should occur only after the user has been authenticated.

    Moving authentication above the MAC would require reworking these mechanisms.  As well, 802.16 is a bit
    of a strange beast in that it supports "convergence layers" at different levels of the OSI stack.  Relying on 802.1x
    would not provide a solution for non-802.3-style convergence layers ie.  IP.

    The alternative is to perform the EAP-based authentication as part of the link initiation (ie. the way that it's done in the
    current Privacy Layer - which is also the "traditional" way to do link-layer authentication). 

    This approach avoids all the problems mentioned above and is compatible with  the EAP interface to a lower-layer formalized in
    draft-ietf-eap-statemachine and Appendix F of 802.1xRev ie. (broadly):

                o EAP receives a logical indication that the channel (ie. secondary mgt connection) is available for EAP message exchange

                o EAP sends and receives EAP messages (in the formats described in  RFC 2284bis), which are in turn transmitted or
                received in PKM-encapusulated msgs.

                o EAP provides the 802.16 control layer with indication of authentication success/failure, and possibly provides master key data
                 upon authentication success

3. Controlled/uncontrolled port

       The 802.16 control layer receives authentication success or failure from the EAP layer.  It behaves as follows on network entry:
         
             - Success: continue initialization
             - Failure:  reset link

        On reauthentication:

             - success: continue operation
             - failure: ??

          In the last case (reauthentication failure), there might be a case after handover where a full link reset is not desired.  If so, there
          would be a situation similiar to the "controlled port".

          The next revision of the contribution should hopefully close this issue.

4. Interoperability

    You are correct in understanding from the text that every SS and BS has a mode in which existing Privacy
    (only) is used. 

    When an SS supports optional EAP-authentication, its product description will also list the EAP methods that it supports (eg.
    "EAP-TLS acc. to RFC 2716").  A compatible BS would then claim support either for RFC 2716 (for standalone support), or
    more likely RFC 3579 (for EAP via RADIUS, with EAP-TLS to be supported on the AAA server) etc.

    The EAP protocol itself selects which supports determination of which authentication scheme should be used.

    I don't see a problem with making the EAP methods part of the MAC layer while leaving the particular methods
    unspecified - there's not a substantive difference between this and leaving the methods undefined for 802.1x.

Regards,

- Jeff


Vladimir Yanover wrote:
Jeff and All,
 
I have certain problems with understanding the document. 
Most important concerns address "Motivations" section [if there is no
sufficient motivation, why should we do anything?], relation between
suggested procedures and existing Privacy sublayers and interoperability
issue.

Besides that, I share concerns expressed by Ken Stanwood in his message
from 11/20/2003 that were not answered [unless I missed something].

As other experts working for equipment manufacturers, I am interested to
understand better applicability of EAP in 802.16 environment, as well as
its profitability as compared to existing Privacy stuff. So additional
clarification would be gratefully accepted. 
See my comments and questions [appear in blue] embedded into citations in
attached document.

Thanks
 
Vladimir 


-----Original Message-----
From: Jeff Mandin
To: csyoon@etri.re.kr
Cc: stds-802-16-mobile@ieee.org
Sent: 12/29/2003 11:59 AM
Subject: Re: [RE] stds-802-16-mobile: [sah]  Contribution on EAP support
uploaded

Hi Yoon,

Thanks for your msg.  I uploaded a revision #2 including your comments,
my responses, and some additional material on the network model and flow
examples.

See my inline comments to your msg below.

Best Regards,
- Jeff

----------------
Jeff Mandin
Streetwaves Networking
Jerusalem, Israel

csyoon@etri.re.kr <mailto:csyoon@etri.re.kr>  wrote:


Hello, Jeff and all, 

I and my colleagues at ETRI have discussed Jeff's initial contribution. 
We proposed some ideas improving the document, and uploaded in TGe
upload directory. 
Main issues are summarized as follows: 

1) For TEK key generation and distribution via EAP, we propose to add
optional Key_Request/Key_Reply procedure for the backward compatibility
with 802.16 privacy mechanism as well as the Key Distribution in
EAPOL-key in 802.1x.

I agree.


2) We have a thought that mapping the controlled logical ports to the
Secondary Management Connection in 802.16 MAC requires some other
functions such as port control functions into the MAC layer. It is not
an easy matter, so we propose that the port control concept would be
discussed afterwards.

It was not my intention to impose those kind of requirements.  I
modified the text in a way that I think should be clearer and more
flexible.

The basic idea of controlled/uncontrolled data connection is fundamental
to our network model, so it's important to define it now.


  

3) We think that the multiple EAP-Request/EAP-Response exchanges can be
initiated by SS or BS. EAP authentication procedure permits initiation
by SS optionally, so we can adopt it.

There are 2 issues here:

1. Can the SS perform the role of the EAP Authenticator?
2.  When the SS is in the role of the EAP supplicant, can it initiate
the authentication sequence?  More precisely:  do we need the equivalent
of an 802.1x EAPOL-Start message?

Regarding the first question:  we should permit the SS to perform as
authenticator as there are some methods which require it for mutual
authentication.  But we should avoid the complexity until the document
is more complete.

On the second question, I can't see a scenario where "EAP-Start" is
needed.  The BS will always use SBC success as its trigger to begin
authentication.


4) We propose to add message format for transmission of EAP packets in
802.16 MAC layer. 
- PKM Message Code added to the Table 25 for EAP Transfer Request and
EAP Transfer Reply 
- EAP Transfer Request Attributes added to the Table 27-b 
- EAP Transfer Reply Attributes added to the Table 28-b 
- Figure 99 Modified for the EAP Authentication procedure 
- PKM Attribute type (EAP Payload, EAP Result, SS's Public Key) added to
the Table 129 
- Attribute define for the PKM Attribute type (EAP Payload, EAP Result,
SS's Public Key) to the [11.2.20], [11.2.21], and [11.2.22]

Thanks for putting these in.  I made the following changes:

         - removed the public key attribute from the EAP-Transfer
request (since if it is needed it is carried in an X.509 certificate by
the inner EAP method.)

         - removed the encrypted authorization key attibute from
EAP-Transfer response (same reason).

         - removed the change to "figure 99" because it showed 2
authentications in a sequence.  RFC 2284bis section 2.1 describes why
this is problematic:  there 
         is no cryptographic binding between the 2 authentications.  To
require 2 sets of credentials it is necessary to use a single compound
method such as PEAP.
         I suggest leaving figure 99 as is and placing EAP-related
authentication flows in a separate section.



6) We added some reference material. 
- Call flow for the user authentication based on EAP framework using the
RADIUS and Diameter as a AAA protocol 


Sincerely, 

CS Yoon 

?? ??:


Also, I created 2 appendices: one for the 802.1x/.11i material and one
for the DIAMETER and TLS material.  





????: Jeff Mandin[ jmandin@streetwaves-networks.com
<mailto:jmandin@streetwaves-networks.com> ] 
????: stds-802-16-mobile@ieee.org <mailto:stds-802-16-mobile@ieee.org>  
??: stds-802-16-mobile: [sah] Contribution on EAP support uploaded 
????: 2003/12/08 ? 18:08 



Hello all, 
My initial contribution on EAP deals with requirements, network model, 
coexistence with PKM, and threats. 
Looking forward to feedback. 
- J. 
----- 
Jeff Mandin 
Streetwaves Networking 
jeff@streetwaves-networks.com <mailto:jeff@streetwaves-networks.com>  




This mail passed through mail.alvarion.com

************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &
computer viruses.
************************************************************************
************



This mail was sent via mail.alvarion.com
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************