|
I slightly understand what's in your mind, but still
don't agree with you. If you think of EAPOL-Start, I'd say that is not EAP
message, morever EAP-Request. It's 802.11 MAC message. So if you think of SOME
message sent from the MSS to the BS, that is not EAP-Request as you mentioned
per RFC 3748, it maybe or could be 802.16 MAC message.
My best regards,
Donnie
----- Original Message -----
Sent: Wednesday, July 21, 2004 9:42 PM
Subject: Re: [STDS-802-16]
[STDS-802-16-MOBILE] [security] PKM-EAP Pair Mismatch
Donnie hi,
Essentially: the PKM message type called
"EAP-Transfer-Request" is something that should be viewed as distinct from RFC
3748's "EAP-Request" (for the reasons listed in my original note).
We wouldn't care if the higher-layer EAP method happened to send a
"TLS response" (for example) inside an EAP-Request message, so similarly
we're not concerned about what kind of EAP message happens to be inside the
EAP-Transfer PKM Frame.
So the direction of the RFC 3748
EAP-Request is not the relevant issue (and I didn't say that it was). I did
note tangentially that in 802.1X there is the notion of bidirectional
EAP sessions, and that someday this notion might be relevant to us - in which
case an EAP-Request might go from SS to BS.
Doing the other changes you
suggested (ie. making a single EAP-transfer message that can travel in either
direction, and requiring the PKMId field to be 0) seems like the best
idea. It seems to me that doing those would satisfy most of
your concerns, and we can then move on to our list of open issues.
Best
Regards,
- Jeff
galahad wrote:
Hi, Jeff!
Had a plesant trip back to your home? I'm still suffering from a little jet
lag.
Couple of days I thought of just deleting entire PKM bi-directional text
from my contribution and resubmit just the one EAP-Transfer text portion.
But last night, one question poped into my mind. I remember you objected my
contribution because you insisted that EAP-Request may come from MSS side.
But as I explained during presentation session at Portland, RFC 2284(see
below excerpted text) clearly specifies that EAP-Request is sent by the
AUTHENTICATOR to the peer. Not by MSS to BS. And still changing PKM to be
bi-directional does not harm anything to the standard and does not incur
backward compatibility problem.
So please re-consider my contribution again and reply me. RSVP
My best regards,
*********************************************************
4.1 Request and Response
Description
The Request packet (Code field set to 1) is sent by the
authenticator to the peer. Each Request has a Type field which
serves to indicate what is being requested. Additional Request
packets MUST be sent until a valid Response packet is received, or
an optional retry counter expires.
----- Original Message -----
From: "galahad" <galahad@netsgo.com>
To: <jmandin@warpmail.net>
Sent: Wednesday, July 14, 2004 8:26 AM
Subject: Re: [STDS-802-16-MOBILE] [security] PKM-EAP Pair Mismatch
Maybe you're right that this is NOT a problem from the perspective of MAC
design. But if a person who is new to IEEE 802.16e standard have a look at
it, he might be uncomfortable with that. Because of that pair mismatch. I
mean we can make it more elaborate than before, but why stay with current
one which is not pretty and awkward.
And I don't see any reason of my solution introduces inconsistencies
between
EAP-transfer and the other PKM messages. Could you explain this in more
detail, pls?
----- Original Message -----
From: <jmandin@warpmail.net>
To: "galahad" <galahad@netsgo.com>
Sent: Wednesday, July 14, 2004 7:43 AM
Subject: Re: [STDS-802-16-MOBILE] [security] PKM-EAP Pair Mismatch
Donnie,
Essentially: Messages from the SS to the BS are contained in
PKM-Requests; messages in the other direction are contained in
PKM-Responses. The fact that the message inside a Response happens to
be called an EAP-Request is not interesting as far as the correctness of
our MAC design is concerned.
EAP-Transfer-Request means "upstream direction EAP transfer", and
doesn't relate to the content of the EAP message.
So the problem isn't really a problem; and the solution introduces
inconsistencies between EAP-transfer and the
other PKM messages.
One clarification that occurs to me is the PKMId field for EAP-transfer
messages should really be 0, as there is no such thing as correlation of
requests and responses (since it's all transparent).
If you'd like to talk about it, then please feel free.
BR,
- Jeff
On Wed, 14 Jul 2004 06:54:48 +0900, "galahad" <galahad@netsgo.com> said:
About "C80216e-04_049r6 Bi-directional PKM messages for EAP
messages", could you reiterate what was the reason of rejection?
Do you want to leave current text as it is or want some
modification
to my contribution?
I'd appreciate your reply.
Best regards,
==================================
Donnie Dongkie Lee
Seorindong 99, JongRoGu
Seoul, Korea
SK Telecom
Phone: +82-2-6323-3147
Mobile: +82-11-758-4359
E-Mail: galahad@nate.com
galahad@netsgo.com
============================
--
jmandin@warpmail.net
|