Re: [radext] New DTLS document

Stig Venaas <stig@venaas.com> Tue, 07 May 2013 17:34 UTC

Return-Path: <stig@venaas.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DE221F93B4 for <radext@ietfa.amsl.com>; Tue, 7 May 2013 10:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jauLsW2x2n2 for <radext@ietfa.amsl.com>; Tue, 7 May 2013 10:33:59 -0700 (PDT)
Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 829F021F9130 for <radext@ietf.org>; Tue, 7 May 2013 10:33:51 -0700 (PDT)
Received: from [IPv6:2001:420:4:ea0c:f9c1:dccb:fdeb:7088] (unknown [IPv6:2001:420:4:ea0c:f9c1:dccb:fdeb:7088]) by ufisa.uninett.no (Postfix) with ESMTPSA id EFB9B813C for <radext@ietf.org>; Tue, 7 May 2013 19:33:49 +0200 (CEST)
Message-ID: <51893AFB.1080006@venaas.com>
Date: Tue, 07 May 2013 10:33:47 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: radext@ietf.org
References: <516EA97E.2000005@deployingradius.com> <C47910C2-BCEA-4DC2-A016-C98D67B62DD9@gmail.com> <A95B4818FD85874D8F16607F1AC7C628B4032E@xmb-rcd-x09.cisco.com> <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com>
In-Reply-To: <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [radext] New DTLS document
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Tue, 07 May 2013 17:34:00 -0000

On 4/29/2013 1:32 AM, Jouni Korhonen wrote:
>
> Thanks Joe for detailed comments. Just few generic questions to the WG.
>
> 1) Do you agree with Joe's suggestion to use the same port as RADSEC:
>
> 	radius-dtls 2083/udp RADIUS over DTLS [RFCTBD]

I support using the same port as RADSEC.

> 2) Do you think Joe's concern on Section 5.1.2 "disambiguation recommendation"
>     is something that need to be reconsidered..

FWIW, I've also implemented RADSEC over DTLS and at least with my
implementation it would be hard to do both regular RADIUS and DTLS
on the same port. So I certainly prefer them to be different ports.

No other comments.

Stig

> - Jouni
>
>
> On Apr 22, 2013, at 8:32 AM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:
>
>> I think there are a few inconsistencies that need cleaning-up:
>>
>> - Section 2.2.1
>>
>> Section 2.5 of RFC 6614 should apply to RADIUS over DTLS since a single port is used for all types of RADIUS codes.  ( I think the last bullet point in section 2.1 should be removed as well.)
>>
>> - Section 5.1.1
>>
>> This section references a requirement to receive RADIUS/UDP and RADIUS/DTLS on the same port, this is no longer a requirement.  Suggest cleaning up the text along the lines of:
>>
>> " ...  Implementations that accept RADIUS/DTLS on the RADIUS/UDP port may find this recommendation difficult to implement in
>>    practice.  ... "
>>
>> - Section 5.1.2
>>
>> I still have a concern about the disambiguation recommendation since it relies upon a protocol field which is not in control of RADIUS, but it is rather in control of DTLS.  Its possible that int he future DTLS may choose to define a new extended handshake type that would use a different type code of 22.  This would introduce ambiguity and prevent this version of DTLS from being used with this mechanism.  It would be a better, more reliable design to have the disambiguation rely upon something that RADIUS had control over.   For example, define a RADIUS code type that encapsulates a RADIUS DTLS message.
>>
>> Additionally section 5.1.2 should clarify that it only applies to implementations that accept RADIUS/DTLS on the RADIUS/UDP port
>>
>> - Section 5.1.3
>>
>> Most of this section applies to implementations that accept RADIUS/DTLS on the RADIUS/UDP port.  THis section should clarify this.  I think the last 3 paragraphs are generic and can be moved to a a different section, such as 5.1.1.
>>
>>
>> - Section 9
>>
>> We could request the same port as RADSEC.  Something like:
>>
>> IANA is requested to assign a registered UDP  port number for RADIUS over DTLS.  The same values as for RADIUS over TLS (RFC6614) are requested.  That is, update the registry as follows:
>>
>>       radius-dtls 2083/udp RADIUS over DTLS [RFCTBD]
>>
>>
>>
>>
>>
>>
>> On Apr 18, 2013, at 12:26 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
>>
>>>
>>> Folks,
>>>
>>> <as a co-chair>
>>>
>>> Everybody happy with -05 ? If I here no immediate
>>> voices of disagreement, we can conclude the WG
>>> has reached consensus and the document can move
>>> forward. I'll wait till next Monday.
>>>
>>> - Jouni
>>>
>>>
>>>
>>> On Apr 17, 2013, at 4:54 PM, Alan DeKok <aland@deployingradius.com> wrote:
>>>
>>>> http://tools.ietf.org/html/draft-ietf-radext-dtls-05
>>>>
>>>> Which addresses all of the open concerns.
>>>>
>>>> Alan DeKok.
>>>> _______________________________________________
>>>> radext mailing list
>>>> radext@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/radext
>>>
>>> _______________________________________________
>>> radext mailing list
>>> radext@ietf.org
>>> https://www.ietf.org/mailman/listinfo/radext
>>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>