RE: [RE] stds-802-16-mobile: [sah] Contribution on EAP support uploaded
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 advantages as compared to existing Privacy stuff. So additional
clarification would be gratefully accepted.
See my comments and questions in uploaded document IEEE C802.16e-04/02
[as our reflector rejects attachments, I had no choice but upload this
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.
************************************************************************************