Re: [STDS-802-16-MOBILE] [security] Pre-authentication discussion (resend)
Jeff,
The term 'routable' is probably inappropriate, as you suggest. The
packets are proxied. The requirement for them to be proxied is an
address and the BSID appears to be the appropriate L2 address to use.
That not all PKM messages are useful when used remotely doesn't seem a
reason to prevent the use of those messages that are useful. My reason
for defining a generic format for carrying proxied PKM messages is that
it is a simple way to specify the behaviour. I do not want to write
special procedures for each message, or a completely new message
sequence with completely new messages.
On you second point, I disagree. There is a very good reason for the BS
to be involved in the proxying. The initial PKM exchanges take place
before any transport connections are set up. Management messages, as
defined, pass only between BS and SS. Before transport connections are
set up, there is no model of communication in 802.16 that allows the SS
to forward management frames over a higher layer protocol to a remote BS
(onlt the BS can do that). In addition, it is generally out of scope for
us to define such a model, since it entails defining backhaul transport
protocols and it would render the protocol be incapable of supporting
all CS types. So having the BS do the proxying is the way to it. The BS
implementation worries about adaption to the BS-BS transport and L2
concepts (such as PKM messages and the BSID) are used in the SS-BS &
BS-SS messages.
-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org
[mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of Jeff
Mandin
Sent: Monday, June 07, 2004 11:09 AM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: Re: [STDS-802-16-MOBILE] [security] Pre-authentication
discussion (resend)
DJ,
Comments inline.
Johnston, Dj wrote:
>Jeff,
>
>For pre-authentication, I am proposing a routable PKM packet.
>Specifically, a PKM message format that contains a BSID field. The BS
>uses this field to map to some BS-BS transport address and send the
>packets on their way.
>
>All normal PKMv2 maessages can be carried in this routable form.
>
>
This isn't really routing packets. As Yong Chang said, the Serving BS
is acting as a proxy.
Some reasons for preferring the other approach are in the previous
email. I would add the fact that most of the PKM messages make no sense
at all in a "remote" scenario.
But more fundamentally: ..... there is no reason for the serving BS to
be actively involved in the exchange. There's no architectural need for
changes in the MAC that I can see, since the aim is to set up a Secure
Association and established a shared Master Key.
I think this remains true even with the new features you have proposed
ie. the AAID.
>Thus an MSS can pre-authenticate remotely.
>
>Along with this, AA aging is required to prevent AA state building up
>and some guideline on how many BSs an MSS may try to pre-auth to. I'm
>thinking of something like 3-4 as a maximum, so that MSSs can't just
>pre-auth with everything and create an excessing system load.
>
>
Yes absolutely. In this respect the requirements of .16 are somewhere
between 3G - which I understand has rapid aging - and .11.
Regards,
- Jeff
Jeff Mandin
Security Adhoc Chair
>DJ
>
>
>-----Original Message-----
>From: owner-stds-802-16-mobile@listserv.ieee.org
>[mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of Jeff
>Mandin
>Sent: Monday, June 07, 2004 10:41 AM
>To: STDS-802-16-MOBILE@listserv.ieee.org
>Subject: [STDS-802-16-MOBILE] [security] Pre-authentication discussion
>(resend)
>
>
> From the discussion about post-handoff authentication, there seems to
>be consensus in the adhoc for Jung-won's idea that two mechanisms will
>co-exist:
>
> 1) Pre-authentication
> 2) Backbone Transfer of Derived Context (suitably secured
> obviously)
>
>I'd like to hear adhoc-ers' views on how generally to support
>pre-authentication in PKMv2.
>
>The mechanism we choose for supporting pre-authentication has
>potentially significant implications. The requirements for pre-auth
>support would be:
>
> 1. Well-understood behaviour
>
> 2. Facilitate pre-auth to a BS on the same provider or a different
>provider.
>
> 3. Enable establishment of the shared-secret Pairwise Master Key
>and determination of success/failure of the authentication
>
> 4. Do not preclude pre-auth to different media (via 802.21 or
>what-have-you). Similarly, do not preclude pre-auth to an unadvertised
>neighbor.
>
>802.1X authentication satisfies all of these. The caveat is that for
>the moment 802.1X can only be used within a single IP subnet; but
>extending it to work over IP has been discussed a lot and seems
>trivial.
>
>
>- Jeff Mandin
>Security Adhoc Chair
>
>
>