1. PMK-R1 Distribution - Discussion
Month Year
doc.: IEEE yy/xxxxr0
November 2006
PMK-R1 Distribution - Discussion
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Chen et.al.Chen et al
John Doe, Some Company

2. PMK-R1 Distribution – Why is it an issue?
Month Year
doc.: IEEE yy/xxxxr0
November 2006
PMK-R1 Distribution – Why is it an issue?
PMK-R0 (11r)
In 11r, protocols of distributing PMK-R1s are not specified, since they are out of scope of 11r. (The dot arrows in the picture.)
That is, we cannot specify protocols to authenticate a “potential” R1KH by the R0KH, to authorize it to be a key holder, and to protect the key distribution.
Currently, three solutions have been discussed:
Pre — D3.0: Requirements on key holders and key distribution.
D3.0: A 3-party pull protocol.
Post – D3.0: A push protocol.
STA
R0KH
R1KHA
R1KHB
R1KHC
Chen et.al.Chen et al
John Doe, Some Company

3. Ns, Na, {Na, TAP-Id}mk, PMK-R1, R1Name
Month Year
doc.: IEEE yy/xxxxr0
November 2006
3-party Pull Protocol
STA
Target AP
R0KH
{Ns, TAP-Id}mk
Ns, Na, {Na, TAP-Id}mk, PMK-R1, R1Name
H(Ns|Na), {Na, TAP-Id}mk
mk – derived from MSK
Protected by out of scope mechanisms.
Protocol is termed 3-party but TAP never contributes to the security, besides indicating that R0KH decrypted the nonce generated by STA.
The yellow arrow STILL relies on a trust/secure relationship between TAP and R0KH, which is already listed as a requirement. THIS IS OUT OF SCOPE FOR 11r!
The encrypted Na sent by R0KH subject to replay attack.
The protocol lacks session identity.
Chen et.al.Chen et al
John Doe, Some Company

4. How the 3-party pull protocol would apply to current FT
Month Year
doc.: IEEE yy/xxxxr0
November 2006
How the 3-party pull protocol would apply to current FT
STA
Current AP
Target AP
R0KH
Successful session
auth request (…, R0KH-ID, {Ns, TAP-ID}mk)
ID-STA, {Ns, TAP-ID}mk
ID-STA, {Ns, TAP-ID}mk
Na, Ns, {Na, TAP-ID}mk, PMK-R1, R1Name
auth response (…, AUTH, {Na, TAP-ID}mk)
Re-association request (…)
R0KH must be involved in each FT!
Re-association response (…)
802.1X Controlled Port Unlocked & Successful Session
Here, Base Mechanism over-the-air is used as an example.
Chen et.al.Chen et al
John Doe, Some Company

5. Key Hierarchy for Pull Protocol
Month Year
doc.: IEEE yy/xxxxr0
November 2006
Key Hierarchy for Pull Protocol
MSK
PMK-R0 MK
PMK- R1A
PMK- R1B
PMK- R1C
Please notice that MK is at the same level as R0 key but used as an encryption key. Using MK to decrypt any ciphertext sent by an STA will make it vulnerable to “chosen cipher-text attack”.
Chen et.al.Chen et al
John Doe, Some Company

6. Observations on 3-party Pull Protocol
Month Year
doc.: IEEE yy/xxxxr0
November 2006
Observations on 3-party Pull Protocol
What the 3-party Protocol may do
Give STA an authenticated up-date on the current status of the target AP from R0KH.
Inform STA if a target AP is entitled to use an R1 Key.
If STA does not like the target AP, then turn away.
The security logic is, because STA trust R0KH, if R0KH tells STA the target AP is good then STA should trust it.
What the 3-party Protocol does NOT
Authenticate the target AP or any entity.
Provide confidentiality of key distribution. (Protection of PMK-R1 is not specified.)
Authorize the key usage to the target AP. (By whom? STA or R0KH or both?).
Bind the PMK-R1 to any entity besides it has already included in the KDF input, assuming NAS-Id =R1KH-Id. This is already achieved by how the PMK-R1 is derived.
Acknowledge the receipt of the PMK-R1.(The acknowledgement can only be achieved through direct communications with TAP as is already done by the MIC in the 4th message of FT exchange)
Chen et.al.Chen et al
John Doe, Some Company

7. Key Hierarchy for Push Protocol
Month Year
doc.: IEEE yy/xxxxr0
November 2006
Key Hierarchy for Push Protocol
MSK
PMK-R0
PMK-R0 Distribution-key
PMK- R1A
PMK- R1B
PMK- R1C
STA-contribution-key - R1A
STA-contribution-key - R1B
STA-contribution-key - R1C
Used to derive R1KEK together with K
Chen et.al.Chen et al
John Doe, Some Company

8. Push Type of PMK-R1 Distribution
Month Year
doc.: IEEE yy/xxxxr0
November 2006
Push Type of PMK-R1 Distribution
A push type of PMK-R1 is introduced in submission 1613r1.
In the push type of distribution, each PMK-R1 is encrypted by a key-wrapping key.
Each key-wrapping key is derived with two piece of keys.
A key K shared between the R0KH and R1KH;
A STA contribution piece Ks derived from R0 key and shared by R0KH and STA.
The target AP cannot unwrap the PMK-R1 unless it receives the STA contribution key Ks. K
STA
Target AP
R0KH
Enc(R1-KEK, PMK-R1) Ks
Decrypt PMK-R1
R1-KEK = KDF(K||Ks, R0KH||R1KH)
Ks = STA-contribution-key
Chen et.al.Chen et al
John Doe, Some Company

9. Observations on Push Type of Distribution
Month Year
doc.: IEEE yy/xxxxr0
November 2006
Observations on Push Type of Distribution
It may prevent a rogue AP from getting PMK-R1, IF
R0KH does not establish a key K with it; or/and
STA does not like the target AP and therefore does not give it STA-contribution-key.
What we do not know
How the key K is shared by R0KH or R1KH, via Authenticated key establishment? Authorization?
In which situation R0KH will give the encrypted PMK-R1 to the target AP.
If R0KH does not authorize the target AP to hold PMK-R1, why bother to establish a K?
How an STA can know the fact that a certain AP is not entitled to hold PMK-R1, based on whether to like it or not?
If STA does not like the target AP, why bother to request for association without giving STA-contribution-key?
If we cannot trust PMK-R1 to be distributed only to the eligible AP, how could we trust the key K is only shared with the eligible AP?
Latencies are added to the TAP as it can not plumb the PMK-R1 until the STA has provided the STA-contribution-key.
The STA does not have assurances of the TAP’s authenticity or authorization until the TAP has proven possession of PMK-R1 via the 4th message of the FT exchange.
Chen et.al.Chen et al
John Doe, Some Company

10. More Observations November 2006
Month Year
doc.: IEEE yy/xxxxr0
November 2006
More Observations
No matter pull or push, STA needs to know which model?, since it will derive the corresponding key hierarchy.
Pull and push seem targeting on different trust models.
Pull: Trust R0KH to tell STA whether the AP is a good one.
Push: Trust STA to authorize an AP as it likes.
Neither pull nor push provide
Why and how an R0KH can authorize an AP to hold a PMK-R1;
Why and how an R0KH can prevent an AP from holding a PMK-R1;
How an AP can authenticate to R0KH.
How an STA is provided assurances of the APs authenticity or authorization
It is unclear whether the shared key K between R0KH and R1KH is specific for an STA.
Either pull or push introduce increased computational and memory requirements on both client and TAP that violate the PAR’s goal for optimal transition time
The introduction of the ‘push’ and ‘pull’ model must be reconciled as it is unclear how each one is enforced or whether both cryptographic contributions must now be required. Observation: the addition of either protocol has added significant cryptographic operations to consume time and power especially on a client. The combination potentially violates the timing requirements of the TGr PAR
Chen et.al.Chen et al
John Doe, Some Company

11. Questions we must answer
Month Year
doc.: IEEE yy/xxxxr0
November 2006
Questions we must answer
What is the trust model or threat model? Which attacks we are up to against? (Cheating NAS-ID? Stealing R1 key?) What requirements or problems are these proposals trying to solve?
What we can assume with regard to
Authentication between R0 key holder and R1 key holders;
Who authorizes an R1 key holder to hold a R1key and how;
Relation between authorizing an R1 key holder and actually delivering an R1 key;
Protected channel between the R0KH and an R1KH to deliver R1 key.
(These requirements had been defined by 8.5A.6.1& 8.5A.6.2 of D2.2 which were now rewritten and no longer correct in D A.6).
How can a target AP happen to possess a valid PMK-R1 but not entitle to hold it? [Based on assumptions were documented in D A.6.1 & 8.5A.6.2]
If we do not know how, then why we think either pull or push protocol can prevent it?
Why is TGr defining backend protocols when it is not in the scope of ?
Chen et.al.Chen et al
John Doe, Some Company

12. What we really want for PMK-R1 Distribution?
Month Year
doc.: IEEE yy/xxxxr0
November 2006
What we really want for PMK-R1 Distribution?
An R0KH must authenticate a potential R1KH with an identity bound to PMK-R1.
The identity should be included in R1KH-ID and unique in the mobility domain.
Based on the authentication, an R0KH must be able to make a judgment on whether to authorize the potential R1KH to hold a specific PMK-R1.
If the potential R1KH is authorized to hold a PMK-R1, then a mutual authenticated protection channel must be established to deliver the PMK-R1 key.
The mutual authentication of R1KH and R0KH may be supported by MDC by public key certificate or pre-shared key.
The protection should provide confidentiality and authenticity.
The PMK-R1 is encrypted and authenticated with Message Authentication Code when delivered.
Neither Pull nor Push can provide what we really want.
[Note: we should be ready to state why….1 reason is because to meet the above requirements involves more communication and assumptions between R0KH and R1KH that is beyond the scope of Similar assumptions and requirements were made between NAS and AS in i, so there is precendence]
Chen et.al.Chen et al
John Doe, Some Company

13. Main Concerns on the Pull and Push
Month Year
doc.: IEEE yy/xxxxr0
November 2006
Main Concerns on the Pull and Push
Primary concerns
Pull: If STA and R0KH cannot agree on R1KH-Id, introducing and agreeing on TAP-ID in an authenticated way between STA and R0KH will not add any security
Push: STA is the entity to hand out a key (STA-contribution-key) in plaintext to the target AP. If an AP can get an encrypted version of PMK-R1 very easily, then STA becomes the only entity to determine whether an AP can use the PMK-R1. This is not consistent with the trust model. We shall trust an R0KH more than an STA.
More on pull: Using a higher level key MK in the key hierarchy to decrypt STA selected cipher-text will make it vulnerable to “chosen cipher-text attack”.
More on push: The shared key K does not add more security if we cannot depend on established trust between R0KH and R1KH.
Secondary concerns
Pull: R0KH involvement in each FT.
Push: Different key hierarchy for STA to derive.
Impact on having added cryptographic and more memory requirements on both STA and AP. In particular, STA’s ability to do the crypto and retain optimal transition time as well as maintain battery life.
Chen et.al.Chen et al
John Doe, Some Company

14. Month Year
doc.: IEEE yy/xxxxr0
November 2006
Suggestions
We should not introduce something which we cannot specify. That is, we should not use one “unsure” to replace another “unsure”.
TGR should include clear requirements or/and assumptions on PMK-R1 distribution.
D A.6.1 and 8.5A.6.2 should be brought back and the additions below be made in section 8.5A.7.
“Even though the protocol for distribution of PMK-R1 from a R0KH is outside of the scope of this specification, PMK-R1 distribution must satisfy the following assumptions.
The R0KH authenticates a potential R1KH with the identity binding to PMK-R1 derivation.
The authorization of holding a PMK-R1 is based on the authentication.
The R0KH and a R1KH establish a mutually authenticated protection channel to deliver a PMK-R1. The mutual authentication may be supported by the Mobility Domain Controller. If the mutual authentication is separate from the authentication to authorize a R1KH, then R1KH must bind the same identity with the mutual authenticated protection channel.
The protection provides confidentiality and authenticity.
Chen et.al.Chen et al
John Doe, Some Company