https://DevOpsCloud.io -- Cloud Monk Losang Jinpa, Ph.D., MCSE/MCT, GitOps DevOps Engineer

Return to RFC 4949 Internet Security Glossary Definitions, RFC 4949 Internet Security Glossary, RFC 4949 Internet Security Glossary Bibliography, Cybersecurity, Awesome Security

---

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RA

(I) See: registration authority.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RA domains

(I) A feature of a CAW that allows a CA to divide the responsibility for certificate requests among multiple RAs.

Tutorial: This ability might be used to restrict access to private authorization data that is provided with a certificate request, and to distribute the responsibility to review and approve certificate requests in high-volume environments. RA domains might segregate certificate requests according to an attribute of the certificate's subject, such as an organizational unit.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RADIUS

(I) See: Remote Authentication Dial-In User Service.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Rainbow Series

(O) /COMPUSEC/ A set of more than 30 technical and policy documents with colored covers, issued by the NCSC, that discuss in detail the TCSEC and provide guidance for meeting and applying the criteria. (See: Green Book, Orange Book, Red Book, Yellow Book.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• random

(I) In essence, “random” means “unpredictable”. [SP22, Knut, R4086] (See: cryptographic key, pseudorandom.) - “Random sequence”: A sequence in which each successive value is obtained merely by chance and does not depend on the preceding values of the sequence. In a random sequence of bits, each bit is unpredictable; i.e., (a) the probability of each bit being a “0” or “1” is 1/2, and (b) the value of each bit is independent of any other bit in the sequence. - “Random value”: An individual value that is unpredictable; i.e., each value in the total population of possibilities has equal probability of being selected.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• random number generator

(I) A process that is invoked to generate a random sequence of values (usually a sequence of bits) or an individual random value.

Tutorial: There are two basic types of generators. [SP22] - “(True) random number generator”: It uses one or more non- deterministic bit sources (e.g., electrical circuit noise, timing of human processes such as key strokes or mouse movements, semiconductor quantum effects, and other physical

Shirey Informational Page 243]

RFC 4949 Internet Security Glossary, Version 2 August 2007

phenomena) and a processing function that formats the bits, and it outputs a sequence of values that is unpredictable and uniformly distributed. - “Pseudorandom number generator”: It uses a deterministic computational process (usually implemented by software) that has one or more inputs called “seeds”, and it outputs a sequence of values that appears to be random according to specified statistical tests.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RBAC

(N) See: role-based access control, rule-based access control.

Deprecated Usage: IDOCs that use this term SHOULD state a definition for it because the abbreviation is ambiguous.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RC2, RC4, RC6

(N) See: Rivest Cipher

1. 2, #4, #6.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• read

(I) /security model/ A system operation that causes a flow of information from an object to a subject. (See: access mode. Compare: write.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• realm

(I) /Kerberos/ A domain consisting of a set of Kerberized clients, Kerberized application servers, and one or more Kerberos authentication servers and ticket-granting servers that support the clients and applications, all operating under the same security policy. (See: domain.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• recovery

1. (I) /cryptography/ The process of learning or obtaining cryptographic data or plain text through cryptanalysis. (See: key recovery, data recovery.)

2a. (I) /system integrity/ The process of restoring a secure state in a system after there has been an accidental failure or a successful attack. (See: secondary definition under “security”, system integrity.)

2b. (I) /system integrity/ The process of restoring an information system's assets and operation following damage or destruction. (See: contingency plan.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RED

1. (N) Designation for data that consists only of clear text, and for information system equipment items and facilities that handle

Shirey Informational Page 244]

RFC 4949 Internet Security Glossary, Version 2 August 2007

clear text. Example: “RED key”. (See: BCR, color change, RED/BLACK separation. Compare: BLACK.)

Derivation: From the practice of marking equipment with colors to prevent operational errors.

2. (O) /U.S. Government/ Designation applied to information systems, and to associated areas, circuits, components, and equipment, “in which unencrypted national security information is being processed.” [C4009]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RED/BLACK separation

(N) An architectural concept for cryptographic systems that strictly separates the parts of a system that handle plain text (i.e., RED information) from the parts that handle cipher text (i.e., BLACK information). (See: BLACK, RED.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Red Book

(D) /slang/ Synonym for “Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria” [NCS05].

Deprecated Term: IDOCs SHOULD NOT use this term. Instead, use the full proper name of the document or, in subsequent references, a more conventional abbreviation, e.g., TNI-TCSEC. (See: TCSEC, Rainbow Series, Deprecated Usage under “Green Book”.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RED key

(N) A cleartext key, which is usable in its present form (i.e., it does not need to be decrypted before being used). (See: RED. Compare: BLACK key.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• reference monitor

(I) “An access control concept that refers to an abstract machine that mediates all accesses to objects by subjects.” [NCS04] (See: security kernel.)

Tutorial: This concept was described in the Anderson report. A reference monitor should be (a) complete (i.e., it mediates every access), (b) isolated (i.e., it cannot be modified by other system entities), and © verifiable (i.e., small enough to be subjected to analysis and tests to ensure that it is correct).

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• reflection attack

(I) An attack in which a valid data transmission is replayed to the originator by an attacker who intercepts the original transmission. (Compare: indirect attack, replay attack.)

Shirey Informational Page 245]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• reflector attack

(D) Synonym for “indirect attack”.

Deprecated Term: IDOCs SHOULD NOT use this term; it could be confused with “reflection attack”, which is a different concept.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• registered user

(I) A system entity that is authorized to receive a system's products and services or otherwise access system resources. (See: registration, user.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• registration

1. (I) /information system/ A system process that (a) initializes an id[[entity (of a system entity) in the system, (b) establishes an identifier for that id[[entity, © may associate authentication information with that identifier, and (d) may issue an identifier credential (depending on the type of authentication mechanism being used). (See: authentication information, credential, identifier, id[[entity, id[[entity proofing.)

2. (I) /PKI/ An administrative act or process whereby an entity's name and other attributes are established for the first time at a CA, prior to the CA issuing a digital certificate that has the entity's name as the subject. (See: registration authority.)

Tutorial: Registration may be accomplished either directly, by the CA, or indirectly, by a separate RA. An entity is presented to the CA or RA, and the authority either records the name(s) claimed for the entity or assigns the entity's name(s). The authority also determines and records other attributes of the entity that are to be bound in a certificate (such as a public key or authorizations) or maintained in the authority's database (such as street address and telephone number). The authority is responsible, possibly assisted by an RA, for verifying the entity's id[[entity and vetting the other attributes, in accordance with the CA's CPS.

Among the registration issues that a CPS may address are the following [R3647]: - How a claimed id[[entity and other attributes are verified. - How organization affiliation or representation is verified. - What forms of names are permitted, such as X.500 DN, domain name, or IP address. - Whether names are required to be meaningful or unique, and within what domain. - How naming disputes are resolved, including the role of trademarks. - Whether certificates are issued to entities that are not persons.

Shirey Informational Page 246]

RFC 4949 Internet Security Glossary, Version 2 August 2007

- Whether a person is required to appear before the CA or RA, or can instead be represented by an agent. - Whether and how an entity proves possession of the private key matching a public key.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• registration authority (RA)

1. (I) An optional PKI entity (separate from the CAs) that does not sign either digital certificates or CRLs but has responsibility for recording or verifying some or all of the information (particularly the identities of subjects) needed by a CA to issue certificates and CRLs and to perform other certificate management functions. (See: ORA, registration.)

2. (I) /PKIX/ An optional PKI component, separate from the CA(s). The functions that the RA performs will vary from case to case but may include id[[entity authentication and name assignment, key generation and archiving of key pairs, token distribution, and revocation reporting. [R4210]

Tutorial: Sometimes, a CA may perform all certificate management functions for all end users for which the CA signs certificates. Other times, such as in a large or geographically dispersed community, it may be necessary or desirable to offload secondary CA functions and delegate them to an assistant, while the CA retains the primary functions (signing certificates and CRLs). The tasks that are delegated to an RA by a CA may include personal authentication, name assignment, token distribution, revocation reporting, key generation, and archiving.

An RA is an optional PKI entity, separate from the CA, that is assigned secondary functions. The duties assigned to RAs vary from case to case but may include the following: - Verifying a subject's id[[entity, i.e., performing personal authentication functions. - Assigning a name to a subject. (See: distinguished name.) - Verifying that a subject is entitled to have the attributes requested for a certificate. - Verifying that a subject possesses the private key that matches the public key requested for a certificate. - Performing functions beyond mere registration, such as generating key pairs, distributing tokens, handling revocation reports, and archiving data. (Such functions may be assigned to a PKI component that is separate from both the CA and the RA.)

3. (O) /SET/ “An independent third-party organization that processes payment card applications for multiple payment card brands and forwards applications to the appropriate financial institutions.” [SET2]

Shirey Informational Page 247]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• regrade

(I) Deliberately change the security level (especially the hierarchical classification level) of information in an authorized manner. (See: downgrade, upgrade.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• rekey

(I) Change the value of a cryptographic key that is being used in an application of a cryptographic system. (See: certificate rekey.)

Tutorial: Rekey is required at the end of a cryptoperiod or key lifetime.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• reliability

(I) The ability of a system to perform a required function under stated conditions for a specified period of time. (Compare: availability, survivability.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• reliable human review

(I) Any manual, automated, or hybrid process or procedure that ensures that a human examines a digital object, such as text or an image, to determine whether the object may be permitted, according to some security policy, to be transferred across a controlled interface. (See: guard.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• relying party

(I) Synonym for “certificate user”.

Usage: Used in a legal context to mean a recipient of a certificate who acts in reliance on that certificate. (See: ABA Guidelines.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• remanence

(I) Residual information that can be recovered from a storage medium after clearing. (See: clear, magnetic remanence, purge.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Remote Authentication Dial-In User Service (RADIUS)

(I) An Internet protocol [R2865] for carrying dial-in users' authentication information and configuration information between a shared, centralized authentication server (the RADIUS server) and a network access server (the RADIUS client) that needs to authenticate the users of its network access ports. (See: TACACS.)

User presents authentication and possibly other information to the RADIUS client (e.g., health information regarding the user device).

Shirey Informational Page 248]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: A user presents authentication information and possibly other information to the RADIUS client, and the client passes that information to the RADIUS server. The server authenticates the client using a shared secret value and checks the presented information, and then returns to the client all authorization and configuration information needed by the client to serve the user.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• renew

See: certificate renewal.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• reordering

(I) /packet/ See: secondary definition under “stream integrity service”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• replay attack

(I) An attack in which a valid data transmission is maliciously or fraudulently repeated, either by the originator or by a third party who intercepts the data and retransmits it, possibly as part of a masquerade attack. (See: active wiretapping, fresh, liveness, nonce. Compare: indirect attack, reflection attack.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• repository

1. (I) A system for storing and distributing digital certificates and related information (including CRLs, CPSs, and certificate policies) to certificate users. (Compare: archive, directory.)

2. (O) “A trustworthy system for storing and retrieving certificates or other information relevant to certificates.” [DSG]

Tutorial: A certificate is published to those who might need it by putting it in a repository. The repository usually is a publicly accessible, on-line server. In the FPKI, for example, the expected repository is a directory that uses LDAP, but also may be an X.500 Directory that uses DAP, or an HTTP server, or an FTP server that permits anonymous login.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• repudiation

1. (I) Denial by a system entity that was involved in an association (especially a communication association that transfers data) of having participated in the relationship. (See: accountability, non-repudiation service.)

2. (I) A type of threat action whereby an entity deceives another by falsely denying responsibility for an act. (See: deception.)

Shirey Informational Page 249]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Usage: This type of threat action includes the following subtypes: - False denial of origin: Action whereby an originator denies responsibility for sending data. - False denial of receipt: Action whereby a recipient denies receiving and possessing data.

3. (O) /OSIRM/ “Denial by one of the entities involved in a communication of having participated in all or part of the communication.” [I7498-2]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Request for Comment (RFC)

1. (I) One of the documents in the archival series that is the official channel for IDOCs and other publications of the Internet Engineering Steering Group, the Internet Architecture Board, and the Internet community in general. (RFC 2026, 2223) (See: Internet Standard.)

2. (D) A popularly misused synonym for a document on the Internet Standards Track, i.e., an Internet Standard, Draft Standard, or Proposed Standard. (See: Internet Standard.)

Deprecated Definition: IDOCs SHOULD NOT use this term with definition 2 because many other types of documents also are published as RFCs.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• residual risk

(I) The portion of an original risk or set of risks that remains after countermeasures have been applied. (Compare: acceptable risk, risk analysis.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• restore

See: card restore.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• reverse engineering

(I) /threat action/ See: secondary definition under “intrusion”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• revocation

See: certificate revocation.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• revocation date

(N) /X.509/ In a CRL entry, a date-time field that states when the certificate revocation occurred, i.e., when the CA declared the digital certificate to be invalid. (See: invalidity date.)

Tutorial: The revocation date may not resolve some disputes because, in the worst case, all signatures made during the validity period of the certificate may have to be considered invalid. However, it may be desirable to treat a digital signature

Shirey Informational Page 250]

RFC 4949 Internet Security Glossary, Version 2 August 2007

as valid even though the private key used to sign was compromised after the signing. If more is known about when the compromise actually occurred, a second date-time, an “invalidity date”, can be included in an extension of the CRL entry.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• revocation list

See: certificate revocation list.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• revoke

(I) See: certificate revocation.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RFC

(I) See: Request for Comment.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Rijndael

(N) A symmetric, block cipher that was designed by Joan Daemen and Vincent Rijmen as a candidate for the AES, and that won that competition. [Daem] (See: Advanced Encryption Standard.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• risk

1. (I) An expectation of loss expressed as the probability that a particular threat will exploit a particular vulnerability with a particular harmful result. (See: residual risk.)

2. (O) /SET/ “The possibility of loss because of one or more threats to information (not to be confused with financial or business risk).” [SET2]

Tutorial: There are four basic ways to deal with a risk [SP30]: - “Risk avoidance”: Eliminate the risk by either countering the threat or removing the vulnerability. (Compare: “avoidance” under “security”.) - “Risk transference”: Shift the risk to another system or entity; e.g., buy insurance to compensate for potential loss. - “Risk limitation”: Limit the risk by implementing controls that minimize resulting loss. - “Risk assumption”: Accept the potential for loss and continue operating the system.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• risk analysis

(I) An assessment process that systematically (a) identifies valuable system resources and threats to those resources, (b) quantifies loss exposures (i.e., loss potential) based on estimated frequencies and costs of occurrence, and © (optionally) recommends how to allocate available resources to countermeasures so as to minimize total exposure. (See: risk management, business-case analysis. Compare: threat analysis.)

Shirey Informational Page 251]

RFC 4949 Internet Security Glossary, Version 2 August 2007

Tutorial: Usually, it is financially and technically infeasible to avoid or transfer all risks (see: “first corollary” of “second law” under “Courtney's laws”), and some residual risks will remain, even after all available countermeasures have been deployed (see: “second corollary” of “second law” under “Courtney's laws”). Thus, a risk analysis typically lists risks in order of cost and criticality, thereby determining where countermeasures should be applied first. [FP031, R2196]

In some contexts, it is infeasible or inadvisable to attempt a complete or quantitative risk analysis because needed data, time, and expertise are not available. Instead, basic answers to questions about threats and risks may be already built into institutional security policies. For example, U.S. DoD policies for data confidentiality “do not explicitly itemize the range of expected threats” but instead “reflect an operational approach … by stating the particular management controls that must be used to achieve [confidentiality] … Thus, they avoid listing threats, which would represent a severe risk in itself, and avoid the risk of poor security design implicit in taking a fresh approach to each new problem”. [NRC91]

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• risk assumption

(I) See: secondary definition under “risk”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• risk avoidance

(I) See: secondary definition under “risk”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• risk limitation

(I) See: secondary definition under “risk”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• risk management

1. (I) The process of identifying, measuring, and controlling (i.e., mitigating) risks in information systems so as to reduce the risks to a level commensurate with the value of the assets protected. (See: risk analysis.)

2. (I) The process of controlling uncertain events that may affect information system resources.

3. (O) “The total process of identifying, controlling, and mitigating information system-related risks. It includes risk assessment; cost-benefit analysis; and the selection, implementation, test, and security evaluation of safeguards. This overall system security review considers both effectiveness and efficiency, including impact on the mission and constraints due to policy, regulations, and laws.” [SP30]

Shirey Informational Page 252]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• risk transference

(I) See: secondary definition under “risk”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Rivest Cipher #2 (RC2)

(N) A proprietary, variable-key-length block cipher invented by Ron Rivest for RSA Data Security, Inc.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Rivest Cipher #4 (RC4)

(N) A proprietary, variable-key-length stream cipher invented by Ron Rivest for RSA Data Security, Inc.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Rivest Cipher #6 (RC6)

(N) A symmetric, block cipher with 128-bit or longer key length, developed by Ron Rivest for RSA Data Security, Inc. as a candidate for the AES.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• Rivest-Shamir-Adleman (RSA)

(N) An algorithm for asymmetric cryptography, invented in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman [RSA78].

Tutorial: RSA uses exponentiation modulo the product of two large prime numbers. The difficulty of breaking RSA is believed to be equivalent to the difficulty of factoring integers that are the product of two large prime numbers of approximately equal size.

To create an RSA key pair, randomly choose two large prime numbers, p and q, and compute the modulus, n = pq. Randomly choose a number e, the public exponent, that is less than n and relatively prime to (p-1)(q-1). Choose another number d, the private exponent, such that ed-1 evenly divides (p-1)(q-1). The public key is the set of numbers (n,e), and the private key is the set (n,d).

It is assumed to be difficult to compute the private key (n,d) from the public key (n,e). However, if n can be factored into p and q, then the private key d can be computed easily. Thus, RSA security depends on the assumption that it is computationally difficult to factor a number that is the product of two large prime numbers. (Of course, p and q are treated as part of the private key, or else are destroyed after computing n.)

For encryption of a message, m, to be sent to Bob, Alice uses Bob's public key (n,e) to compute m**e (mod n) = c. She sends c to Bob. Bob computes c**d (mod n) = m. Only Bob knows d, so only Bob can compute c**d (mod n) to recover m.

To provide data origin authentication of a message, m, to be sent to Bob, Alice computes m**d (mod n) = s, where (d,n) is Alice's

Shirey Informational Page 253]

RFC 4949 Internet Security Glossary, Version 2 August 2007

private key. She sends m and s to Bob. To recover the message that only Alice could have sent, Bob computes s**e (mod n) = m, where (e,n) is Alice's public key.

To ensure data integrity in addition to data origin authentication requires extra computation steps in which Alice and Bob use a cryptographic hash function h (see: digital signature). Alice computes the hash value h(m) = v, and then encrypts v with her private key to get s. She sends m and s. Bob receives m' and s', either of which might have been changed from the m and s that Alice sent. To test this, he decrypts s' with Alice's public key to get v'. He then computes h(m') = v“. If v' equals v”, Bob is assured that m' is the same m that Alice sent.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• robustness

(N) See: level of robustness.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• role

1. (I) A job function or employment position to which people or other system entities may be assigned in a system. (See: role- based access control. Compare: duty, billet, principal, user.)

2. (O) /Common Criteria/ A pre-defined set of rules establishing the allowed interactions between a user and the TOE.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• role-based access control

(I) A form of id[[entity-based access control wherein the system entities that are identified and controlled are functional positions in an organization or process. [Sand] (See: authorization, constraint, id[[entity, principal, role.)

Tutorial: Administrators assign permissions to roles as needed to perform functions in the system. Administrators separately assign user identities to roles. When a user accesses the system in an id[[entity (for which the user has been registered) and initiates a session using a role (to which the user has been assigned), then the permissions that have been assigned to the role are available to be exercised by the user.

The following diagram shows that role-based access control involves five different relationships: (a) administrators assign identities to roles, (b) administrators assign permissions to roles, © administrators assign roles to roles, (d) users select identities in sessions, and (e) users select roles in sessions. Security policies may define constraints on these assignments and selections.

Shirey Informational Page 254]

RFC 4949 Internet Security Glossary, Version 2 August 2007

© Permission Inheritance Assignments (i.e., Role Hierarchy)

[[Constraint]]s]
+=====+
]] | [[  ]] | [[
(a) [[Id[[entity]]v  v  (b) Per[[mission]]

+———-+ Assignments +——-+ Assignments +———-+ ]] | Id[[entities]] | <=============> | [[Roles ]] | <=============> | Per[[missions]] | +----------+ [[Constraints] +——-+ Constraints] +———-+

 ]] | [[]] | [[ ^^
 ]] | [[]] | [[+-----------+]] | [[]] | [[ +---------------------+
 ]] | [[]] | [[]] | [[ +-------+ ]] | [[]] | [[]] | [[ ]] | [[ Legend  ]] | [[
 ]] | [[+====>]] | [[[[Session]]]] | [[=====+]] | [[ ]] | [[]] | [[
 ]] | [[ ]] | [[ +-------+ ]] | [[ ]] | [[ ]] | [[  One-to-One]] | [[
 ]] | [[ ]] | [[ ...]] | [[ ]] | [[ ]] | [[ =================== ]] | [[
 ]] | [[ ]] | [[ +-------+ ]] | [[ ]] | [[ ]] | [[]] | [[
 +========>]] | [[[[Session]]]] | [[=========+ ]] | [[  One-to-Many  ]] | [[

(d) Id[[entity ]] | +-------+ | (e) [[Role ]] | ==================> | [[Selections ]] | rfc_4949_internet_security_glossary_definitions_r | [[Selections ]] | rfc_4949_internet_security_glossary_definitions_r | [[Constraints]]] | [[Access]] | [[Constraints] ]] | Many-to-Many | rfc_4949_internet_security_glossary_definitions_r | [[Sessions ]] | rfc_4949_internet_security_glossary_definitions_r | <=================> | +-----------++---------------------+ ([[Fair Use Source: RFC 4949]) ---- * [[role certificate (I) An organizational certificate that is issued to a system entity that is a member of the set of users that have identities that are assigned to the same role. (See: role-based access control.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• root, root CA

1. (I) /PKI/ A CA that is directly trusted by an end entity. (See: trust anchor, trusted CA.)

2. (I) /hierarchical PKI/ The CA that is the highest level (most trusted) CA in a certification hierarchy; i.e., the authority upon whose public key all certificate users base their validation of certificates, CRLs, certification paths, and other constructs. (See: top CA.)

Tutorial: The root CA in a certification hierarchy issues public- key certificates to one or more additional CAs that form the second-highest level. Each of these CAs may issue certificates to more CAs at the third-highest level, and so on. To initialize operation of a hierarchical PKI, the root's initial public key is securely distributed to all certificate users in a way that does not depend on the PKI's certification relationships, i.e., by an out-of-band procedure. The root's public key may be distributed simply as a numerical value, but typically is distributed in a self-signed certificate in which the root is the subject. The

Shirey Informational Page 255]

RFC 4949 Internet Security Glossary, Version 2 August 2007

root's certificate is signed by the root itself because there is no higher authority in a certification hierarchy. The root's certificate is then the first certificate in every certification path.

3. (I) /DNS/ The base of the tree structure that defines the name space for the Internet DNS. (See: domain name.)

4. (O) /MISSI/ A name previously used for a MISSI policy creation authority, which is not a root as defined above for general usage, but is a CA at the second level of the MISSI hierarchy, immediately subordinate to a MISSI policy approving authority.

5. (O) /UNIX/ A user account (a.k.a. “superuser”) that has all privileges (including all security-related privileges) and thus can manage the system and its other user accounts.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• root certificate

1. (I) /PKI/ A certificate for which the subject is a root. (See: trust anchor certificate, trusted certificate.)

2. (I) /hierarchical PKI/ The self-signed public-key certificate at the top of a certification hierarchy.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• root key

(I) /PKI/ A public key for which the matching private key is held by a root. (See: trust anchor key, trusted key.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• root registry

(O) /MISSI/ A name previously used for a MISSI PAA.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• ROT13

(I) See: secondary definition under “Caesar cipher”.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• router

1a. (I) /IP/ A networked computer that forwards IP packets that are not addressed to the computer itself. (Compare: host.)

1b. (I) /IPS/ A gateway that operates in the IPS Internet Layer to connect two or more subnetworks.

1c. (N) /OSIRM/ A computer that is a gateway between two networks at OSIRM Layer 3 and that relays and directs data packets through that internetwork. (Compare: bridge, proxy.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• RSA

(N) See: Rivest-Shamir-Adleman.

Shirey Informational Page 256]

RFC 4949 Internet Security Glossary, Version 2 August 2007

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• rule

See: policy rule.

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• rule-based security policy

(I) “A security policy based on global rules [i.e., policy rules] imposed for all users. These rules usually rely on comparison of the sensitivity of the resource being accessed and the possession of corresponding attributes of users, a group of users, or entities acting on behalf of users.” [I7498-2] (Compare: id[[entity- based security policy, policy rule, RBAC.)

([[Fair Use]] [[Source]]: [[RFC 4949])

---

• rules of behavior

(I) A body of security policy that has been established and implemented concerning the responsibilities and expected behavior of entities that have access to a system. (Compare: [R1281].)

Tutorial: For persons employed by a corporation or government, the rules might cover such matters as working at home, remote access, use of the Internet, use of copyrighted works, use of system resources for unofficial purpose, assignment and limitation of system privileges, and individual accountability.

---

Fair Use Sources:

• RFC 4949 Internet Security Glossary