Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
DJ,
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" <dj.johnston@intel.com> To: "galahad" <galahad@NETSGO.COM>; <STDS-802-16@listserv.ieee.org> Sent: Wednesday, July 21, 2004 12:30 PM Subject: RE: [STDS-802-16] [STDS-802-16-MOBILE] [security] PKM-EAP Pair Mismatch Donnie, 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 Jeff? DJ -----Original Message----- From: owner-stds-802-16@listserv.ieee.org [mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of galahad Sent: Tuesday, July 20, 2004 6:48 PM To: STDS-802-16@listserv.ieee.org Subject: Re: [STDS-802-16] [STDS-802-16-MOBILE] [security] PKM-EAP Pair Mismatch 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 > > > > > > > > > ==================================
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 ================================== |