Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16-MOBILE] [security] Pre-authentication discussion (resend)

Title:
DJ,

1. Originally, many suggested that we use EAPoL as the solution for extensible authentication in 802.16.  We elected instead to define a "EAP-in-MAC" solution, for various reasons - primarily because .16 network entry cannot complete without using an authenticated identity.

2. Your proposal is to extend the functionality of our "EAP-in-MAC" to include at least the following:

          a) Tunnelling/detunnelling of EAP (and other PKM-?) messages into/out-of the Security Sublayers of neighbor base stations

          b) New messages, and changes to the Authenticator EAP state machine to support non-local clients.

                eg. what does a client send to a Target BS to begin authentication?  In the local case,.authentication begins automatically as part of Network Entry, but for the remote case we would have to add a START message that the client can send to the non-local BS.

                I think we'd find that these changes basically mean turning EAP-in-MAC into EAP-over-LAN.

          c) Protection against rogue packets - the inter-BS tunnel would be a new path on which to send forged EAP-LOGOFF.  Would there be a Diffie-Hellman  Preliminary AK here also? [As an aside, could you upload your Shenzhen adhoc mtg. slides - Thanks!]

3. Let me try to summarize (in what I hope is a fair and complete manner)  your supplied reasons for adopting this tunnel/proxy approach rather than permitting the MSS to authenticate over the data plane using a well-understood non-MAC mechanism (ie. EAPoL or other approaches around that would apply for IPv4, IPv6, PPP).  My responses follow.

      -  Tunnelling permits an MSS to preauthenticate to a remote BS before it authenticates or has a transport connecttion on the local BS

[JM] To me that's a bug rather than a feature.  The 802.11 people also think so, and specifically prohibited doing pre-auth before auth.  In any event I think that the capability to do pre-auth to a BS that is not known to the current BS (eg. different provider) is more important, and is not possible with the tunnel approach.

       - Support for tunnelling enables us to guarantee that pre-authentication is always possible, as we cannot mandate use of a particular data-plane mechanism such as EAPoL since this is not part of our scope and does not pertain to all convergence sublayers

[JM] Previously, when higher layer functions have been required, we have simply said they are "out of scope" and left them for particular implementations or future standards.  That preauth is a higher-layer function is clear from:

    * the fact that in your own description you say that the Serving BS is behaving only as a front end for the higher layer protocol.
    * the fact that trying to support preauth in the MAC makes us add EAP-over-LAN features such as START

4. So basically:  we shouldn't tunnel PKM msgs.  Instead we should permit higher-layers to supply the MAC layer with authentication data received by Derived Context Transfer on the one hand and preauthentication protocols on the other.

- Jeff

Johnston, Dj wrote: 
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