Lawful interception Lawful interception (LI) is obtaining communications network data pursuant to lawful authority for the purpose

of analysis or evidence. Such data generally consist of signalling or network management information or, in fewer instances, the content of the communications. If the data are not obtained in real-time, the activity is referred to as access to retained data (RD). There are many bases for this activity that include infrastructure protection and cybersecurity. In general, the operator of public network infrastructure can undertake LI activities for those purposes. Operators of private network infrastructures have an inherent right to maintain LI capabilities within their own networks unless otherwise prohibited. One of the bases for LI is the interception of telecommunications by law enforcement agencies (LEAs), regulatory or administrative agencies, and intelligence services, in accordance with local law. Under some legal systems, implementationsparticularly real-time access to contentmay require due process and receiving proper authorization from competent authoritiesan activity that was formerly known as "wiretapping" and has existed since the inception of electronic communications. The material below primarily treats this narrow segment of LI. With the legacy public switched telephone network (PSTN), wireless, and cable systems, lawful interception (LI) was generally performed by accessing the mechanical or digital switches supporting the targets' calls. The introduction of packet switched networks, softswitch technology, and server-based applications the past two decades fundamentally altered how LI is undertaken.

Technical description Almost all countries have LI capability requirements and have implemented them using global LI requirements and standards developed by the European Telecommunications Standards Institute (ETSI), 3rd Generation Partnership Project (3GPP), or CableLabs organizationsfor wireline/Internet, wireless, and cable systems, respectively. In the USA, the comparable requirements are enabled by the Communications Assistance for Law Enforcement Act (CALEA), with the specific capabilities promulgated jointly by the Federal Communications Commission and the Department of Justice.

In order to prevent investigations being compromised, LI systems may be designed in a manner that hides the interception from the telecommunications operator concerned. This is a requirement in some jurisdictions. To ensure systematic procedures for carrying out interception, while also lowering the costs of interception solutions, industry groups and government agencies worldwide have attempted to standardize the technical processes behind lawful interception. One organization, ETSI, has been a major driver in lawful interception standards not only for Europe, but worldwide. This architecture attempts to define a systematic and extensible means by which network operators and law enforcement agents (LEAs) can interact, especially as networks grow in sophistication and scope of services. Note this architecture applies to not only traditional wireline and wireless voice calls, but to IP-based services such as Voice over IP, email, instant messaging, etc. The architecture is now applied worldwide (in some cases with slight variations in terminology), including in the United States in the context of CALEA conformance. Three stages are called for in the architecture: 1. 2. 3. collection where target-related call data and content are extracted mediation where the data is formatted to conform to specific standards delivery of the data and content to the law enforcement agency (LEA).

from the network

The call data (known as Intercept Related Information or IRI in Europe and Call Data or CD in the US) consists of information about the targeted communications, including destination of a voice call (e.g., called partys telephone number), source of a call (callers phone number), time of the call, duration, etc. Call content is namely the stream of data carrying the call. Included in the architecture is the lawful interception management function, which covers interception session set-up and tear down, scheduling, target identification, etc. Communications between the network operator and LEA are via the Handover Interfaces (designated HI). Communications data and content are typically delivered from the network operator to the LEA in an encrypted format over an IP-based VPN. The interception of traditional voice calls still often relies on the establishment of an ISDN channel that is set up at the time of the interception.

As stated above, the ETSI architecture is equally applicable to IP-based services where IRI (or CD) is dependent on parameters associated with the traffic from a given application to be intercepted. For example, in the case of email IRI would be similar to the header information on an email message (e.g., destination email address, source email address, time email was transmitted) as well as pertinent header information within the IP packets conveying the message (e.g., source IP address of email server originating the email message). Of course, more in-depth information would be obtained by the interception system so as to avoid the usual email address spoofing that often takes place (e.g., spoofing of source address). Voice-over-IP likewise has its own IRI, including data derived from Session Initiation Protocol (SIP) messages that are used to set up and tear down a VOIP call. ETSI LI Technical Committee work today is primarily focussed on developing the new Retained Data Handover and Next Generation Networkspecifications, as well as perfecting the innovative TS102232 standards suite that apply to most contemporary network uses. USA interception standards that help network operators and service providers conform to CALEA are mainly those specified by the Federal Communications Commission (which has both plenary legislative and review authority under CALEA) CableLabs, and the Alliance for Telecommunications Industry Solutions (ATIS). ATIS's standards include new standards for broadband Internet access and VoIP services, as well as legacy J-STD-025B which updates the earlier J-STD-025A to include packetized voice and CDMA wireless interception. All of these standards have been challenged as "deficient" by the U.S. Dept of Justice pursuant to CALEA. Generic global standards have also been developed by Cisco via the Internet Engineering Task Force (IETF) that provide a front-end means of supporting most LI real-time handover standards.

RADIUS

Remote Authentication Dial In User Service (RADIUS) is a networking protocol that provides centralized Authentication, Authorization, and

Accounting (AAA) management for computers to connect and use a network service. RADIUS was developed by Livingston Enterprises, Inc., in 1991 as an access server authentication and accounting protocol and later brought into the Internet Engineering Task Force (IETF) standards.[1] Because of the broad support and the ubiquitous nature of the RADIUS protocol, it is often used byISPs and enterprises to manage access to the Internet or internal networks, wireless networks, and integrated e-mail services. These networks may incorporate modems, DSL, access points, VPNs,network ports, web servers, etc.
[2]

RADIUS is a client/server protocol that runs in the application layer, using UDP as transport. TheRemote Access Server, the Virtual Private Network server, the Network switch with port-based authentication, and the Network Access Server (NAS), are all gateways that control access to the network, and all have a RADIUS client component that communicates with the RADIUS server. The RADIUS server is usually a background process running on a UNIX or Windows NT machine.[3]RADIUS serves three functions: 1. 2. 3. AAA RADIUS servers use the AAA concept to manage network access in the following twostep process, also known as an "AAA transaction". AAA stands for authentication, authorization and accounting. Authentication and Authorization characteristics in RADIUS are described inRFC 2865 while Accounting is described by RFC 2866. to authenticate users or devices before granting them access to a to authorize those users or devices for certain network services and to account for usage of those services.

network,

Authentication and authorization The user or machine sends a request to a Remote Access Server (RAS) to gain access to a particular network resource using access credentials. The credentials are passed to the RAS device via the link-layer protocol - for example, Point-to-Point Protocol (PPP) in the case of many dialup or DSL providers or posted in an HTTPS secure web form.

In turn, the RAS sends a RADIUS Access Request message to the RADIUS server, requesting authorization to grant access via the RADIUS protocol.[4] This request includes access credentials, typically in the form of username and password or security certificate provided by the user. Additionally, the request may contain other information which the RAS knows about the user, such as its network address or phone number, and information regarding the user's physical point of attachment to the RAS. The RADIUS server checks that the information is correct using authentication schemes like PAP, CHAP or EAP. The user's proof of identification is verified, along with, optionally, other information related to the request, such as the user's network address or phone number, account status and specific network service access privileges. Historically, RADIUS servers checked the user's information against a locally stored flat file database. Modern RADIUS servers can do this, or can refer to external sources - commonly SQL, Kerberos, LDAP, or Active Directory servers - to verify the user's credentials.

RADIUS Authentication and Authorization Flow The RADIUS server then returns one of three responses to the NAS : 1) Access Reject, 2) Access Challenge or 3) Access Accept.

Access Reject - The user is unconditionally denied access to all requested

network resources. Reasons may include failure to provide proof of identification or an unknown or inactive user account.

Access Challenge - Requests additional information from the user such as a

secondary password, PIN, token or card. Access Challenge is also used in more complex authentication dialogs where a secure tunnel is established between the

user machine and the Radius Server in a way that the access credentials are hidden from the RAS.

Access Accept - The user is granted access. Once the user is authenticated, the

RADIUS server will often check that the user is authorised to use the network service requested. A given user may be allowed to use a company's wireless network, but not its VPN service, for example. Again, this information may be stored locally on the RADIUS server, or may be looked up in an external source like LDAP or Active Directory. Authorization attributes are conveyed to the RAS stipulating terms of access to be granted. For example: the following authorization attributes may be included in an Access-Accept.

The specific IP address to be assigned to the user The address pool from which the user's IP should be chosen The maximum length that the user may remain connected An access list, priority queue or other restrictions on a user's access L2TP parameters VLAN parameters Quality of Service (QoS) parameters

Each of these three RADIUS responses may include a Reply-Message attribute which may give a reason for the rejection, the prompt for the challenge, or a welcome message for the accept. The text in the attribute can be passed on to the user in a return web page.

Accounting

RADIUS Accounting Flow Accounting is described in RFC 2866. When network access is granted to the user by the NAS, an Accounting Start (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "start") is sent by the NAS to the RADIUS server to signal the start of the user's network access. "Start" records typically contain the user's identification, network address, point of attachment and a unique session identifier.[5] Periodically, Interim Update records (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "interim-update") may be sent by the NAS to the RADIUS server, to update it on the status of an active session. "Interim" records typically convey the current session duration and information on current data usage. Finally, when the user's network access is closed, the NAS issues a finalAccounting Stop record (a RADIUS Accounting Request packet containing an Acct-Status-Type attribute with the value "stop") to the RADIUS server, providing information on the final usage in terms of time, packets transferred, data transferred, reason for disconnect and other information related to the user's network access. Typically, the client sends Accounting-Request packets until it receives an Accounting-Response acknowledgement, using some retry interval.

The primary purpose of this data is that the user can be billed accordingly; the data is also commonly used for statistical purposes and for general network monitoring.

Roaming

Roaming using a proxy RADIUS AAA server. RADIUS is commonly used to facilitate roaming between ISPs, for example:

by companies which provide a single global set of credentials that are usable by independent, but collaborating, institutions issuing their own credentials to

on many public networks;

their own users, that allow a visitor from one to another to be authenticated by their home institution, such as in Eduroam. RADIUS facilitates this by the use of realms, which identify where the RADIUS server should forward the AAA requests for processing. Realms A realm is commonly appended to a user's user name and delimited with an '@' sign, resembling an email address domain name. This is known as postfix notation for the realm. Another common usage is prefix notation, which involves prepending the realm to the username and using '\' as a delimiter. Modern RADIUS servers allow any character to be used as a realm delimiter, although in practice '@' and '\' are usually used. Realms can also be compounded using both prefix and postfix notation, to allow for complicated roaming scenarios; for example,

somedomain.com\username@anotherdomain.com could be a valid username with two realms. Although realms often resemble email domains, it is important to note that realms are in fact arbitrary text and need not contain real domain names. Proxy operations When a RADIUS server receives an AAA request for a user name containing a realm, the server will reference a table of configured realms. If the realm is known, the server will then proxy the request to the configured home server for that domain. The behaviour of the proxying server regarding the removal of the realm from the request ("stripping") is configuration-dependent on most servers. In addition, the proxying server can be configured to add, remove or rewrite AAA requests when they are proxied. Security Roaming with RADIUS exposes the users to various security and privacy concerns. More generally, some roaming partners establish a secure tunnel between the RADIUS servers to ensure that users' credentials cannot be intercepted while being proxied across the internet. This is a concern as the MD5 hash built into RADIUS is considered insecure.[6]

acket structure

RADIUS packet data format. The RADIUS packet data format is shown to the right. The fields are transmitted from left to right, starting with the code, the identifier, the length, the authenticator and the attributes. RADIUS Codes (decimal) are assigned as follows: Cod e

Assignment

Access-Request

Access-Accept

Access-Reject

Accounting-Request

Accounting-Response

11

Access-Challenge

12

Status-Server (experimental)

13

Status-Client (experimental)

255 Reserved The Identifier field aids in matching requests and replies. The Length field indicates the length of the entire RADIUS packet including the Code, Identifier, Length, Authenticator and optional Attribute fields. The Authenticator is used to authenticate the reply from the RADIUS server, and is used in encrypting passwords, its length is 16 bytes. Attribute value pairs

RADIUS AVP layout. The RADIUS Attribute Value Pairs (AVP) carry data in both the request and the response for the authentication, authorization, and accounting transactions. The length of the radius packet is used to determine the end of the AVPs. AVP Type

Assignment

User-Name

User-Password

CHAP-Password

NAS-IP-Address

NAS-Port

Service-Type

Framed-Protocol

Framed-IP-Address

Framed-IP-Netmask

10

Framed-Routing

11

Filter-Id

12

Framed-MTU

13

Framed-Compression

14

Login-IP-Host

15

Login-Service

16

Login-TCP-Port

17

(unassigned)

18

Reply-Message

19

Callback-Number

20

Callback-Id

21

(unassigned)

22

Framed-Route

23

Framed-IPX-Network

24

State

25

Class

26

Vendor-Specific

27

Session-Timeout

28

Idle-Timeout

29

Termination-Action

30

Called-Station-Id

31

Calling-Station-Id

32

NAS-Identifier

33

Proxy-State

34

Login-LAT-Service

35

Login-LAT-Node

36

Login-LAT-Group

37

Framed-AppleTalk-Link

38

Framed-AppleTalkNetwork

39

Framed-AppleTalk-Zone

40

Acct-Status-Type

41

Acct-Delay-Time

42

Acct-Input-Octets

43

Acct-Output-Octets

44

Acct-Session-Id

45

Acct-Authentic

46

Acct-Session-Time

47

Acct-Input-Packets

48

Acct-Output-Packets

49

Acct-Terminate-Cause

50

Acct-Multi-Session-Id

51

Acct-Link-Count

52-59

(reserved for accounting)

60

CHAP-Challenge

61

NAS-Port-Type

62

Port-Limit

63

Login-LAT-Port

Vendor-specific attributes RADIUS is extensible; many vendors of RADIUS hardware and software implement their own variants using Vendor-Specific Attributes (VSAs). Microsoft has published some of their VSAs.[7] VSA definitions from many other companies remain proprietary and/or ad-hoc.

UDP port numbers RADIUS has been officially assigned UDP ports 1812 for RADIUS Authentication and 1813 for RADIUS Accounting by the Internet Assigned Numbers Authority (IANA). However, prior to IANA allocation of ports 1812 and 1813, ports 1645 and 1646 (authentication and accounting, respectively) were used unofficially and became the default ports assigned by many RADIUS Client/Server implementations of the time. The tradition of using 1645 and 1646 for backwards compatibility continues to this day. For this reason many RADIUS Server implementations monitor both sets of UDP ports for RADIUS requests. Microsoft RADIUS servers default to 1812 and 1813 but Cisco devices default to the traditional 1645 and 1646 ports. Juniper Networks' RADIUS servers listen on both unofficial and official ports 1645, 1812, 1646 and 1813 by default but can be configured with arbitrary ports.SBR Security The RADIUS protocol does not transmit passwords in cleartext between the NAS and RADIUS server (not even with PAP protocol). Rather, a shared secret is used along with the MD5 hashing algorithm to obfuscate passwords. Because this particular implementation is not considered to be a very strong protection of the user's credentials[8], additional protection - such as IPsec tunnels or physically-secured datacenter networks - should be used to further protect the RADIUS traffic between the NAS device and the RADIUS server. Additionally, the user's security credentials are the only part protected by RADIUS itself, yet other user-specific attributes such as tunnel-group IDs or vlan memberships passed over RADIUS may be considered sensitive (helpful to an attacker) or private (sufficient to identify the individual client) information as well.[citation needed] RADIUS history RADIUS was originally specified in an RFI by Merit Network in 1991 to control dial-in access to NSFnet. Livingston Enterprises responded to the RFI with a description of a RADIUS server. Merit Network awarded the contract to Livingston Enterprises that delivered their PortMaster series of Network Access Servers and the initial RADIUS server to Merit. RADIUS was later (1997) published as RFC 2058 and RFC 2059 (current versions are RFC 2865 and RFC 2866).[1]

Now, several commercial and open-source RADIUS servers exist. Features can vary, but most can look up the users in text files, LDAPservers, various databases, etc. Accounting records can be written to text files, various databases, forwarded to external servers, etc. SNMPis often used for remote monitoring and keep-alive checking of a RADIUS server. RADIUS proxy servers are used for centralized administration and can rewrite RADIUS packets on the fly (for security reasons, or to convert between vendor dialects). The Diameter protocol is the planned replacement for RADIUS. Diameter uses SCTP or TCP while RADIUS uses UDP as the transport layer. RFCs The RADIUS protocol is currently defined in the following IETF RFCs: Obsolete RFCs are indicated with strikethrough text. Date Obsolete publishe Related article d by d

Title

Notes

RFC Remote Authentication January 205 Dial In User Service 1997 8 (RADIUS)

RADIUS

RFC 2138

RFC 205 RADIUS Accounting 9

January 1997

RADIUS

RFC 2139

RFC Remote Authentication 213 Dial In User Service April 1997 RADIUS 8 (RADIUS)

RFC 2865

RFC 213 RADIUS Accounting 9

April 1997 RADIUS

RFC 2866

RFC Microsoft Vendor254 specific RADIUS

March

RADIUS

Attributes

1999

RFC Proxy Chaining and 260 Policy Implementation 7 in Roaming

June 1999

RFC RADIUS Authentication 261 Client MIB 8

Management RFC 4668 information base

RFC RADIUS Authentication 261 Server MIB 9

Management RFC 4669 information base

RFC RADIUS Accounting 262 Client MIB 0

June 1999

Management RFC 4670 information base

RFC RADIUS Accounting 262 Server MIB 1

June 1999

Management RFC 4671 information base

RFC Implementation of L2TP 280 Compulsory Tunneling April 2000 9 via RADIUS

RFC Remote Authentication 286 Dial In User Service June 2000 RADIUS 5 (RADIUS)

Updated by: RFC 2868,RFC 3575, RFC 5080

RFC 286 RADIUS Accounting 6

June 2000 RADIUS

RFC RADIUS Accounting 286 Modifications for Tunnel June 2000 RADIUS 7 Protocol Support

Updates RFC 2866

RFC RADIUS Attributes for 286 June 2000 Tunnel Protocol Support 8

Updates RFC 2865

RFC 286 RADIUS Extensions 9

June 2000

updated by RFC 3579,RFC 5080

Network Access Servers RFC Requirements: 288 July 2000 Extended RADIUS 2 Practices

RFC 316 RADIUS and IPv6 2

August 2001

RFC IANA Considerations for 357 July 2003 RADIUS 5

RFC Dynamic Authorization 357 July 2003 Extensions to RADIUS 6

RFC 5176

RFC Extensible Septembe 357 RADIUS Support for EAP Authentication r 2003 9 Protocol

Updates: RFC 2869

RFC IEEE 802.1X RADIUS 358 Usage Guidelines 0

Septembe 802.1X r 2003

RADIUS Attributes RFC Suboption for the DHCP February 401 Relay Agent 2005 4 Information Option

RFC Chargeable User 437 Identity 2

January 2006

RFC RADIUS Extension for 459 Digest Authentication 0

July 2006

RFC 5090

RFC RADIUS Authentication August 466 Client MIB for IPv6 2006 8

Management information base

RFC RADIUS Authentication August 466 Server MIB for IPv6 2006 9

Management information base

RFC RADIUS Accounting 467 Client MIB for IPv6 0

August 2006

Management information base

RFC RADIUS Accounting 467 Server MIB for IPv6 1

August 2006

Management information base

RFC RADIUS Attributes for Septembe 467 Virtual LAN and Priority r 2006 5 Support

RFC DSL Forum Vendor467 Specific RADIUS 9 Attributes

Septembe r 2006

RFC RADIUS Delegated481 IPv6-Prefix Attribute 8

April 2007

RFC RADIUS Filter Rule 484 Attribute 9

April 2007

RFC Common RADIUS December 508 Implementation Issues 2007 0 and Suggested Fixes

Updates RFC 3579

RFC RADIUS Extension for 509 Digest Authentication 0

February 2008

RFC Dynamic Authorization January 517 Extensions to RADIUS 2008 6

RFC RADIUS Authorization 560 for NAS Management 7

July 2009

RFC Use of Status-Server 599 Packets in the RADIUS 7 Protocol

August 2010

Updates RFC 2866

Policy charging and rules function Policy charging and rules function (PCRF) is the node designated in real-time to determine policy rules in a multimedia network.[1] As a policy tool, the PCRF plays a central role in next-generation networks.[2] Unlike earlier policy engines that were added on to an existing network to enforce policy, the PCRF is a software component that operates at the network core and efficiently accesses subscriber databases and other specialized functions, such as a charging systems, in a scalable, reliable, and centralized manner.[3] The PCRF is the part of the network architecture that aggregates information to and from the network, operational support systems, and other sources (such as portals) in real time, supporting the creation of rules and then automatically making intelligent policy decisions for each subscriber active on the network. Such a network might offer multiple services, quality of service (QoS) levels, and charging rules.[