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.
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
No assignments are final before they occur in this list.
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
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
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.
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.
Experimental / Dynamic Assignments
These may be retracted without notice. They are here for development purposes only.
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.
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.
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.
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-ServiceKeyis a starting point defined to setup in (remotely) hosted services.
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.
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:
ARPA2-Rules-Nameto describe the name of what is being sought
In addition, the following AVPs may also occur:
ARPA2-Selectorto 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.
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.
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
email@example.com 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
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.