Dec 12, 2008

Received Signal Strength Indication(RSSI)

In telecommunications, Received Signal Strength Indication (RSSI) is a measurement of the power present in a received radio signal.

RSSI is generic radio receiver technology metric, which is usually invisible to the user of device containing the receiver, but is directly known to users of wireless networking of IEEE 802.11 protocol family.

RSSI is often done in the intermediate frequency (IF) stage before the IF amplifier. In zero-IF systems, it is done in the baseband signal chain, before the baseband amplifier. RSSI output is often a DC analog level. It can also be sampled by an internal ADC and the resulting codes available directly or via peripheral or internal processor bus.

RSSI in 802.11 implementations
In an IEEE 802.11 system RSSI is the received signal strength in a wireless environment, in arbitrary units. RSSI can be used internally in a wireless networking card to determine when the amount of radio energy in the channel is below a certain threshold at which point the network card is clear to send (CTS). Once the card is clear to send, a packet of information can be sent. The end-user will likely observe an RSSI value when measuring the signal strength of a wireless network through the use of a wireless network monitoring tool like Network Stumbler or Inssider (for Windows Vista).

RSSI measurements will vary from 0 to a maximum of 255 depending on the vendor. It consists of a one-byte integer value. A value of 1 will indicate the minimum signal strength detectable by the wireless card, while 0 indicates no signal. The value has a maximum of RSSI_Max. For example, Cisco Systems cards will return an RSSI of 0 to 100. In this case, the RSSI_Max is 100. The Cisco card can report 101 distinct power levels. Another popular Wi-Fi chipset is made by Atheros. An Atheros based card will return an RSSI value of 0 to 127 and a value of 0x80 indicates an invalid number

The subtlety of 802.11 RSSI comes from how it's sampled; RSSI is acquired during the preamble stage of receiving an 802.11 frame. To this extent 802.11 RSSI has (for the most part) been replaced with RCPI; a functional measurement covering the entire received frame with defined absolute levels of accuracy and resolution.

RSSI is stored on TX/RX descriptor and was measured by baseband and PHY for each individual packet.

Simple Object Access Protocol(SOAP)

SOAP的全名為Simple Object Access Protocol(簡易物件通訊協定),是一種以XML為基礎的通訊協定,其作用是編譯網路服務所需的要求或回應後,再將編譯後的訊息送出到網路,簡單來說就是應用程式和用戶之間傳輸資料的一種機制。

SOAP的全名為Simple Object Access Protocol(簡易物件通訊協定),是一種以XML為基礎的通訊協定,其作用是編譯網路服務所需的要求或回應後,再將編譯後的訊息送出到網路,簡單來說就是應用程式和用戶之間傳輸資料的一種機制。






Dec 11, 2008

Cipher Block Chaining Message Authentication Code Protocol (CCMP)

Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) is an encryption protocol that forms part of the 802.11i standard for wireless local area networks (WLANs), particularly those using WiMax technology. The CCMP algorithm is based on the U.S. federal government's Advanced Encryption Standard (AES).
CCMP offers enhanced security compared with similar technologies such as Temporal Key Integrity Protocol (TKIP). CCMP employs 128-bit keys and a 48-bit initialization vector that minimizes vulnerability to replay attacks. The Counter Mode component provides data privacy. The Cipher Block Chaining Message Authentication Code component provides data integrity and authentication. The enhanced privacy and security of CCMP compared with TKIP requires additional processing power, often necessitating new or upgraded hardware.

802.11i is a standard for WLANs that provides encryption for networks that use the 802.11a, 802.11b and 802.11g standards. The AES is an encryption algorithm for securing sensitive but unclassified material by government agencies. It may eventually become the de facto encryption standard for commercial transactions in the private sector.

Proactive Key Caching(PKC)

PKC is an IEEE 802.11i extension that allows for the proactive caching (before the client roaming event) of the WPA/WPA2 PMK that is derived during a client IEEE 802.1 x/EAP authentication at the AP. If a PMK (for a given WLAN client) is already present at an AP when presented by the associating client, full IEEE 802.1X/EAP authentication is not required. Instead, the WLAN client can simply use the WPA 4-way handshake process to securely derive a new session encryption key for communication with that AP.

Note PKC is an IEEE 802.11i extension and so is supported in WPA2—not WPA.

Basic Service Set(BSS)

The Basic Service Set is a term used to describe the collection of Stations which may communicate together within an 802.11 WLAN (Wireless Local Area Network).

The BSS may or may not include AP (Access Point) which provide a connection onto a fixed distribution system such as an Ethernet network. Two types of BSS exist; IBSS (Independent Basic Service Set) and Infrastructure Basic Service Set.

EAP-TTLS(Extensible Authentication Protocol-Tunneled Transport Layer Security)

EAP-Tunneled Transport Layer Security, or EAP-TTLS is an EAP protocol that extends TLS. It was co-developed by Funk Software and Certicom. It is widely supported across platforms, although there is no native OS support for this EAP protocol in Microsoft Windows, it requires the installation of small extra programs such as SecureW2.

EAP-TTLS offers very good security. The client does not need be authenticated via a CA-signed PKI certificate to the server, but only the server to the client. This greatly simplifies the setup procedure as a certificate does not need to be installed on every client.

After the server is securely authenticated to the client via its CA certificate, the server can then use the established secure connection ("tunnel") to authenticate the client. It can use an existing and widely deployed authentication protocol and infrastructure, incorporating legacy password mechanisms and authentication databases, while the secure tunnel provides protection from eavesdropping and man-in-the-middle attack. Note that the user's name is never transmitted in unencrypted cleartext, thus improving privacy.

EAP TTLS is described in RFC 5281.

EAP-MD5(Extensible Authentication Protocol-Message Digest 5)

EAP-MD5, defined in RFC 3748, is the only IETF Standards Track based EAP method. It offers minimal security; the MD5 hash function is vulnerable to dictionary attacks, and does not support key generation, which makes it unsuitable for use with dynamic WEP, or WPA/WPA2 enterprise. EAP-MD5 differs from other EAP methods in that it only provides authentication of the EAP peer to the EAP server but not mutual authentication. By not providing EAP server authentication, this EAP method is vulnerable to man-in-the-middle attacks.

EAP-SIM(Extensible Authentication Protocol-Subscriber Identity Module)

Extensible Authentication Protocol Method for GSM Subscriber Identity, or EAP-SIM, is an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). EAP-SIM is described in RFC 4186.

Public Key Infrastructure(PKI)

In cryptography, a public key infrastructure (PKI) is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique for each CA. The binding is established through the registration and issuance process, which, depending on the level of assurance the binding has, may be carried out by software at a CA, or under human supervision. The PKI role that assures this binding is called the Registration Authority (RA) . For each user, the user identity, the public key, their binding, validity conditions and other attributes are made unforgeable in public key certificates issued by the CA.

The term trusted third party (TTP) may also be used for certificate authority (CA). The term PKI is sometimes erroneously used to denote public key algorithms, which do not require the use of a CA.

Protected Access Credentials(PAC)

Protected Access Credentials (PACs) are credentials that are distributed to clients for optimized network authentication. PACs can be used to establish an authentication tunnel between the client and the authentication server (the first phase of authentication as described in the "Two-Phase Tunneled Authentication" section). A PAC consists of, at most, three components: a shared secret, an opaque element, and other information.

The shared secret component contains the pre-shared key between the client and authentication server. Called the PAC-Key, this pre-shared key establishes the tunnel in the first phase of authentication.

The opaque component is provided to the client and is presented to the authentication server when the client wants to obtain access to network resources. Called the PAC-Opaque, this component is a variable length field that is sent to the authentication server during tunnel establishment. The EAP server interprets the PAC-Opaque to obtain the required information to validate the client's identity and authentication. The PAC-Opaque includes the PAC-Key and may contain the PAC's client identity.

The PAC might contain other information. Called PAC-Info, this component is a variable length field that is used to provide, at a minimum, the authority identity of the PAC issuer (the server that created the PAC). Other useful but not mandatory information, such as the PAC-Key lifetime, can also be conveyed by the PAC-issuing server to the client during PAC provisioning or refreshment.

PACs are created and issued by a PAC authority, such as Cisco Secure ACS, and are identified by an ID. A user obtains his or her own copy of a PAC from a server, and the ID links the PAC to a profile.

Persistent PACs, such as machine PACs, are stored in the EAP-FAST registry and encrypted. These PACs are also protected with access control lists (ACLs) so only designated users (the owners of the PACs) and members of privileged user groups (for example, administrators) can access them. Machine PACs are stored globally so that all users of a machine can use the PACs.

All PACs are encrypted and tied to the host machine with Microsoft Crypto API (CryptoProtectData). PACs cannot be copied and used on other machines.

All non-persistent PACs, such as User Authorization PACs, are stored in volatile memory and do not persist after reboot or after a user has logged off.

Cisco Centralized Key Management(CCKM)

CCKM is a term used in wireless networks. It stands for Cisco Centralized Key Management, which is a form of Fast Roaming. When a wireless LAN is configured for fast reconnection, a LEAP enabled client device can roam from one access point to another without involving the main server. Using Cisco (TM) Centralized Key Management (CCKM), an access point configured to provide Wireless Domain Services (WDS) takes the place of the RADIUS server and authenticates the client without perceptible delay in voice or other time-sensitive applications.

Actually, the WDS (which can be run as a service on a Cisco Access Point or on various router modules) caches the user credentials after the initial log-on. The user must authenticate with the Radius server the first time - then he can roam between access points using cached credentials. This saves time in the roaming process, especially valuable for IP Telephones.

The current implementation of CCKM requires Cisco compatible hardware and either LEAP, EAP-Fast (CCXv3) or PEAP-GTC, PEAP-MSCHAP, EAP-TLS (CCXv4).

Dec 10, 2008

Network Access Identifier(NAI) - RFC2486

RFC2486 - The Network Access Identifier

Network Working Group B. Aboba
Request for Comments: 2486 Microsoft
Category: Standards Track M. Beadles
WorldCom Advanced Networks
January 1999

The Network Access Identifier

Status of this Memo

This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

1. Abstract

In order to enhance the interoperability of roaming and tunneling
services, it is desirable to have a standardized method for
identifying users. This document proposes syntax for the Network
Access Identifier (NAI), the userID submitted by the client during
PPP authentication. It is expected that this will be of interest for
support of roaming as well as tunneling. "Roaming capability" may be
loosely defined as the ability to use any one of multiple Internet
service providers (ISPs), while maintaining a formal, customer-vendor
relationship with only one. Examples of where roaming capabilities
might be required include ISP "confederations" and ISP-provided
corporate network access support.

2. Introduction

Considerable interest has arisen recently in a set of features that
fit within the general category of "roaming capability" for dialup
Internet users. Interested parties have included:

Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts
with those of other regional providers to offer dialup service
over a wider area.

National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive
dialup service in a group of countries or on a continent.

Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services
may include Internet access as well as secure access to
corporate intranets via a Virtual Private Network (VPN), enabled
by tunneling protocols such as PPTP, L2F, L2TP, and IPSEC tunnel

In order to enhance the interoperability of roaming and tunneling
services, it is desirable to have a standardized method for
identifying users. This document proposes syntax for the Network
Access Identifier (NAI). Examples of implementations that use the
NAI, and descriptions of its semantics, can be found in [1].

2.1. Terminology

This document frequently uses the following terms:

Network Access Identifier
The Network Access Identifier (NAI) is the userID submitted
by the client during PPP authentication. In roaming, the
purpose of the NAI is to identify the user as well as to
assist in the routing of the authentication request.
Please note that the NAI may not necessarily be the same as
the user's e-mail address or the userID submitted in an
application layer authentication.

Network Access Server
The Network Access Server (NAS) is the device that clients
dial in order to get access to the network. In PPTP
terminology this is referred to as the PPTP Access
Concentrator (PAC), and in L2TP terminology, it is referred
to as the L2TP Access Concentrator (LAC).

Roaming Capability
Roaming capability can be loosely defined as the ability to
use any one of multiple Internet service providers (ISPs),
while maintaining a formal, customer-vendor relationship
with only one. Examples of cases where roaming capability
might be required include ISP "confederations" and ISP-
provided corporate network access support.

Tunneling Service
A tunneling service is any network service enabled by
tunneling protocols such as PPTP, L2F, L2TP, and IPSEC
tunnel mode. One example of a tunneling service is secure
access to corporate intranets via a Virtual Private Network

2.2. Requirements language

In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [9].

2.3. Purpose

As described in [1], there are now a number of services implementing
dialup roaming, and the number of Internet Service Providers involved
in roaming consortia is increasing rapidly.

In order to be able to offer roaming capability, one of the
requirements is to be able to identify the user's home authentication
server. For use in roaming, this function is accomplished via the
Network Access Identifier (NAI) submitted by the user to the NAS in
the initial PPP authentication. It is also expected that NASes will
use the NAI as part of the process of opening a new tunnel, in order
to determine the tunnel endpoint.

2.4. Notes for Implementors

As proposed in this document, the Network Access Identifier is of the
form user@realm. Please note that while the user portion of the NAI
conforms to the BNF described in [5], the BNF of the realm portion
allows the realm to begin with a digit, which is not permitted by the
BNF described in [4]. This change was made to reflect current
practice; although not permitted by the BNF described in [4], FQDNs
such as are commonly used, and accepted by current software.

Please note that NAS vendors may need to modify their devices so as
to support the NAI as described in this document. Devices handling
NAIs MUST support an NAI length of at least 72 octets.

3. Formal definition of the NAI

The grammar for the NAI is given below, described in ABNF as
documented in [7]. The grammar for the username is taken from [5],
and the grammar for the realm is an updated version of [4].

nai = username / ( username "@" realm )

username = dot-string

realm = realm "." label

label = let-dig * (ldh-str)

ldh-str = *( Alpha / Digit / "-" ) let-dig

dot-string = string / ( dot-string "." string )

string = char / ( string char )

char = c / ( "\" x )

let-dig = Alpha / Digit

Alpha = %x41-5A / %x61-7A ; A-Z / a-z

Digit = %x30-39 ;0-9

c = < any one of the 128 ASCII characters, but
not any special or SP >

x = %x00-7F
; all 127 ASCII characters, no exception

SP = %x20 ; Space character

special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."
/ "," / ";" / ":" / "@" / %x22 / Ctl

Ctl = %x00-1F / %x7F
; the control characters (ASCII codes 0 through 31
; inclusive and 127)

Examples of valid Network Access Identifiers include:

Examples of invalid Network Access Identifiers include:


4. References

[1] Aboba, B., Lu J., Alsop J., Ding J. and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997.

[2] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April

[3] Rigney C., "RADIUS Accounting", RFC 2139, April 1997.

[4] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.

[5] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.

[6] Gulbrandsen A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.

[7] Crocker, D. and P. Overrell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[8] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.

[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

5. Security Considerations

Since an NAI reveals the home affiliation of a user, it may assist an
attacker in further probing the username space. Typically this
problem is of most concern in protocols which transmit the user name
in clear-text across the Internet, such as in RADIUS, described in
[2] and [3]. In order to prevent snooping of the user name,
protocols may use confidentiality services provided by IPSEC,
described in [8].

6. IANA Considerations

This document defines a new namespace that will need to be
administered, namely the NAI realm namespace. In order to to avoid
creating any new administrative procedures, administration of the NAI
realm namespace will piggyback on the administration of the DNS

NAI realm names are required to be unique and the rights to use a
given NAI realm for roaming purposes are obtained coincident with
acquiring the rights to use a particular fully qualified domain name
(FQDN). Those wishing to use an NAI realm name should first acquire
the rights to use the corresponding FQDN. Using an NAI realm without
ownership of the corresponding FQDN creates the possibility of
conflict and therefore is to be discouraged.

Note that the use of an FQDN as the realm name does not imply use of
the DNS for location of the authentication server or for
authentication routing. Since to date roaming has been implemented
on a relatively small scale, existing implementations typically
handle location of authentication servers within a domain and perform
authentication routing based on local knowledge expressed in proxy
configuration files. The implementations described in [1] have not
found a need for use of DNS for location of the authentication server
within a domain, although this can be accomplished via use of the DNS
SRV record, described in [6]. Similarly, existing implementations
have not found a need for dynamic routing protocols, or propagation
of global routing information. Note also that there is no
requirement that the NAI represent a valid email address.

7. Acknowledgements

Thanks to Glen Zorn of Microsoft for many useful discussions of
this problem space.

8. Authors' Addresses

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Phone: 425-936-6605

Mark A. Beadles
WorldCom Advanced Networks
5000 Britton Rd.
Hilliard, OH 43026

Phone: 614-723-1941

9. Full Copyright Statement

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an


蔡宜秀 2008/12/09 06:00:00

別於Skype及IPOX 070等網路電話,由國家傳播委員會(NCC)審議通過的070網路電話除有11個號碼(指070-BCDE-FGHI)外,由於070網路電話是走國際電信聯盟(ITU)的E.164通信編碼格式,因此可與同走E.164格式的公眾電信網路(PSTN)互通,如市話等。


但若070網路電話業者欲以有助降低通訊成本一點吸引企業轉使用070網路電話,有其困難性,理由是,企業除得先整合070網路電話與企業內的VoIP PBX等外,還必需進一步向員工宣導與改變其使用習慣等,在這樣的狀況下,建議取得070網路電話執照的業者在祭出各項優惠通話費率之外,如070網路電話使用者可以極低費用撥接行動電話等,亦需要提供更多元的加值服務。


第一,費率競爭將日趨激烈。為吸引企業客戶青睞,遠傳在推出070網路電話之後,即祭出可整合ADSL與MVPN行動服務、免費贈送遠傳070軟體電話,以及享網路閘道器(IP Gateway)免租金、免設定及安裝費等優惠的「遠傳070企業方案」,由這,不難預測,是方通訊等070網路電話業者為弭補晚入070網路電話市場一事,即可能提供更優惠的費資方案,如可與非E.164網路電話互通等。

第二,市場趨勢使然。從美國、日本、南韓、新加坡與香港等地的070網路電話(非每個國家都是以070為網路電話號碼的前綴碼,如下述的Yahoo!BB網路電話的前綴碼即為050)推動狀況來看,加值服務已成為E.164網路電話業者擴大業務範疇的關鍵作法,如日本的第一大網路電話業者Yahoo!BB為擴大事業版圖,繼推出隨選視訊(MOD)─BBTV後,還與微軟及日本電信(Japan Telecom)合作推出整合網路電話、電子郵件(E-mail)與即時通訊(IM)的整合通訊服務(UC)。




舉例來說,雖然有不少業者提出,070網路電話就像是1條SIP Trunk,只要企業的IP交換機(IP PBX)、VoIP Gateway可支援SIP Trunk,即可向業者申請1個070號碼,將該號碼註冊到IP PBX上,即可完成互通與轉接整合......但誰都不曉得,事情是否真如業者所言,不會有任何「萬一」發生。