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

["Pearl Liang via RT" <[e-mail]>]

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, [e-mail] wrote:
> 
> Application for a Port Number and/or Service Name
> 
> Assignee: IESG <[e-mail]>
> Contact Person: IETF Chair <[e-mail]>
> 
> 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.
> []