Re: [802.21] Mutual authentication requirements in SSG
Dear ALL:
I think the first step is to identify the security goals. In my
previous e-mail, notice what I said,
if we want to
give assurance to MN that the information is from the information server,
then information server must authenticate the message
(information). If some argue that this assurance is not necessary,
because so and so, then IS may not need to authenticate the message
(information). Perhaps, we can separately discuss security goals
for IS, CS, and ES.
Another thing we need to consider. So far, there is no
infrastructure support for MIH service. Let me explain what I
mean. For signals, it depends on EAP server (authentication, key
derivation, link layer protection) or Authentication Center (3GPP and
3GPP2). The server will hold the long-term key, conduct entity
authentication, establish keys, and transport some keys to PoA so that
the link layer signals are protected between the MN and PoA. For
MIH, we do not have such a thing yet. The trust model is different since
whatever it is, authentication server or PKI, it must be trusted by all
the MIHFs (in both MNs and NNs). Ideally, the infrastructure must be
media independent as well and also from end-to-end between MIHFs.
For example, between MN MIHF and Information server, we can use TLS for
authentication, key establishment, and protections. For TLS, entity
authentication (at least server authentication) can use PKI, where the
actual data protection using symmetric key based algorithms, for example,
AES-CBC for encryption and HMAC for integrity protection. (This
shall more or less response the remark that public key is too heavy).
This is my suggestion on what we will do next:
1. Identify security goals for IS, CS, and ES.
2. Based on the goals to identify what protections we need to apply.
3. Discuss feasibility for infrastructure support based on the
protections.
4. Discuss tradeoffs between security and performance to make a final
decision.
Regards,
Lily
At 04:27 AM 2/8/2008, Rahul Sinha wrote:
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 -----
- From: Michael G
Williams
- To:
STDS-802-21@LISTSERV.IEEE.ORG
- 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
-
-
-
- From: ext Lily Chen
[
mailto:llchen@NIST.GOV]
- Sent: 07 February, 2008 11:26
- To: STDS-802-21@LISTSERV.IEEE.ORG
- Subject: Re: [802.21] Mutual authentication requirements in
SSG
- 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
-