|
Hello All,
I agree with Lily on her comments. Perhaps we can
restate them as requirements as follows:
1. An end-to-end security mechanism should be used
for securing the MIH protocol. In particular, security services (mutual
authentication, message confidentiality and integrity)
should be provided at the MIH layer.
2. The security of the MIH protocol messages
should not depend on the security of the underlying transport mechanism.
Note that different transport
protocols have different security mechanisms. Moreover, the message may not
be secure while passing through intermediate nodes.
The alternative is IPSec. However, we
cannot assume that IPSec will be available.
I also agree with the suggestion of binding 1.
Mutual authentication, 2. Key establishment for message protection, 3. Message
protection (confidentiality+integrity). This might
be the case if an authentication method is used,
which, in addition to authenticating entities, also derives key/keys which can
be used as message confidentiality/integrity keys.
PKI is perhaps too 'heavy'.
Any comments on the above?
Regards,
Rahul Sinha
----- Original Message -----
Sent: Friday, February 08, 2008 7:49
AM
Subject: Re: [802.21] Mutual
authentication requirements in SSG
Hi Lily, Maryna, Peretz,Yoshi,
Thank you for the responses, helping us to make
progress here.
Maryna, Peretz, regarding the use of MIIS in
unauthenticated state... that use case is supported for NWDS acceleration by
.16 and .11. We have assumed that the use of the MIIS at L2 would mean that
the PoA would not trust the MN even if the MN is currently associated to
the PoA's network through a different PoA. Could it be possible for the MN to
already trust the new PoA however, if it is in the same network as the current
PoA? What would it take to make that a possibility? Of course the mobile node
may use the information as a hint even if there is no authentication (as is
done today with the beacon)
For this use case, one of the main concerns expressed
in .11 was that of DoS attack from the MN. Were there similar concerns from
.16?
Lily, regarding use of MIH when the MN is
authenticated to the network, you mentioned that for most correct usage, the
four aspects of 1,2,3 plus replay protection must be mandatory to use,
regardless of the transport level use of those four aspects. As a result, we
may have L2 use of these four protections, then L3 use of them (e.g. ipsec),
then the MSTP layer, and then the MIH layer, is that what we are
suggesting?
BR,
Michael
We have a few relative security aspects:
1.
Mutual authentication (entity authentication).
2. Key establishment for
message protection.
3. Message protections (encryption and integrity
protection).
If we want to make sure that MN receives information
from a correct source, then we have to bind 1-2-3 together so that the
message is authenticated by the entity which have authenticated in 1. Entity
authentication does not imply message authentication (integrity
protection). That is, we cannot depend on transport protection, since
the transport layer ID for the service unit may not be the same as the MIH
ID. The transport layer mutual authentication may not mean MIH mutual
authentication. Furthermore, the protection may be applied hop-by-hop
instead of end-to-end. The information receiver may not be able to get any
assurance on where the information comes from.
There are some
options if MN can access a PKI which is media independent and if the
protection is applied at MIH protocol, then the information can be
authenticated by digital signatures, verifiable by MN without step 1 and
step 2 we listed in the above. In this case, other cautions must be taken,
for example, to prevent re-play attacks.
However, these are just
IFs. We need discuss how applicable these IFs
are.
Regards,
Lily
At 04:23 AM 2/5/2008, komarova
wrote:
Hi all,
MN to IS
authentication may be optional, but IS to MN authentication should be
mandatory in order to provide guarantee that the MN receives information
from a correct source.
Best regards,
Maryna
Komarova
Yoshihiro Ohba a écrit :
Hi Perets,
This topic
is important for SSG TR.
On Sun, Feb 03, 2008 at 01:54:07AM
-0600, Feder, Peretz (Peretz) wrote:
Michael: We actually were
planning to use IS in 802.16 before the 802.16
full authentication,
if now required we may loose the pre-authentication
network entry
flexibility.
This leads to an
issue on whether the security feature to be defined
by a new project
(if approved) should be mandatory to use or option to
use. We
may need to define it as option to use at least for IS,
considering
the 802.16 usage mentioned above as well as GAS usage
in
802.11u. We may need to investigate the same issue for ES
and CS as
well.
Regards,
Yoshihiro
Ohba
________________________________
From: Michael
G Williams [ mailto:Michael.G.Williams@NOKIA.COM] Sent:
Friday, February 01, 2008 8:15 PM
To:
STDS-802-21@LISTSERV.IEEE.ORG
Subject: [802.21] Mutual
authentication requirements in SSG
Hi,
In the security
study group, we discussed the need for MIHF level
authentication.
There were a few topics in this area:
What do people see as
serving as the basis for credentials for the MIHF?
Is it
possible to reuse the network access authentication or
MSTP
transport authentication for the MIHF level?
Is mutual
authentication always required, or is one way sufficient for
some
applications?
Is the need for authentication different between the
four different
services (management, ES, IS, CE)?
Comments?
Proposed solutions?
Best Regards, Michael
|