|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
After reading your email, I looked after the mesh-mode related text and
found section 6.3.16 of REVd/D5 document, where PKM message tunneling is
described. "The entity performing the BS part of the protocol" could be or
may be MSS, but I'm not sure about it. Although that is right, that entity
performing the BS part of the protocol has to be regarded as BS as the
6.3.16 says. And have a lookat the table 129 original PKM message direction
does not change when mesh-mode tunneling.
So as a bottom line, I see authenticator is always in the BS or the entity
performing the BS part of the protocol, which does not change the direction
of PKM messages and EAP message. So I don't think it's possible for us to
see EAP-Request comes from the MSS to BS. NEVER!
I'd like to have Jeff's opinion on this. Thanks.
----- Original Message -----
From: "Johnston, Dj" <firstname.lastname@example.org>
To: "galahad" <galahad@NETSGO.COM>; <STDSemail@example.com>
Sent: Wednesday, July 21, 2004 12:30 PM
Subject: RE: [STDS-802-16] [STDS-802-16-MOBILE] [security] PKM-EAP Pair
Is the location of the authenticator always going to be in the base?
Possibly not if we ever extend security to cover mesh modes.
Either way, I suspect that if we just reduced the PKM-EAP packet to
being a single message that can be sent in either direction, then it
would address all objections (layer violations and direction mapping)
and work with whatever EAP scenario hits us in the future. Do you agree
[mailto:firstname.lastname@example.org] On Behalf Of galahad
Sent: Tuesday, July 20, 2004 6:48 PM
Subject: Re: [STDS-802-16] [STDS-802-16-MOBILE] [security] PKM-EAP Pair
Had a plesant trip back to your home? I'm still suffering from a little
Couple of days I thought of just deleting entire PKM bi-directional text
from my contribution and resubmit just the one EAP-Transfer text
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
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
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" <email@example.com>
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
> EAP-transfer and the other PKM messages. Could you explain this in
> more detail, pls?
> ----- Original Message -----
> From: <firstname.lastname@example.org>
> To: "galahad" <email@example.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
> > If you'd like to talk about it, then please feel free.
> > BR,
> > - Jeff
> > On Wed, 14 Jul 2004 06:54:48 +0900, "galahad" <firstname.lastname@example.org>
> > > 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: email@example.com
> > > firstname.lastname@example.org
> > > ============================
> > --
> > email@example.com