--- 1/draft-ietf-radext-dynamic-discovery-08.txt 2013-12-20 00:14:31.704417614 -0800 +++ 2/draft-ietf-radext-dynamic-discovery-09.txt 2013-12-20 00:14:31.756418973 -0800 @@ -1,19 +1,19 @@ RADIUS Extensions Working Group S. Winter Internet-Draft RESTENA Intended status: Experimental M. McCauley -Expires: April 19, 2014 OSC - October 16, 2013 +Expires: June 23, 2014 OSC + December 20, 2013 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS - draft-ietf-radext-dynamic-discovery-08 + draft-ietf-radext-dynamic-discovery-09 Abstract This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 19, 2014. + This Internet-Draft will expire on June 23, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -46,41 +46,43 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 3 - 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.1.3. Remarks . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 8 2.2. Definition of the X.509 certificate property SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 10 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 11 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 - 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 11 + 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 12 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 12 - 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 13 - 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 13 + 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 13 + 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 14 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 15 - 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 16 - 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 16 + 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 17 + 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 7. Normative References . . . . . . . . . . . . . . . . . . . . 22 - Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 23 + 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 7.2. Informative References . . . . . . . . . . . . . . . . . 24 + Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 24 1. Introduction RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers (clients, servers). Where RADIUS forwarding servers are in use, the number of realms to be forwarded and the corresponding number of servers to configure may be significant. Where new realms with new servers are added or @@ -197,39 +199,42 @@ Note that [RFC3958] already defines that a failure to identify the server as being authoritative for the realm is always considered a failure; so even if a discovered target returns a wrong credential instantly, it is not eligible for retry. Furthermore, the contacted RADIUS/TLS server verifies during connection setup whether or not it finds the connecting RADIUS/TLS client authorized or not. If the connecting RADIUS/TLS client is not found acceptable, the server will close the TLS connection immediately with an appropriate alert. Such TLS handshake failures - are permanently fatal and not eligible for retry. + are permanently fatal and not eligible for retry, unless the + connecting client has more X.509 certificates to try; in this case, a + retry with the remainder of its set of certificates SHOULD be + attempted. If the TLS session setup to a discovered target does not succeed, that target (as identified by IP address and port number) SHOULD be ignored from the result set of any subsequent executions of the discovery algorithm at least until the target's Effective TTL has expired or until the entity which executes the algorithm changes its TLS context to either send a new client certificate or expect a different server certificate. 2.1.1.3. Server Identification and Handshake After the algorithm in this document has been executed, a RADIUS/TLS - session as per [RFC6614] is established. Since the algorithm does - not allow to derive confidential keying material between the RADIUS/ - TLS client (i.e. the server which executes the discovery algorithm) - and the RADIUS/TLS server which was discovered, TLS-PSK ciphersuites - can not be used for the subsequent TLS handshake in the RADIUS/TLS - conversation. Only TLS ciphersuites using X.509 certificates can be + session as per [RFC6614] is established. Since the dynamic discover + algorithm does not have provisions to establish confidential keying + material between the RADIUS/TLS client (i.e. the server which + executes the discovery algorithm) and the RADIUS/TLS server which was + discovered, TLS-PKS ciphersuites cannot be used for in the subsequent + TLS handshake. Only TLS ciphersuites using X.509 certificates can be used with this algorithm. There are numerous ways to define which certificates are acceptable for use in this context. This document defines one mandatory-to- implement mechanism which allows to verify whether the contacted host is authoritative for a NAI realm or not. It also gives one example of another mechanism which is currently in wide-spread deployment, and one possible approach based on DNSSEC which is yet unimplemented. 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm @@ -226,86 +231,72 @@ used with this algorithm. There are numerous ways to define which certificates are acceptable for use in this context. This document defines one mandatory-to- implement mechanism which allows to verify whether the contacted host is authoritative for a NAI realm or not. It also gives one example of another mechanism which is currently in wide-spread deployment, and one possible approach based on DNSSEC which is yet unimplemented. 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm + Verification of authority to provide AAA services over RADIUS/TLS is a two-step process. Step 1 is the verification of certificate wellformedness and validity as per [RFC5280] and whether it was issued from a root certificate which is deemed trustworthy by the RADIUS/TLS client. - Step 2 is: compare the value of algorithm's variable "R" after the + Step 2 is to compare the value of algorithm's variable "R" after the execution of step 3 of the discovery algorithm in Section 3.4.3 below (i.e. after a consortium name mangling, but before conversion to a form usable by the name resolution library) to all values of the contacted RADIUS/TLS server's X.509 certificate property "subjectAlternativeName:otherName:NAIRealm" as defined in - Section 2.2. The comparison is a byte-by-byte comparison, except for - dot-separated parts of the value whose content is a single "*" - character; such labels match all strings in the same part of the NAI - realm. If at least one of the sAN:otherName:NAIRealm values matches - the NAI realm, the server is considered authorized; if none matches, - the server is considered unauthorized. - - Examples: - - +-----------------+-----------------------------------------------+ - | NAI realm | NAIRealm | MATCH? | - +-----------------+-----------------------------------------------+ - | foo.example | foo.example | YES | - | foo.example | *.example | YES | - | bar.foo.example | *.example | NO | - | bar.foo.example | bar.*.example | NO (NAIRealm invalid) | - | bar.foo.example | *.*.example | NO (NAIRealm invalid) | - | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | - | sub.bar.foo.example | *.bar.foo.example | YES | - +-----------------+-----------------------------------------------+ - - Figure 3: Examples for NAI realm vs. certificate matching + Section 2.2. 2.1.1.3.2. Other mechanism: Trust Roots + policyOID Verification of authority to provide AAA services over RADIUS/TLS is a two-step process. Step 1 is the verification of certificate wellformedness and validity as per [RFC5280] and whether it was issued from a root certificate which is deemed trustworthy by the RADIUS/TLS client. - Step 2 is: compare the values of the contacted RADIUS/TLS server's + Step 2 is to compare the values of the contacted RADIUS/TLS server's X.509 certificate's extensions of type "Policy OID" to a list of configured acceptable Policy OIDs for the roaming consortium. If one of the configured OIDs is found in the certificate's Policy OID extensions, then the server is considered authorized; if there is no match, the server is considered unauthorized. This mechanism is inferior to the mandatory-to-implement mechanism in the previous section because all authorized servers are validated by the same OID value; the mechanism is not fine-grained enough to express authority for one specific realm inside the consortium. If the consortium contains members which are hostile against other members, this weakness can be exploited by one RADIUS/TLS server impersonating another if DNS responses can be spoofed by the hostile member. - It should be noted that these shortcomings can be mitigated by using - the RADIUS infrastructure only with authentication payloads which - provide mutual authentication; that way, the final EAP server that - was reached can be validated by the EAP peer, and any improper - redirections to a different server will be detected. + The shortcomings in server identification can be partially mitigated + by using the RADIUS infrastructure only with authentication payloads + which provide mutual authentication and credential protection (i.e. + EAP types passing the criteria of [RFC4017]): using mutual + authentication prevents the hostile server from mimicking the real + EAP server (it can't terminate the EAP authentication unnoticed + because it does not have the server certificate from the real EAP + server); protection of credentials prevents the impersonating server + from learning usernames and passwords of the ongoing EAP conversation + (other RADIUS attributes pertaining to the authentication, such as + the EAP peer's Calling-Station-ID, can still be learned though). 2.1.1.3.3. Other mechanism: DNSSEC / DANE Where DNSSEC is used, the results of the algorithm can be trusted; i.e. the entity which executes the algorithm can be certain that the realm that triggered the discovery is actually served by the server that was discovered via DNS. However, this does not guarantee that the server is also authorized (i.e. a recognised member of the roaming consortium). @@ -321,24 +312,25 @@ Realm = "example.com" Common Branch = "idp.roaming-consortium.example. label for TLSA query = "example.com.idp.roaming- consortium.example. result of discovery algorithm for realm "example.com" = 192.0.2.1:2083 + ( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : "FAIL" ) -2.1.1.3.4. Remark +2.1.1.3.4. Client Authentication and Authorisation Note that RADIUS/TLS connections always mutually authenticate the RADIUS server and the RADIUS client. This specification provides an algorithm for a RADIUS client to contact and verify authorization of a RADIUS server only. During connection setup, the RADIUS server also needs to verify whether it considers the connecting RADIUS client authorized; this is outside the scope of this specification. 2.1.2. SRV @@ -348,33 +340,33 @@ +-----------------+-----------------------------------------+ | SRV Label | Use | +-----------------+-----------------------------------------+ | _radiustls._tcp | RADIUS transported over TLS as defined | | | in [RFC6614] | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | _radiustls._udp | RADIUS transported over DTLS as defined | | | in [I-D.ietf-radext-dtls] | +-----------------+-----------------------------------------+ - Figure 4: List of SRV Labels + Figure 3: List of SRV Labels Just like NAPTR records, the lookup and subsequent follow-up of SRV records may yield more than one server to contact in a prioritised list. [RFC2782] does not specify rules regarding "Definition of Conditions for Retry/Failure", nor "Server Identification and Handshake". This specification defines that the rules for these two topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be used both for targets retrieved via an initial NAPTR RR as well as for targets retrieved via an initial SRV RR (i.e. in the absence of NAPTR RRs). -2.1.3. Remarks +2.1.3. Optional name mangling It is expected that in most cases, the SRV and/or NAPTR label used for the records is the DNS A-label representation of the literal realm name for which the server is the authoritative RADIUS server (i.e. the realm name after conversion according to section 5 of [RFC5891]). However, arbitrary other labels or service tags may be used if, for example, a roaming consortium uses realm names which are not associated to DNS names or special-purpose consortia where a globally @@ -465,31 +457,58 @@ a trusted comparison item. Further to this, this specification's NAPTR entries may be of type "A" which do not involve resolution of any SRV records, which again makes subjectAltName:otherName:sRVName unsuited for this purpose. This section defines the NAIRealm name as a form of otherName from the GeneralName structure in SubjectAltName defined in [RFC5280]. id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } + NAIRealm ::= UTF8String (SIZE (1..MAX)) The NAIRealm, if present, MUST contain an NAI realm as defined in [I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot- separated part of the NAI with the single character "*" to indicate a wildcard match for "all labels in this part". Further features of regular expressions, such as a number of characters followed by a * to indicate a common prefix inside the part, are not permitted. + The comparison of a NAIRealm to the NAI realm as derived from user + input with this algorithm is a byte-by-byte comparison, except for + the optional leftmost dot-separated part of the value whose content + is a single "*" character; such labels match all strings in the same + dot-separated part of the NAI realm. If at least one of the + sAN:otherName:NAIRealm values matches the NAI realm, the server is + considered authorized; if none matches, the server is considered + unauthorized. + This subjectAltName MAY occur more than once in a certificate. + Examples: + + +---------------------+-------------------+-----------------------+ + | NAI realm (RADIUS) | NAIRealm (cert) | MATCH? | + +---------------------+-------------------+-----------------------+ + | foo.example | foo.example | YES | + | foo.example | *.example | YES | + | bar.foo.example | *.example | NO | + | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | + | bar.foo.example | bar.*.example | NO (NAIRealm invalid) | + | bar.foo.example | *.*.example | NO (NAIRealm invalid) | + | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | + | sub.bar.foo.example | *.bar.foo.example | YES | + +-----------------+-----------------------------------------------+ + + Figure 4: Examples for NAI realm vs. certificate matching + Appendix A contains the ASN.1 definition of the above objects. 3. DNS-based NAPTR/SRV Peer Discovery 3.1. Applicability Dynamic server discovery as defined in this document is only applicable for AAA transactions where a RADIUS entity which acts as a forwarding server for one or more realms receives a request with a realm for which it is not authoritative, and which no explicit next @@ -644,21 +663,21 @@ 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = BACKOFF_TIME and terminate. 11. O' = (set of {hostname; port; order/preference; Effective TTL ( all DNS TTLs that led to this hostname ) } for all terminal lookup results). 12. Proceed with step 18. - 13. Generate R' = (prefix R with "_radiustls._tcp." or + 13. Generate R' = (prefix R with "_radiustls._tcp." and/or "_radiustls._udp.") 14. Using the host's name resolution library, perform SRV lookup with R' as label (see "Delay considerations" below). 15. If name resolution returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and terminate. 16. If the result is a negative DNS response, O-1 = { empty set }, O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) } @@ -856,31 +875,24 @@ }; O-2 = 0 19. No match with own listening address; terminate with tuple (O-1, O-2) from previous step. The implementation will then attempt to connect to two servers, with preference to [2001:0DB8::202:44ff:fe0a:f704]:2083. 4. Security Considerations - - The results from the execution of this algorithm are only trustworthy - if each of the lookup steps by the name resolution library were - cryptographically secured; i.e. if DNSSEC validation was turned on - during the resolution AND all of the records were in a DNSSEC signed - zone AND validation of all those records was successful. - - When using DNS without DNSSEC security extensions for at least one of - the replies to NAPTR, SRV and A/AAAA requests as described in section - Section 3, the result O can not be trusted. Even if it can be - trusted (i.e. DNSSEC is in use), actual authorization of the + When using DNS without DNSSEC security extensions and validation for + all of the replies to NAPTR, SRV and A/AAAA requests as described in + section Section 3, the result O can not be trusted. Even if it can + be trusted (i.e. DNSSEC is in use), actual authorization of the discovered server to provide service for the given realm needs to be verified. A mechanism from section Section 2.1.1.3 or equivalent MUST be used to verify authorization. The algorithm has a configurable completion time-out DNS_TIMEOUT defaulting to three seconds for RADIUS' operational reasons. The lookup of DNS resource records based on unverified user input is an attack vector for DoS attacks: an attacker might intentionally craft bogus DNS zones which take a very long time to reply (e.g. due to a particularly byzantine tree structure, or artificial delays in @@ -939,52 +951,58 @@ o In addition to that, with the clearinghouse being a RADIUS intermediate in possession of a valid shared secret, the clearinghouse can observe and record even the security-critical RADIUS attributes such as User-Password. This risk may be mitigated by choosing authentication payloads which are cryptographically secured and do not use the attribute User- Password - such as certain EAP types. o There is no additional information disclosure to parties outside - the IP path between the RADIUS client and server (in aprticular, + the IP path between the RADIUS client and server (in particular, no DNS servers learn about realms of current ongoing authentications). With RADIUS and dynamic discovery, - o Passive observers on the IP path cannot inspect any part of the - RADIUS payload. They can observe source and destination of the - traffic flow, but can not easily use this information to create - mobility profiles because the user who tries to authenticate is - not identifiable due to the encrypted payload. - o Clearinghouses can be eliminated by RADIUS clients directly contacting the RADIUS home server, if this is desired. The possibility of aggregation of user information in the clearinghouse thus does not manifest. Note that despite the - technical possibility of avoid clearinghouses, they may still + technical possibility of avoiding clearinghouses, they may still remain in operation for other reasons. + o Even where intermediate proxies continue to be used for reasons + unrelated to dynamic discovery, the number of such intermediates + may be reduced by removing those proxies which are only deployed + for pure request routing reasons. This reduces the number of + entities which can inspect the RADIUS traffic. + o RADIUS clients which make use of dynamic discovery will need to query the Domain Name System, and use a user's realm name as the query label. A passive observer on the IP path between the RADIUS client and the DNS server(s) being queried can learn that a user of that specific realm was trying to authenticate at that RADIUS client at a certain point in time. This may or may not be sufficient for the passive observer to create a mobility profile. During the recursive DNS resolution, a fair number of DNS servers and the IP hops in between those get to learn that information. Not every single authentication triggers DNS lookups, so there is no one-to-one relation of leaked realm information and the number of authentications for that realm. + o Since dynamic discovery operates on a RADIUS hop-by-hop basis, + there is no guarantee that the RADIUS payload is not transmitted + between RADIUS systems which do not make use of this algorithm, + and possibly using other transports such as RADIUS/UDP. On such + hops, the enhanced privacy is jeopardized. + In summary, with classic RADIUS, few intermediate entities learn very detailed data about every ongoing authentications, while with dynamic discovery, many entities learn only very little about recently authenticated realms. 6. IANA Considerations This document requests IANA registration of the following entries in existing registries: @@ -1014,21 +1033,23 @@ This specification allocates a X.509 certificate property "NAIRealm" as per section Section 2.2 above, see placeholders "XXX". There is currently no IANA registry for the subjectAltName:otherName namespace. The authority for this namespace appears to be the PKIX working group. Before issuing the RFC, IANA should liaise with PKIX to ensure that a value for NAIRealm is issued; IANA should subsequently, prior to issuing the RFC, update the placeholders in said section. -7. Normative References +7. References + +7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC @@ -1052,60 +1073,67 @@ [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [I-D.ietf-radext-dtls] DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- - ietf-radext-dtls-05 (work in progress), April 2013. + ietf-radext-dtls-07 (work in progress), October 2013. [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012. [I-D.ietf-radext-nai] DeKok, A., "The Network Access Identifier", draft-ietf- - radext-nai-03 (work in progress), May 2013. + radext-nai-05 (work in progress), November 2013. -Appendix A. Appendix A: ASN.1 Syntax of NAIRealm +7.2. Informative References + + [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible + Authentication Protocol (EAP) Method Requirements for + Wireless LANs", RFC 4017, March 2005. +Appendix A. Appendix A: ASN.1 Syntax of NAIRealm PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dns-srv-name-93(40) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS id-pkix - FROM PKIX1Explicit88 { iso(1) identified-organization(3) - dod(6) internet(1) security(5) mechanisms(5) pkix(7) - id-mod(0) id-pkix1-explicit(18) } ; + FROM PKIX1Explicit-2009 + {iso(1) identified-organization(3) dod(6) internet(1) + security(5) mechanisms(5) pkix(7) id-mod(0) + id-mod-pkix1-explicit-02(51)} -- from RFC 5280 - -- In the GeneralName definition using the 1993 ASN.1 syntax - -- includes: - - OTHER-NAME ::= TYPE-IDENTIFIER + OTHER-NAME + FROM PKIX1Implicit-2009 + {iso(1) identified-organization(3) dod(6) internet(1) security(5) + mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} + ; -- Service Name Object Identifier id-on OBJECT IDENTIFIER ::= { id-pkix 8 } - id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } + id-on-nai OBJECT IDENTIFIER ::= { id-on 99999 } -- Service Name naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }} NAIRealm ::= UTF8String (SIZE (1..MAX)) END Authors' Addresses