This is the AVP namespace for the ARPA2 / InternetWide project.

AVPs are tags used with Diameter. We can allocate tags under the Private Enterprise Numbers 44469 for ARPA2, or possibly 10471 for OpenFortress. Other Vendor-Ids may occur here, but are strictly references to other places.

When allocations are implemented by multiple vendors, the suggestion in the Diameter Base Protocol is to send for Expert Review to obtain a global allocation.

Range Assignments

These are free ranges from which AVP Codes for ARPA2 are usually allocated:

  • 0-255 reserved, see below
  • 256-511 for the Network Access application (AA-Request, AA-Answer) (free: 257-511)
  • 512-16659999 may be allocated in blocks for other applications (free: 512-16659999)
  • 16660000-16777215 are allocated experimentally and dynamically (free: 1666030-16777215)

Reserved ranges of AVP Codes:

Name:         N/A
VendorIds:    44469 (ARPA2) and 10471 (OpenFortress)
AVP Code:     0
Purpose:      Not to be used
Application:  All
Messages:     None
Datatype:     N/A
Reference:    RFC 6733

Name:        N/A
VendorIds:   44469 (ARPA2) and 10471 (OpenFortress)
AVP Codes:   1-255
Purpose:     Reserved for RADIUS
Application: All
Messages:    RADIUS-compatibility messages
Datatype:    N/A
Reference:   RFC 6733

Name:        N/A
VendorIds:   44469 (ARPA2)
AVP Codes:   16660000-16660009  (assigned up to 166600002)
Purpose:     Experimental/Dynamic Assignment for SASL
Application: NAS
Messages:    SASL carried into Diameter
Datatype:    N/A
Reference:   see below

Name:        N/A
VendorIds:   44469 (ARPA2)
AVP Codes:   16660010-16660029 (assigned up to 166600014)
Purpose:     Experimental/Dynamic Assignment for remote access to an ARPA2 Rules DB
Application: NAS
Messages:    Rules DB interactions, such as Access Control and Groups
Datatype:    N/A
Reference:   see below

Individual Assignments

No assignments are final before they occur in this list.

ARPA2-AA-Alternative

Name:        ARPA2-AA-Alternative
VendorId:    44469 (ARPA2)
AVP Code:    256
Purpose:     Grouped AVPs for Alternative Network Access
Application: Network Access
Messages:    AAR (AA-Request), AAA (AA-Answer)
Datatype:    Grouped
Reference:   see below, RFC 4005

The purpose of this allocation is to group AVPs that form an alternative in the authentication and/or authorisation expressed by Diameter in the Network Access application.

When used in an AA-Request message, it expresses the desire to try a number of alternatives. This facility may not be suited for public use on the Internet, as it is supportive of attacks.

When used in an AA-Answer message, it expresses that multiple combinations were acceptable to the server.

In general, the AVPs inside one ARPA2-AA-Alternative group should be considered to belong together, on top of AVPs that are not contained in an ARPA2-AA-Alternative group. Multiple ARPA2-AA-Alternative groups however, are not combined; each delivers a set of AVPs for an alternative in the AA-Request of AA-Answer.

The AVPs contained in an ARPA2-AA-Alternative group are constrained to those that can be used in the Network Access application and that need not occur in direct proximity of the Diameter header, and that have no impact on routing or proxying.

An ARPA2-AA-Alternative group may only occur in the top level of an AA-Request or AA-Response message, so in the set of AVPs that follows the Diameter header. There is no required minimum number of ARPA2-AA-Alternative groups, zero or one are as acceptable as two or more.

ARPA2-AA-Known-User-Name

Under consideration.

ARPA2-AA-Contacted-User

Under consideration.

ARPA2-AA-Resource

Under consideration.

ARPA2-AA-Resource-Instance

Under consideration.

ARPA2-AA-Communication-Rights

Under consideration.

ARPA2-AA-Resource-Rights

Under consideration.

ARPA2-AA-Resource-Instance-Rights

Under consideration.

ARPA2-AA-SASL

Under consideration.

Experimental / Dynamic Assignments

These may be retracted without notice. They are here for development purposes only.

SASL-Mechanism

Name:        SASL-Mechanism
VendorId:    44469 (ARPA2)
AVP Code:    16660000
Purpose:     Embedding SASL in Diameter
Application: Network Access
Messages:    AAR (AA-Request), AAA (AA-Answer)
Datatype:    UTF8String
Reference:   see below, draft-vanrein-diameter-sasl

The SASL-Mechanism AVP has AVP Code TBD0. This specification only uses the mechanism name GS2-SXOVER-PLUS as a value for this AVP. It MUST be included in the first message of an GS2-SXOVER-PLUS exchange sent to the home realm, and it SHOULD be verified by the home realm upon reception. Its purpose is mostly to distinguish this specification from potential future specifications to encapsulate SASL in Diameter.

Though not used in this specification, this AVP may also be supplied from the home realm to the Diameter client to hold a space-separated list of SASL mechanisms.

SASL-Token

Name:        SASL-Token
VendorId:    44469 (ARPA2)
AVP Code:    16660001
Purpose:     Embedding SASL in Diameter
Application: Network Access
Messages:    AAR (AA-Request), AAA (AA-Answer)
Datatype:    OctetString
Reference:   see below, draft-vanrein-diameter-sasl

The SASL-Token AVP has AVP Code TBD1. SASL requires distinction between empty and absent tokens; absent SASL tokens are represented by absence of the SASL-Token AVP and empty SASL tokens are represented as a present SASL-Token AVP with zero content bytes.

SASL-Channel-Binding

Name:        SASL-Channel-Binding
VendorId:    44469 (ARPA2)
AVP Code:    16660002
Purpose:     Embedding SASL in Diameter
Application: Network Access
Messages:    AAR (AA-Request)
Datatype:    OctetString
Reference:   see below, draft-vanrein-diameter-sasl

The SASL-Channel-Binding AVP has AVP Code TBD2. It MUST appear along the first SASL-Token AVP for a Network Access session if the SASL- Mechanism ends in -PLUS.

This AVP may occur more than once, to indicate support of multiple forms of channel binding. Note however that all mechanisms suitable for Diameter relaying use the GS2 bridge [RFC5056] in which case the channel binding name to pass along in this message can be derived.

When the client connects to the foreign service over TLS, the tls- unique form [RFC5929] of channel binding is RECOMMENDED. Specific foreign servers may however be exempted by the home realm.

The contents of this AVP concatenates two values:

name is the standard name of the channel binding information, followed by a zero-valued byte.

value contains the bytes of the channel binding information.

Normally, channel binding information should be sourced from the underlying communications channel, but this information is not available to a SASL backend running Diameter. To enable channel binding between the end points, the foreign server incorporates the channel binding information that the client can use in its connection to the foreign server. This is useful to mitigate replay attacks, which is why its use is RECOMMENDED.

ARPA2-Rules

Name:        ARPA2-Rules
VendorId:    44469 (ARPA2)
AVP Code:    16660010
Purpose:     Holding together a related set of ARPA2 Access Control AVPs
Application: Network Access
Messages:    AAR (AA-Request), AAA (AA-Answer)
Datatype:    Grouped
Reference:   see below

This AVP holds a set of the following ARPA2-AccessControl-XXX AVPs to indicate they belong together. One AAR or AAA may hold more than one of these sets, and each are dealt with independently.

The occurrence of this set in an AA-Request is a request to respond to it in an AA-Answer, but not a strict requirement. Negligence to send such as response MUST NOT be interpreted as approval of the attempted form of access.

Every ARPA2-Rules group must contain precisely one entry point into the access tree of the Rules DB. These may give rise to extra required or optional fields. Currently defined starting points for use with Diameter are:

  • ARPA2-Rules-ServiceKey is a starting point defined to setup in (remotely) hosted services.

ARPA2-Rules-Answer

Name:        ARPA2-Rules-Answer
VendorId:    44469 (ARPA2)
AVP Code:    16660011
Purpose:     Holding together a related set of ARPA2 Access Control AVPs
Application: Network Access
Messages:    AAA (AA-Answer)
Datatype:    OctetString
Reference:   see below

This AVP reports the Ruleset in its binary form as used on the ARPA2 Common API; that is, as a sequence of ASCII strings with each a NUL terminator character. The purpose of passing this literal form is to enable processing with the ARPA2 Common library as a plain and simple ruleset in the place where it is needed.

This AVP may hold 0 bytes to indicate that it found no usable Ruleset. Note that this differs from a set with an empty line, which would at least hold a NUL character. No assumptions should be made about such absense of a Ruleset, other than what a RulesDB application makes of it.

The Ruleset in this AVP is not encrypted. Contexts may exist that require better protection of sensitive data, which may be a reason for later introduction of another kind of AVP.

ARPA2-Rules-ServiceKey

Name:        ARPA2-Rules-ServiceKey
VendorId:    44469 (ARPA2)
AVP Code:    16660012
Purpose:     Defining the access point to the Rules DB access hierarchy
Application: Network Access
Messages:    AAR (AA-Request), AAA (AA-Answer)
Datatype:    OctetString
Reference:   see below

This AVP holds the binary form of the Service Key. This serves as the entrance point into a subtree of the Rules DB access hierarchy, intended for use by (remote) services who need to learn about such things as Access Rights.

Service Keys are often communicated on commandlines and in configfiles in their hexadecimal form, but they must be mapped to binary form for this AVP.

There may be several mechanisms to get a starting point into Rulesets, of which this is just one. Every ARPA2-Rules group must contain precisely one of these.

When this AVP is included in an ARPA2-Rules group, then the following AVPs are obliged to occur in the same group:

  • One ARPA2-Rules-Name to describe the name of what is being sought

In addition, the following AVPs may also occur:

  • ARPA2-Selector to describe the ARPA2 Identity or ARPA2 Selector triggering the Rules DB lookup. It may be dropped when the group is sent while starting an authentication exchange that will yield a Remote Identity to use in place of this field.

ARPA2-Rules-Name

Name:        ARPA2-Rules-Name
VendorId:    44469 (ARPA2)
AVP Code:    16660013
Purpose:     Naming the Rules DB entry to retrieve
Application: Network Access
Messages:    AAR (AA-Request), AAA (AA-Answer)
Datatype:    UTF8String
Reference:   see below

This AVP holds the Rules Name that adheres to a grammar that is accurately defined by the Rules Type. Note that a Rules Type is not necessarily communicated, but that is may also be implied by other AVPs, such as the ARPA2-Rules-ServiceKey. The same holds for the domain being serviced.

The form of this AVP is an UTF8 String. This means that it must not contain NUL characters or other non-UTF8 byte sequences. The API for APRA2 Common defines a NUL-terminated string, but the trailing NUL is replaced by the length fields when sent over Diameter.

Examples of Rules Names are /248e0e23-d2ed-4d20-84d3-8a2ab781f420 for a Collection in Reservoir, and john to locate something particular to that user.

ARPA2-Rules-Selector

Name:        ARPA2-Rules-Selector
VendorId:    44469 (ARPA2)
AVP Code:    16660014
Purpose:     Selecting the (Remote) Identity that causes the lookup
Application: Network Access
Messages:    AAR (AA-Request), AAA (AA-Answer)
Datatype:    UTF8String
Reference:   see below

This AVP is optional when the same Diameter message starts an authentication attempt. In this case, the ARPA2-Rules group is saved for processing along with a successful result of the authentication, and a value like this AVP will be derived from the authentication outcome, which must than be written in a general user@domain.name form, to be parsed as a Remote Identity.

Some Service Keys belong to a Rules Type that does not require a selector, but set it to a default value, usually @. which must then be supplied explicitly in this field. The intention of this field being optional is not to know and substitute such values that are specific to a Rules Type.

The value of this AVP is, generally taken, an ARPA2 Selector. This includes ARPA2 Identity and even Remote Identity forms (with less stylised local parts). Only the textual representation is passed. Forms that do not match either of these syntax forms cause the rejection of an entire ARPA2-Rules request.

NAS-Port-Type value "SASL-Authenticated Protocol"

This is a value to register in IANA's NAS-Port-Type value registry,

Note: This is quite a difficult procedure, and we may not choose to undertake it, and work our way around it.

Name:        NAS-Port-Type
Value:       SASL-Authenticated-Protocol(TBD)
Purpose:     Relaying SASL protocol interactions to Authentication Backends
Application: Network Access
Reference:   see below, draft-vanrein-diameter-sasl

The requested code value is intended to specify the following meanings for the NAS-Port or NAS-Port-Id when they are used to relay SASL protocol interactions to authentication backends. SASL may request the use of a service name, which is relayed in the NAS-Port or NAS-Port-Id field when NAS-Port-Type is set to SASL-Authenticated-Protocol(TBD).

Such relaying may happen in two different scenarios. First, it may be used internally to concentrate SASL protocol interactions into a single internal identity provider, without the need to store credentials in front-end servers. Second, such an identity provider may be hosted under a domain of the client's choosing, in which case we speak of Realm Crossover and require suitable security arrangements to be made, but other than that, the SASL interaction may be forwarded.

Name:        NAS-Port for NAS-Port-Type SASL-Authenticated-Protocol(TBD)
Purpose:     Relaying SASL protocol interactions to Authentication Backends
Application: Network Access
Reference:   see below, draft-vanrein-diameter-sasl

The NAS-Port represents a string such as SASL can use it as a service name. This is used, for instance, in the construction of Kerberos Tickets in a part preceding the service host, as "imap" in the Ticket's service name "imap/mail.example.com@EXAMPLE.COM".

This NAS-Port definition is general, and although it distinguishes the front-end service, it does not do so in a unique manner because it follows SASL naming traditions. Unique references must be explicitly setup between the service front-end and authentication backend, and will lead to a numeric trunk code being used as NAS-Port-Id.

Name:        NAS-Port-Id for NAS-Port-Type SASL-Authenticated-Protocol(TBD)
Purpose:     Relaying SASL protocol interactions to Authentication Backends
Application: Network Access
Reference:   see below, draft-vanrein-diameter-sasl

The NAS-Port-Id represents a trunk code between a service front end and an authenticating backend. Such a code can be used to distinguish the front end from the perspective of the authentication backend.

The service string, such as "imap" in the above, would be implicated by the used NAS-Port-Id; different service strings may require different NAS-Port-Id values or SASL mechanisms relying on them may be held back.