[radext] [IANA #814379] Application for a Service Name "radiustls"

"Pearl Liang via RT" <iana-prot-param@iana.org> Mon, 23 March 2015 21:26 UTC

Return-Path: <iana-shared@icann.org>
X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org
Delivered-To: radext@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 50C301A1B40; Mon, 23 Mar 2015 14:26:01 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC031A1B1E; Mon, 23 Mar 2015 14:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.19
X-Spam-Level:
X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYVMd_HZ5UhA; Mon, 23 Mar 2015 14:25:59 -0700 (PDT)
Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F101A1AFF; Mon, 23 Mar 2015 14:25:59 -0700 (PDT)
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2NLPwM7014447; Mon, 23 Mar 2015 21:25:58 GMT
Received: by request3.lax.icann.org (Postfix, from userid 48) id C6895C20682; Mon, 23 Mar 2015 21:25:58 +0000 (UTC)
RT-Owner: pearl.liang
From: "Pearl Liang via RT" <iana-prot-param@iana.org>
In-Reply-To: <201503200844.t2K8iwiC011679@smtp1.lax.icann.org>
References: <RT-Ticket-814379@icann.org> <201503200844.t2K8iwiC011679@smtp1.lax.icann.org>
Message-ID: <rt-4.2.9-22561-1427145958-360.814379-7-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #814379
X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/)
X-RT-Originator: pearl.liang@icann.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Mon, 23 Mar 2015 21:25:58 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/QbJslPrJBbqEjtt82MjSurY5yl4>
X-Mailman-Approved-At: Mon, 23 Mar 2015 15:29:39 -0700
Cc: draft-ietf-radext-dynamic-discovery.all@ietf.org, chair@ietf.org, iesg@ietf.org
Subject: [radext] [IANA #814379] Application for a Service Name "radiustls"
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: iana-prot-param@iana.org
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 21:26:01 -0000

Dear IESG/Authors:

We have processed this request (included below).
This message is to confirm that we have registered the following as per
draft-ietf-radext-dynamic-discovery-13:


radiustls		tcp	Authentication, Accounting and Dynamic authorization via the RADIUS protocol. This service name is used to construct the SRV service label "_radiustls" for discovery of RADIUS/TLS servers	[IESG]	[IETF_Chair]	2015-03-23		[draft-ietf-radext-dynamic-discovery-13]			Defined TXT keys: None
radiustls		udp	Authentication, Accounting and Dynamic authorization via the RADIUS protocol. This service name is used to construct the SRV service label "_radiustls" for discovery of RADIUS/TLS servers	[IESG]	[IETF_Chair]	2015-03-23		[draft-ietf-radext-dynamic-discovery-13]			Defined TXT keys: None


Please see:
http://www.iana.org/assignments/service-names-port-numbers

When the document has been approved for publication as an RFC, we will update
the draft string to the approved RFC number.

Thank you,

Pearl Liang
ICANN


On Fri Mar 20 08:44:59 2015, chair@ietf.org wrote:
> 
> Application for a Port Number and/or Service Name
> 
> Assignee: IESG <iesg@ietf.org>
> Contact Person: IETF Chair <chair@ietf.org>
> 
> Resource Request:
> 
> [ ] Port Number
> [x] Service Name
> 
> Transport Protocols:
>     [x] TCP
>     [ ] UDP
>     [ ] SCTP
>     [ ] DCCP
> 
> Service Code:         []
> Service Name:         [radiustls]
> Desired Port Number:  []
> Description:          [Authentication, Accounting and Dynamic
> authorization via the RADIUS protocol.  This service name is used to
> construct the SRV service label "_radiustls" for discovery of
> RADIUS/TLS servers.]
> 
> Reference:
> [http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-13]
> 
> Defined TXT Keys:
> 
> 1.  If broadcast/multicast is used, how and what for?
> [Not used.]
> 
> 2.  If UDP is requested, please explain how traffic is limited, and
> whether the
>     protocol reacts to congestion.
> [Not requested.]
> 
> 3.  If UDP is requested, please indicate whether the service is solely
>     for the discovery of hosts supporting this protocol.
> [Not requested.]
> 
> 4.  Please explain how your protocol supports versioning.
> [The protocol immediately initiates TLS (no STARTTLS). TLS version
> negotiation follows as usual.]
> 
> 5.  If your request is for more than one transport, please explain in
>     detail how the protocol differs over each transport.
> [No other transport besides TCP requested; note however the parallel
> service name radiusdtls which will be requested for RADIUS/DTLS over
> UDP.]
> 
> 6.  Please describe how your protocol supports security. Note that
> presently
>     there is no IETF consensus on when it is appropriate to use a
> second port
>     for an insecure version of a protocol.
> [Traditional RADIUS over UDP has no version negotiation and no
> protocol phase which would allow the equivalent of STARTTLS. A new
> port is thus required and was assigned in RFC6614. The service name
> requested here only allows to discover servers supporting RFC6614 in
> DNS. The discovery algorithm in this draft uses DNSSEC where
> available, but has provisions for server authorisation verification in
> the absence of DNSSEC (using PKIX certificate extensions).]
> 
> 7.  Please explain why a unique port assignment is necessary as
> opposed to a
>    port in range (49152-65535) or existing port.
> [No port is requested here (RFC6614 already has a port for
> RADIUS/TLS).]
> 
> 8.  Please explain the state of development of your protocol.
> [The protocol is already in use on the internet by a large roaming
> consortium.]
> 
> 9.  If SCTP is requested, is there an existing TCP and/or UDP service
> name or
>     port number assignment? If yes, provide the existing service name
> and port number.
> [SCTP is not requested.]
> 
> 10.  What specific SCTP capability is used by the application such
> that a
>     user who has the choice of both TCP (and/or UDP) and SCTP ports
> for
>     this application would choose SCTP? See RFC 4960 section 7.1.
> [SCTP is not requested.]
> 
> 11. Please provide any other information that would be helpful in
>     understanding how this protocol differs from existing assigned
> services.
> []