RE: [802.21] Mutual authentication requirements in SSG
Hi, Michael:
Please look at my another e-mail sent this morning, where I emphasize and
promote discussions on big IFs to see what is the goal and what is
needed.
The following e-mail is to answer your question about why if L3 have 1,
2, and 3 established why need to do it on L2 as well. It is not my
intention to propose one way or another wrt mandatory or optional. It is
up to the group to make a decision.
Regards,
Lily
At 01:59 PM 2/8/2008, Michael.G.Williams@nokia.com wrote:
Hi Lily,
Layering of
security is a familiar concept, and the ideal. Also, end to end security
is the ideal as well. However in some typical deployment scenarios, do we
need to have the ideals in place as always mandatory to use? The existing
TR suggests that not all MIH security requirements are SHALL, some are
MAY.
For example,
in the IETF MIPSHOP MSTP, the security techniques are specified, so that
when transport security is deployed, specific methods are mandatory to
use. However the use of transport security is a deployment option, or, if
I can coin a phrase, 'connection time' option.
Can we have
MIH security methods be a profile (or profiles), so that there are
deployment options? The concern is that if the network architecture
doesn't need end to end security at the MIH layer, forcing it to be
mandatory to use in all deployments might make the network designer solve
the MIH problem a different way.
BR,
Michael
From: ext Lily Chen
[
mailto:llchen@NIST.GOV]
Sent: 08 February, 2008 06:57
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] Mutual authentication requirements in
SSG
Michael:
MIH is delivered by either L3 or L2. If it is delivered by L3, then
the protections will be applied at L3 or higher. Then L2 would not
need to know what is delivered. Whatever specified at L2 will not be
related to MIH.
For example, you are doing home banking from your laptop at home
through a wireless connection. You log in to your bank account, establish
a SSL (or TLS) link. This is end-to-end between the bank
application in your laptop and the bank server. You have to do so
since you need to know that you are on a right server. This
connection is established for your banking activity. Now your
wireless link between the laptop and wireless harbor may also be
protected at link layer whenever you make your connection. This link is
not specific for your banking activity and even do not care what you are
doing. It process each frame in the same way.
For MIH, there is one procedure to bind 1, 2, and 3 for MIH purpose
and from MIHF to MIHF. The others have nothing to do with MIH.
Regards,
Lily
At 09:19 PM 2/7/2008, Michael.G.Williams@nokia.com wrote:
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
-