draft-ietf-emu-rfc5448bis-07.txt   draft-ietf-emu-rfc5448bis-08.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft V. Lehtovirta Internet-Draft V. Lehtovirta
Obsoletes: 5448 (if approved) V. Torvinen Obsoletes: 5448 (if approved) V. Torvinen
Updates: 4187 (if approved) Ericsson Updates: 4187 (if approved) Ericsson
Intended status: Informational P. Eronen Intended status: Informational P. Eronen
Expires: September 10, 2020 Independent Expires: May 3, 2021 Independent
March 9, 2020 October 30, 2020
Improved Extensible Authentication Protocol Method for 3GPP Mobile Improved Extensible Authentication Protocol Method for 3GPP Mobile
Network Authentication and Key Agreement (EAP-AKA') Network Authentication and Key Agreement (EAP-AKA')
draft-ietf-emu-rfc5448bis-07 draft-ietf-emu-rfc5448bis-08
Abstract Abstract
The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the
primary authentication mechanism for devices wishing to access mobile primary authentication mechanism for devices wishing to access mobile
networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible
within the Extensible Authentication Protocol (EAP) framework. RFC within the Extensible Authentication Protocol (EAP) framework. RFC
5448 (EAP-AKA') was an improved version of EAP-AKA. 5448 (EAP-AKA') was an improved version of EAP-AKA.
This memo replaces the specification of EAP-AKA'. EAP-AKA' was This memo replaces the specification of EAP-AKA'. EAP-AKA' was
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020. This Internet-Draft will expire on May 3, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 50 skipping to change at page 2, line 50
4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 18 4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 18
4.1. Summary of Attributes for EAP-AKA . . . . . . . . . . . . 20 4.1. Summary of Attributes for EAP-AKA . . . . . . . . . . . . 20
5. Peer Identities . . . . . . . . . . . . . . . . . . . . . . . 20 5. Peer Identities . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Username Types in EAP-AKA' Identities . . . . . . . . . . 20 5.1. Username Types in EAP-AKA' Identities . . . . . . . . . . 20
5.2. Generating Pseudonyms and Fast Re-Authentication 5.2. Generating Pseudonyms and Fast Re-Authentication
Identities . . . . . . . . . . . . . . . . . . . . . . . 21 Identities . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. Identifier Usage in 5G . . . . . . . . . . . . . . . . . 22 5.3. Identifier Usage in 5G . . . . . . . . . . . . . . . . . 22
5.3.1. Key Derivation . . . . . . . . . . . . . . . . . . . 23 5.3.1. Key Derivation . . . . . . . . . . . . . . . . . . . 23
5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY
Attribute . . . . . . . . . . . . . . . . . . . . . . 24 Attribute . . . . . . . . . . . . . . . . . . . . . . 24
6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 26 6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 31 7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29
7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 33 7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 32
7.4. Security Properties of Binding Network Names . . . . . . 34 7.4. Security Properties of Binding Network Names . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 34
8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 35 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 34
8.3. Key Derivation Function Namespace . . . . . . . . . . . . 35 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . 38 9.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 41 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 40
Appendix B. Changes to RFC 4187 . . . . . . . . . . . . . . . . 41 Appendix B. Changes to RFC 4187 . . . . . . . . . . . . . . . . 40
Appendix C. Changes from Previous Version of This Draft . . . . 42 Appendix C. Changes from Previous Version of This Draft . . . . 41
Appendix D. Importance of Explicit Negotiation . . . . . . . . . 44 Appendix D. Importance of Explicit Negotiation . . . . . . . . . 44
Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 45 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 44
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the
primary authentication mechanism for devices wishing to access mobile primary authentication mechanism for devices wishing to access mobile
networks. [RFC4187] (EAP-AKA) made the use of this mechanism networks. [RFC4187] (EAP-AKA) made the use of this mechanism
possible within the Extensible Authentication Protocol (EAP) possible within the Extensible Authentication Protocol (EAP)
framework [RFC3748]. framework [RFC3748].
[RFC5448] (EAP-AKA') was an improved version of EAP-AKA. This memo [RFC5448] (EAP-AKA') was an improved version of EAP-AKA. This memo
skipping to change at page 20, line 48 skipping to change at page 20, line 48
usernames. This specification extends this definition as follows. usernames. This specification extends this definition as follows.
There are four types of usernames: There are four types of usernames:
(1) Regular usernames. These are external names given to EAP- (1) Regular usernames. These are external names given to EAP-
AKA'. The regular usernames are further subdivided into to AKA'. The regular usernames are further subdivided into to
categories: categories:
(a) Permanent usernames, for instance IMSI-based usernames. (a) Permanent usernames, for instance IMSI-based usernames.
(b) Privacy-friendly temporary usernames, for instance 5G (b) Privacy-friendly temporary usernames, for instance 5G
privacy identifiers (see Section 5.3.2 and Section 5.3.2.1. privacy identifiers (see Section 5.3.2).
(2) EAP-AKA' pseudonym usernames. For example, (2) EAP-AKA' pseudonym usernames. For example,
2s7ah6n9q@example.com might be a valid pseudonym identity. In 2s7ah6n9q@example.com might be a valid pseudonym identity. In
this example, 2s7ah6n9q is the pseudonym username. this example, 2s7ah6n9q is the pseudonym username.
(3) EAP-AKA' fast re-authentication usernames. For example, (3) EAP-AKA' fast re-authentication usernames. For example,
43953754@example.com might be a valid fast re-authentication 43953754@example.com might be a valid fast re-authentication
identity and 43953754 the fast re-authentication username. identity and 43953754 the fast re-authentication username.
The permanent, privacy-friendly temporary, and pseudonym usernames The permanent, privacy-friendly temporary, and pseudonym usernames
skipping to change at page 23, line 19 skipping to change at page 23, line 19
to prepare for many different situations, including sometimes having to prepare for many different situations, including sometimes having
to communicate identities within EAP. to communicate identities within EAP.
The following sections clarify which identifiers are used and how. The following sections clarify which identifiers are used and how.
5.3.1. Key Derivation 5.3.1. Key Derivation
In EAP-AKA', the peer identity is used in the Section 3.3 key In EAP-AKA', the peer identity is used in the Section 3.3 key
derivation formula. derivation formula.
The identity needs to be represented in exact correct format for the
key derivation formulala to produce correct results.
If the AT_KDF_INPUT parameter contains the prefix "5G:", the AT_KDF If the AT_KDF_INPUT parameter contains the prefix "5G:", the AT_KDF
parameter has the value 1, and this authentication is not a fast re- parameter has the value 1, and this authentication is not a fast re-
authentication, then the peer identity used in the key derivation authentication, then the peer identity used in the key derivation
MUST be the 5G SUPI for the peer. This rule applies to all full EAP- MUST be as specified in Annex F.3 of [TS-3GPP.33.501] and Clause 2.2
AKA' authentication processes, even if the peer sent some other of [TS-3GPP.23.003]. This is in contrast to [RFC5448], which used
identifier at a lower layer or as a response to an EAP Identity the identity as communicated in EAP and represented as a NAI. Also,
Request or if no identity was sent. in contrast to [RFC5448], in 5G EAP-AKA' does not use the "0" or "6"
prefix in front of the identifier.
The identity MUST also be represented in the exact correct format for For an example of the format of the identity, see Clause 2.2 of
the key derivation formula to produce correct results. In 5G, this [TS-3GPP.23.003].
identifier is the SUPI. The SUPI format is as defined
Section 5.3.1.1.
In all other cases, the following applies: In all other cases, the following applies:
The identity used in the key derivation formula MUST be exactly The identity used in the key derivation formula MUST be exactly
the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent, the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent,
regardless of the kind of identity that it may have been. If no regardless of the kind of identity that it may have been. If no
AT_IDENTITY was sent, the identity MUST be the exactly the one AT_IDENTITY was sent, the identity MUST be the exactly the one
sent in the generic EAP Identity exchange, if one was made. sent in the generic EAP Identity exchange, if one was made.
Again, the identity MUST be used exactly as sent. Again, the identity MUST be used exactly as sent.
If no identity was communicated inside EAP, then the identity is If no identity was communicated inside EAP, then the identity is
the one communicated outside EAP in link layer messaging. the one communicated outside EAP in link layer messaging.
In this case, the used identity MUST be the identity most recently In this case, the used identity MUST be the identity most recently
communicated by the peer to the network, again regardless of what communicated by the peer to the network, again regardless of what
type of identity it may have been. type of identity it may have been.
5.3.1.1. Format of the SUPI
A SUPI is either an IMSI or a Network Access Identifier [RFC7542].
When used in EAP-AKA', the format of the SUPI MUST be as specified in
[TS-3GPP.23.003] Section 28.7.2, with the semantics defined in
[TS-3GPP.23.003] Section 2.2A. Also, in contrast to [RFC5448], in 5G
EAP-AKA' does not use the "0" or "6" prefix in front of the entire
IMSI.
For instance, if the IMSI is 234150999999999 (MCC = 234, MNC = 15),
the NAI format for the SUPI takes the form:
234150999999999@nai.5gc.mnc015.mcc234.3gppnetwork.org
5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute
The EAP authentication option is only available in 5G when the new 5G The EAP authentication option is only available in 5G when the new 5G
core network is also in use. However, in other networks an EAP-AKA' core network is also in use. However, in other networks an EAP-AKA'
peer may be connecting to other types of networks and existing peer may be connecting to other types of networks and existing
equipment. equipment.
When the EAP peer is connecting to a 5G access network and uses the When the EAP peer is connecting to a 5G access network and uses the
5G Non-Access Stratum (NAS) protocol [TS-3GPP.24.501], the EAP server 5G Non-Access Stratum (NAS) protocol [TS-3GPP.24.501], the EAP server
is in a 5G network. The EAP identity exchanges are generally not is in a 5G network. The EAP identity exchanges are generally not
used in this case, as the identity is already made available on used in this case, as the identity is already made available on
previous link layer exchanges. previous link layer exchanges.
In this situation, the EAP server SHOULD NOT request an additional In this situation, the EAP Identity Response and EAP-AKA' AT_IDENTITY
identity from the peer. If the peer for some reason receives EAP- attribute are handled as specified in Annex F.2 of [TS-3GPP.33.501].
Request/Identity or EAP-Request/AKA-Identity messages, the peer
behaves as follows.
Receive EAP-Request/Identity
In this case, the peer MUST respond with a EAP-Response/Identity
containing the privacy-friendly 5G identifier, the SUCI. The SUCI
MUST be represented as specified in Section 5.3.2.1.
EAP-Request/AKA-Identity with AT_PERMANENT_REQ
For privacy reasons, the peer MUST follow a "conservative" policy
and terminate the authentication exchange rather than risk
revealing its permanent identity.
The peer MUST respond with EAP-Response/AKA-Client-Error with the
client error code 0, "unable to process packet".
EAP-Request/AKA-Identity with AT_FULLAUTH_REQ
In this case, the peer MUST respond with a EAP-Response/AKA-
Identity containing the SUCI. The SUCI MUST be represented as
specified in Section 5.3.2.1.
EAP-Request/AKA-Identity with AT_ANY_ID_REQ
If the peer supports fast re-authentication and has a fast re-
authentication identity available, the peer SHOULD respond with
EAP-Response/AKA-Identity containing the fast re-authentication
identity. Otherwise the peer MUST respond with a EAP-Response/
AKA-Identity containing the SUCI, and MUST represent the SUCI as
specified in Section 5.3.2.1.
Similarly, if the peer is communicating over a non-3GPP network but
carrying EAP inside 5G NAS protocol, it MUST assume that the EAP
server is in a 5G network, and again employ the SUCI within EAP.
Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is
configured to use.
5.3.2.1. Format of the SUCI
When used in EAP-AKA', the format of the SUCI MUST be as specified in When used in EAP-AKA', the format of the SUCI MUST be as specified in
[TS-3GPP.23.003] Section 28.7.3, with the semantics defined in [TS-3GPP.23.003] Section 28.7.3, with the semantics defined in
[TS-3GPP.23.003] Section 2.2B. Also, in contrast to [RFC5448], in 5G [TS-3GPP.23.003] Section 2.2B. Also, in contrast to [RFC5448], in 5G
EAP-AKA' does not use the "0" or "6" prefix in front of the EAP-AKA' does not use the "0" or "6" prefix in front of the
identifier. identifier.
For instance, assuming the IMSI 234150999999999, where MCC=234, For an example of an IMSI in NAI format, see [TS-3GPP.23.003]
MNC=15 and MSISN=0999999999, the Routing Indicator 678, and a Home Section 28.7.3.
Network Public Key Identifier of 27, the NAI format for the SUCI
takes the form:
For the null-scheme:
type0.rid678.schid0.userid0999999999@nai.5gc.mnc015.
mcc234.3gppnetwork.org
For the Profile <A> protection scheme:
type0.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key>. Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is
cip<encryption of 0999999999>.mac<MAC tag value>@nai.5gc. configured to use.
mnc015.mcc234.3gppnetwork.org
6. Exported Parameters 6. Exported Parameters
The EAP-AKA' Session-Id is the concatenation of the EAP Type Code The EAP-AKA' Session-Id is the concatenation of the EAP Type Code
(0x32, one byte) with the contents of the RAND field from the AT_RAND (0x32, one byte) with the contents of the RAND field from the AT_RAND
attribute, followed by the contents of the AUTN field in the AT_AUTN attribute, followed by the contents of the AUTN field in the AT_AUTN
attribute: attribute:
Session-Id = 0x32 || RAND || AUTN Session-Id = 0x32 || RAND || AUTN
skipping to change at page 29, line 51 skipping to change at page 28, line 32
EAP-AKA' uses several different types of identifiers to identify the EAP-AKA' uses several different types of identifiers to identify the
authenticating peer. It is strongly RECOMMENDED to use the privacy- authenticating peer. It is strongly RECOMMENDED to use the privacy-
friendly temporary or hidden identifiers, i.e., the 5G SUCI, friendly temporary or hidden identifiers, i.e., the 5G SUCI,
pseudonym usernames, and fast re-authentication usernames. The use pseudonym usernames, and fast re-authentication usernames. The use
of permanent identifiers such as the IMSI or SUPI may lead to an of permanent identifiers such as the IMSI or SUPI may lead to an
ability to track the peer and/or user associated with the peer. The ability to track the peer and/or user associated with the peer. The
use of permanent identifiers such as the IMSI or SUPI is strongly NOT use of permanent identifiers such as the IMSI or SUPI is strongly NOT
RECOMMENDED. RECOMMENDED.
As discussed in Section 5.3, when authenticating to a 5G network, As discussed in Section 5.3, when authenticating to a 5G network,
only the 5G SUCI identifier should be used. The use of EAP-AKA' only the 5G SUCI identifier is normally used. The use of EAP-AKA'
pseudonyms in this situation is at best limited, because the 5G SUCI pseudonyms in this situation is at best limited, because the 5G SUCI
already provides a stronger mechanism. In fact, the re-use of the already provides a stronger mechanism. In fact, the re-use of the
same pseudonym multiple times will result in a tracking opportunity same pseudonym multiple times will result in a tracking opportunity
for observers that see the pseudonym pass by. To avoid this, the for observers that see the pseudonym pass by. To avoid this, the
peer and server need to follow the guidelines given in Section 5.2. peer and server need to follow the guidelines given in Section 5.2.
When authenticating to a 5G network, per Section 5.3.1, both the EAP- When authenticating to a 5G network, per Section 5.3.1, both the EAP-
AKA' peer and server need to employ the permanent identifier, SUPI, AKA' peer and server need to employ the permanent identifier, SUPI,
as an input to key derivation. However, this use of the SUPI is only as an input to key derivation. However, this use of the SUPI is only
internal. As such, the SUPI need not be communicated in EAP internal. As such, the SUPI need not be communicated in EAP
skipping to change at page 39, line 50 skipping to change at page 38, line 45
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[I-D.ietf-emu-aka-pfs] [I-D.ietf-emu-aka-pfs]
Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward
Secrecy for the Extensible Authentication Protocol Method Secrecy for the Extensible Authentication Protocol Method
for Authentication and Key Agreement (EAP-AKA' PFS)", for Authentication and Key Agreement (EAP-AKA' PFS)",
draft-ietf-emu-aka-pfs-02 (work in progress), November draft-ietf-emu-aka-pfs-04 (work in progress), May 2020.
2019.
[Heist2015] [Heist2015]
Scahill, J. and J. Begley, "The great SIM heist", February Scahill, J. and J. Begley, "The great SIM heist", February
2015, in https://firstlook.org/theintercept/2015/02/19/ 2015, in https://firstlook.org/theintercept/2015/02/19/
great-sim-heist/ . great-sim-heist/ .
[MT2012] Mjolsnes, S. and J-K. Tsay, "A vulnerability in the UMTS [MT2012] Mjolsnes, S. and J-K. Tsay, "A vulnerability in the UMTS
and LTE authentication and key agreement protocols", and LTE authentication and key agreement protocols",
October 2012, in Proceedings of the 6th international October 2012, in Proceedings of the 6th international
conference on Mathematical Methods, Models and conference on Mathematical Methods, Models and
skipping to change at page 44, line 46 skipping to change at page 43, line 38
specifications, such as key derivation for AKA, would affect this specifications, such as key derivation for AKA, would affect this
specification and implementations. specification and implementations.
o References have been updated to the latest Release 15 versions, o References have been updated to the latest Release 15 versions,
that are now stable. that are now stable.
o Tables have been numbered. o Tables have been numbered.
o Adopted a number of other editorial corrections. o Adopted a number of other editorial corrections.
The version -08 includes the following changes:
o Alignment of the 3GPP TS Annex and this draft, so that each
individual part of the specification is stated in only one place.
This has lead to this draft referring to bigger parts of the 3GPP
specification, instead of spelling out the details within this
document. Note that this alignment change is a proposal at this
stage, and will be discussed in the upcoming 3GPP meeting.
o Relaxed the language on using only SUCI in 5G. While that is the
mode of operation expected to be used, [TS-3GPP.33.501] does not
prohibit other types of identifiers.
Appendix D. Importance of Explicit Negotiation Appendix D. Importance of Explicit Negotiation
Choosing between the traditional and revised AKA key derivation Choosing between the traditional and revised AKA key derivation
functions is easy when their use is unambiguously tied to a functions is easy when their use is unambiguously tied to a
particular radio access network, e.g., Long Term Evolution (LTE) as particular radio access network, e.g., Long Term Evolution (LTE) as
defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined
by 3GPP2. There is no possibility for interoperability problems if by 3GPP2. There is no possibility for interoperability problems if
this radio access network is always used in conjunction with new this radio access network is always used in conjunction with new
protocols that cannot be mixed with the old ones; clients will always protocols that cannot be mixed with the old ones; clients will always
know whether they are connecting to the old or new system. know whether they are connecting to the old or new system.
 End of changes. 16 change blocks. 
107 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/