Subject: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item

From: Bernard Aboba <[email-masked]>
Date: Sun, 19 Jul 2009 07:19:15 -0700

This is a reminder of an ongoing call for review of the document "RADIUS attributes for IPv6
Access Networks" for adoption as a RADEXT WG work item.  This document is being targeted at Proposed Standard
status. 

The document is available for review here:
http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access

This
call for review will last until August 7, 2009.  Please send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.  If you have comments on the
document, please also send these to the list in the format described on
the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/

---

From: "MILES DAVID" <[email-masked]>
Date: Sat, 1 Aug 2009 05:37:23 +0800

As an implementer I would like to lend my support to adopting this draft
as a WG item. We currently need VSA for many of the items proposed which
restricts interoperability between vendors.

I'm happy to work with the authors to ready this draft for a last call
as needed

Cheers, 

David Miles
Alcatel-Lucent
Product Manager - IPv6 & Broadband
Level 3, 215 Spring St
Melbourne VIC 3000, Australia
p. +61 3 9664 3308
c. +61 417 684 617
e. [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 31 Jul 2009 21:38:29 +0000
Content-class: urn:content-classes:message
Subject: Re: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item
Date: Sat, 1 Aug 2009 05:37:23 +0800
From: "MILES DAVID" <[email-masked]>
To: <[email-masked]>

As an implementer I would like to lend my support to adopting this draft
as a WG item. We currently need VSA for many of the items proposed which
restricts interoperability between vendors.

I'm happy to work with the authors to ready this draft for a last call
as needed

Cheers, 

David Miles
Alcatel-Lucent
Product Manager - IPv6 & Broadband
Level 3, 215 Spring St
Melbourne VIC 3000, Australia
p. +61 3 9664 3308
c. +61 417 684 617
e. [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 30 Jul 2009 19:51:56 +0000
Date: Thu, 30 Jul 2009 21:49:34 +0200
From: Stefan Winter <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>,  [email-masked]
Subject: Re: Slides

This is a multi-part message in MIME format.
--------------040903000806010709040902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I have been exposed to eduroam's PKI expert for an extended amount of 
time today. The result is that I had to update my RadSec slides. Attached.

Greetings,

Stefan Winter

--------------040903000806010709040902
Content-Type: application/pdf;
 name="ietf75-radext-radsec.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="ietf75-radext-radsec.pdf"

--------------040903000806010709040902--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 30 Jul 2009 19:51:46 +0000
Date: Thu, 30 Jul 2009 21:50:50 +0200
From: Stefan Winter <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>,  [email-masked]
Subject: Re: Slides

This is a multi-part message in MIME format.
--------------030907050202020601040501
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I have been exposed to eduroam's PKI expert for an extended amount of 
time today. The result is that I had to update my RadSec slides. Attached.

Greetings,

Stefan Winter

--------------030907050202020601040501
Content-Type: application/pdf;
 name="ietf75-radext-radsec.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="ietf75-radext-radsec.pdf"

--------------030907050202020601040501--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 28 Jul 2009 11:27:02 +0000
Date: Tue, 28 Jul 2009 13:26:06 +0200
From: Stefan Winter <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>,  [email-masked]
Subject: Re: Slides

This is a multi-part message in MIME format.
--------------040407070202090700010600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

slides for RadSec and NAI discovery are attached.

Greetings,

Stefan Winter

--------------040407070202090700010600
Content-Type: application/pdf;
 name="ietf75-radext-nai-discovery.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="ietf75-radext-nai-discovery.pdf"

--------------040407070202090700010600
Content-Type: application/pdf;
 name="ietf75-radext-radsec.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="ietf75-radext-radsec.pdf"

Rgo--------------040407070202090700010600--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Mon, 27 Jul 2009 09:35:08 +0000
To: [email-masked], [email-masked]
Subject: RFC 5607 on Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
From: [email-masked]
Cc: [email-masked], [email-masked]
Message-Id: <[email-masked]>
Date: Mon, 27 Jul 2009 02:30:19 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 5607

        Title:      Remote Authentication Dial-In User Service 
                    (RADIUS) Authorization for Network Access Server 
                    (NAS) Management 
        Author:     D. Nelson, G. Weber
        Status:     Standards Track
        Date:       July 2009
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      25
        Characters: 55464
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-radext-management-authorization-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5607.txt

This document specifies Remote Authentication Dial-In User Service
(RADIUS) attributes for authorizing management access to a Network
Access Server (NAS).  Both local and remote management are supported,
with granular access rights and management privileges.  Specific
provisions are made for remote management via Framed Management
protocols and for management access over a secure transport protocol.
[STANDARDS TRACK]

This document is a product of the RADIUS EXTensions Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 27 Jul 2009 07:30:39 +0000
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Mon, 27 Jul 2009 09:29:28 +0200
Subject: RE: Crypto-agility requirements:  Hop-by-hop vs. end-to-end (from Issue 303)
Accept-Language: en-US
acceptlanguage: en-US

Bernard Aboba wrote

> A proposal for addressing this would be to state explicitly that
> solutions are only required to address hop-by-hop security.�� 
> more explanation is required, one or more of the following points
> might be included:
<...>

I think just stating this explicitly would be sufficient, and more 
explanation isn't needed...

Best regards,
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 26 Jul 2009 23:07:25 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: <[email-masked]>, "[email-masked]" <[email-masked]>, <[email-masked]>
Subject: RE: review of draft-zorn-radius-pkmv1-04.txt
Date: Sun, 26 Jul 2009 16:06:59 -0700

--_ff633059-9086-4aea-9e50-16f58ffe3021_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   I believe the intent was "related to RADIUS security".  The guidelines
> document could be updated to address this.

The rationale behind the original exemption was that security required
changes on both the RADIUS client and server.  Therefore the RADIUS
server would need a code change anyway, regardless of whether the
attributes were complex or simple.   That rationale applies not just
to "RADIUS security" but also to authentication mechanisms, many of
which were previously implemented with complex attributes (e.g. CHAP). 
So I'm not clear that we're talking about a "loophole" here. 

> encapsulation using RFC 2548 MPPE-Key attributes...

I was unclear about how this is supposed to work.  Is the idea to apply
the MPPE-Key encryption mechanism to the attribute specified
in the draft, or is the idea to actually use the MPPE-Key attributes 
themselves?  If the former, more detail should be provided.  If the latter,
is it necessary to define two attribute formats or would it be simpler to
go with one?  If the RFC 2548 MPPE-Key attributes are used, is the format
the same as that defined in RFC 2548 (just a wrapped key) or is the wrapping
applied to a complex attribute?  

> a four octet Integer should be used instead of a two octet data type
> (which doesn't exist in RADIUS)

As I recall, the security exemption didn't apply to creation of new RADIUS
data types, correct? 

--_ff633059-9086-4aea-9e50-16f58ffe3021_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
&gt;   I believe the intent was "related to RADIUS security".  The guidelines<br>&gt; document could be updated to address this.<br><br>The rationale behind the original exemption was that security required<br>changes on both the RADIUS client and server.&nbsp; Therefore the RADIUS<br>server would need a code change anyway, regardless of whether the<br>attributes were complex or simple.&nbsp;&nbsp; That rationale applies not just<br>to "RADIUS security" but also to authentication mechanisms, many of<br>which were previously implemented with complex attributes (e.g. CHAP). <br>So I'm not clear that we're talking about a "loophole" here. <br><br>&gt; encapsulation using RFC 2548 MPPE-Key attributes...<br><br>I was unclear about how this is supposed to work.&nbsp; Is the idea to apply<br>the MPPE-Key encryption mechanism to the attribute specified<br>in the draft, or is the idea to actually use the MPPE-Key attributes <br>themselves?&nbsp; If the former, more detail should be provided.&nbsp; If the latter,<br>is it necessary to define two attribute formats or would it be simpler to<br>go with one?&nbsp; If the RFC 2548 MPPE-Key attributes are used, is the format<br>the same as that defined in RFC 2548 (just a wrapped key) or is the wrapping<br>applied to a complex attribute?&nbsp; <br><br>&gt; a four octet Integer should be used instead of a two octet data type<br>&gt; (which doesn't exist in RADIUS)<br><br>As I recall, the security exemption didn't apply to creation of new RADIUS<br>data types, correct? <br><br><br></body>
</html>
--_ff633059-9086-4aea-9e50-16f58ffe3021_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 26 Jul 2009 22:37:40 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Audio Stream information for IETF 75 (fwd)
Date: Sun, 26 Jul 2009 15:37:16 -0700

--_68d3066f-a688-4515-957d-e03b6f84539e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The links to the audio streams aren't currently on the ietf.org page.   
We apologize and are working to correct this.
 
In the meantime, here is a list of direct links to the audio streams.
 
Kongresshall A	http://feed.verilan.com/ietf/stream08.m3u
Kongresshall B	http://feed.verilan.com/ietf/stream01.m3u
Kongresshall C	http://feed.verilan.com/ietf/stream02.m3u
Cabaret			http://feed.verilan.com/ietf/stream03.m3u
300				http://feed.verilan.com/ietf/stream04.m3u
307				http://feed.verilan.com/ietf/stream05.m3u
Small Stage		http://feed.verilan.com/ietf/stream06.m3u
Large Stage		http://feed.verilan.com/ietf/stream07.m3u
 
Nick Kukich
 
Network Engineering
 
[email-masked]
www.verilan.com
 
VeriLAN Event Services, Inc.
215 SE Morrison Street Suite 7000
Portland, OR 97214
 
Tel:  503 907-1427
Fax: 503 224-8833
Cell: 503 290-8676

 EMAILING FOR THE GREATER GOOD
Join me
--_68d3066f-a688-4515-957d-e03b6f84539e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<pre>The links to the audio streams aren't currently on the ietf.org page.   <br>We apologize and are working to correct this.<br> <br>In the meantime, here is a list of direct links to the audio streams.<br> <br>Kongresshall A	<a href="http://feed.verilan.com/ietf/stream08.m3u" target="_blank">http://feed.verilan.com/ietf/stream08.m3u</a><br>Kongresshall B	<a href="http://feed.verilan.com/ietf/stream01.m3u" target="_blank">http://feed.verilan.com/ietf/stream01.m3u</a><br>Kongresshall C	<a href="http://feed.verilan.com/ietf/stream02.m3u" target="_blank">http://feed.verilan.com/ietf/stream02.m3u</a><br>Cabaret			<a href="http://feed.verilan.com/ietf/stream03.m3u" target="_blank">http://feed.verilan.com/ietf/stream03.m3u</a><br>300				<a href="http://feed.verilan.com/ietf/stream04.m3u" target="_blank">http://feed.verilan.com/ietf/stream04.m3u</a><br>307				<a href="http://feed.verilan.com/ietf/stream05.m3u" target="_blank">http://feed.verilan.com/ietf/stream05.m3u</a><br>Small Stage		<a href="http://feed.verilan.com/ietf/stream06.m3u" target="_blank">http://feed.verilan.com/ietf/stream06.m3u</a><br>Large Stage		<a href="http://feed.verilan.com/ietf/stream07.m3u" target="_blank">http://feed.verilan.com/ietf/stream07.m3u</a><br> <br>Nick Kukich<br> <br>Network Engineering<br> <br>[email-masked]<br>www.verilan.com<br> <br>VeriLAN Event Services, Inc.<br>215 SE Morrison Street Suite 7000<br>Portland, OR 97214<br> <br>Tel:  503 907-1427<br>Fax: 503 224-8833<br>Cell: 503 290-8676</pre><br><br><br><br><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><img style="border-style: none;" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt="i'm"> EMAILING FOR THE GREATER GOOD<br><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;">Join me</span></a></td></tr></tbody></table></body>
</html>
--_68d3066f-a688-4515-957d-e03b6f84539e_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 26 Jul 2009 22:20:02 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Slides
Date: Sun, 26 Jul 2009 15:19:20 -0700

--_733094d8-c94d-469a-856a-b98b3a2add1f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If you have a slot at the RADEXT WG meeting on Friday, please
send your slides to myself and Dave so we can get them up on 
the agenda site. 

--_733094d8-c94d-469a-856a-b98b3a2add1f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
If you have a slot at the RADEXT WG meeting on Friday, please<br>send your slides to myself and Dave so we can get them up on <br>the agenda site. <br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a></td></tr></tbody></table></body>
</html>
--_733094d8-c94d-469a-856a-b98b3a2add1f_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 24 Jul 2009 15:07:49 +0000
Date: Fri, 24 Jul 2009 17:06:49 +0200
From: Alan DeKok <[email-masked]>
To: [email-masked]
CC: Glen Zorn <[email-masked]>, [email-masked],  radext mailing list <[email-masked]>, [email-masked]
Subject: Re: AD review of draft-zorn-radius-pkmv1-04.txt

[email-masked] wrote:
> Yeah.  I've always been a bit uncomfortable with the "security
> functionality" escape clause in the RADIUS Design Guidelines draft. 
> Lots of things can reasonably be claimed to be "security related".  I
> would have preferred the exception to be crafted a bit narrower, just
> for this reason.  But, unless wording of Design Guidelines is changed,
> you have a legitimate argument.

  I believe the intent was "related to RADIUS security".  The guidelines
document could be updated to address this.

  RADIUS could transport parameters for *another* protocol.  Those
attributes are not security related.  They either follow the RADIUS data
model (int, IP address, etc.), or they are "opaque data" that RADIUS is
simply transporting on the behalf of the other protocol.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Jul 2009 20:22:15 +0000
Date: Thu, 23 Jul 2009 20:21:29 +0000 (UTC)
From: [email-masked]
To: Glen Zorn <[email-masked]>
Cc: [email-masked], radext mailing list <[email-masked]>,  [email-masked], Alan DeKok <[email-masked]>
Subject: Re: AD review of draft-zorn-radius-pkmv1-04.txt

------=_Part_243466_1819363248.1248380489142
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Glen Zorn writes... 

> > As a  result, the introduction of new complex data types within 

> > RADIUS attribute specifications SHOULD be avoided, except 

> > in the case of complex attributes involving authentication or 

> > security functionality. 
> 
> All of the attributes are security related. 

Yeah.  I've always been a bit uncomfortable with the "security functionality" escape clause in the RADIUS Design Guidelines draft.  Lots of things can reasonably be claimed to be "security related".  I would have preferred the exception to be crafted a bit narrower, just for this reason.  But, unless wording of Design Guidelines is changed, you have a legitimate argument. 

> >   I do not see any pressing need to make this attribute carry seven 
> > independent fields.  The RADIUS attribute space has sufficient room to 
> > allocate 7 attributes.  If the extended attribute format is used, then 
> > nearly all space limitations are removed.  I would recommend that these 
> > independent values be split up into independent attributes that follow 
> > the RADIUS data model. 
> 
> Given that there are already multiple interoperable implementations and all 
> of the attributes are security related, I see no pressing need to make 
> people change running code to satisfy your personal preferences.  Sorry if 
> these attributes were designed to be easy to implement for people writing 
> PKM code, rather than RADIUS code. 

No one has ever claimed that following the RADIUS Design Guidelines is the only way to interoperable implementations.  Lots of designs, good, bad and indifferent, can be made to interoperate . 

If we are to dismiss the Design Guidelines as a "personal preference" how are they to be taken seriously?  I understand that following someone else's design guidance is not always popular with developers, but following regular design patterns is a well recognized practice in software engineering, that is generally attributed with increasing product quality and maintainability.  I think we simply need to "get with the program" here. 

------=_Part_243466_1819363248.1248380489142
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 12pt; color: #000000'><P>Glen Zorn writes...</P>
<P><BR>&gt; &gt;&nbsp;As a&nbsp;&nbsp;result, the introduction of new complex data types within</P>
<P>&gt; &gt;&nbsp;RADIUS attribute specifications SHOULD be avoided, except </P>
<P>&gt; &gt; in the case of complex attributes involving authentication or </P>
<P>&gt; &gt; security functionality.<BR>&gt;<BR>&gt; All of the attributes are security related.</P>
<P>&nbsp;</P>
<P>Yeah.&nbsp; I've always been a bit uncomfortable with the "security functionality" escape clause in the RADIUS Design Guidelines draft.&nbsp; Lots of things can reasonably be claimed to be "security related".&nbsp; I would have preferred the exception to be crafted a bit narrower, just for this reason.&nbsp; But, unless wording of Design Guidelines&nbsp;is changed, you have a legitimate argument.</P>
<P><BR>&gt; &gt; &nbsp; I do not see any pressing need to make this attribute carry seven<BR>&gt; &gt; independent fields. &nbsp;The RADIUS attribute space has sufficient room to<BR>&gt; &gt; allocate 7 attributes. &nbsp;If the extended attribute format is used, then<BR>&gt; &gt; nearly all space limitations are removed. &nbsp;I would recommend that these<BR>&gt; &gt; independent values be split up into independent attributes that follow<BR>&gt; &gt; the RADIUS data model.<BR>&gt;<BR>&gt; Given that there are already multiple interoperable implementations and all<BR>&gt; of the attributes are security related, I see no pressing need to make<BR>&gt; people change running code to satisfy your personal preferences. &nbsp;Sorry if<BR>&gt; these attributes were designed to be easy to implement for people writing<BR>&gt; PKM code, rather than RADIUS code.</P>
<P>&nbsp;</P>
<P>No one has ever claimed that following the RADIUS Design Guidelines is the only way to interoperable implementations.&nbsp; Lots of designs, good, bad and indifferent, can be made to interoperate.</P>
<P>&nbsp;</P>
<P>If we are to dismiss the Design Guidelines as a "personal preference" how are&nbsp;they to be taken seriously?&nbsp; I understand that following someone else's design guidance is not always popular with developers, but following regular design patterns is a well recognized practice&nbsp;in software engineering, that is generally attributed with increasing product quality and maintainability.&nbsp; I think we simply need to "get with the program" here.</P>
<P>&nbsp;</P></div></body></html>
------=_Part_243466_1819363248.1248380489142--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Jul 2009 15:02:46 +0000
Date: Thu, 23 Jul 2009 17:01:52 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'radext mailing list' <[email-masked]>, [email-masked],  [email-masked]
Subject: Re: AD review of draft-zorn-radius-pkmv1-04.txt

Glen Zorn wrote:
> No.  There _are_ implementations as I rather clearly stated at the meeting
> in SF, using the Experimental attribute space.

  So the implementations have to be updated to use the IANA code points,
independent of them possibly using the extended attributes format.

> Given that there are already multiple interoperable implementations and all
> of the attributes are security related, I see no pressing need to make
> people change running code to satisfy your personal preferences.

 The contents of the design guidelines document reflect the WG consensus
after years of effort and review.  It by *no* means reflects solely my
personal preference, as seems to be implied here.

>  Sorry if
> these attributes were designed to be easy to implement for people writing
> PKM code, rather than RADIUS code.

  There's no need to follow the RADIUS design guidelines, because the
attributes refer to data that interacts with non-RADIUS systems...

  What value, then, is in the design guidelines, WG consensus, or IETF
review?  Can we just over-ride them willy-nilly because a vendor has an
implementation of a spec?

>>   In Section 3.4.  PKM-Cryptosuite-List, can the attribute be longer
>> than 253 bytes?    
> 
> No.  There are exactly 

  This response seems to have been cut off.

>>   Would it be sufficient to require that the Access-Accept contains a
>> Message-Authenticator for integrity protection?
> 
> If you consider MD5 to be "strong integrity protection".

  It appears to be good enough for the rest of RADIUS, at least until
the TLS-based methods are standardized.

> MPPE-Send-Key is broken; I don't see the value in requiring the use of
> broken technology.  There are much better ways to encrypt attributes for
> transmission, in which (once again) the radext WG has shown near zero
> interest.  Maybe it should be a cisco VSA?

  If it's documented, sure.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Jul 2009 09:43:51 +0000
Date: Thu, 23 Jul 2009 11:43:05 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: radext mailing list <[email-masked]>, [email-masked],  [email-masked]
Subject: AD review of draft-zorn-radius-pkmv1-04.txt

Romascanu, Dan (Dan) wrote:
> I have reviewed as shepherding AD draft-zorn-radius-pkmv1-04.txt 

  Following on Dan's review, I've reviewed the document for agreement
with the RADIUS design guidelines document [1]

  Both the PKM-SS-Cert and PKM-CA-Cert attributes provide 'ad-hoc'
extension of the RADIUS attribute size, much like the EAP-Message
attribute.  It would have been preferable to follow the extended
attribute format [2].  This provides a standardized way of carrying data
larger than a 253 bytes.

  However, that document has not yet been published.  My question is
that if there are no current implementations of the PKM specification,
it may be preferable to wait until the extended attributes document is
finished, and then to use that format.

  Section 3.3 defines the PKM-Config-Settings.  This is a "complex
attribute" within the meaning of Section 2.1.3 of the design guidelines
document, which states:

   As a
   result, the introduction of new complex data types within RADIUS
   attribute specifications SHOULD be avoided, except in the case of
   complex attributes involving authentication or security
   functionality.

  I do not see any pressing need to make this attribute carry seven
independent fields.  The RADIUS attribute space has sufficient room to
allocate 7 attributes.  If the extended attribute format is used, then
nearly all space limitations are removed.  I would recommend that these
independent values be split up into independent attributes that follow
the RADIUS data model.

  In Section 3.4.  PKM-Cryptosuite-List, can the attribute be longer
than 253 bytes?    If so, do the same ad-hoc rules as above apply?  The
IEEE specification seems to permit attributes up to 32768 octets in length.

  It would also be good to reference a specific page or section in the
IEEE spec, rather than just referring to the document as a whole.

  Section 3.5.  PKM-SAID, defines an attribute containing 2 octets of
data.  It would be preferable to use a 4-octet type, and to specify that
the upper 2 octets are zero.  This would allow the attribute to fit
within the existing RADIUS data model, as discussed in Section 2.1.1 of
the design guidelines document:

   It is worth noting that since RADIUS only supports unsigned integers
   of 32 or 64 bits, attributes using signed integer data types or
   unsigned integer types of other sizes will require code changes, and
   SHOULD be avoided.

  Section 3.6.  PKM-SA-Descriptor defines another complex attribute as
discussed above.  It would be good to define this as a 64-bit integer,
which would fit within the RADIUS data model.

  Section 3.7.  PKM-AUTH-Key defines a complex attribute for
authentication or security, which fits within the design guidelines.
However, the encryption of the attribute is specified by reference to
[IEEE.802.16-2004].  This encryption is unlike anything previously used
in RADIUS, but it appears to be mandated by the IEEE specificiation.

  It would also be good to reference a specific section of
[IEEE.802.16-2004] for this definition, rather than referencing the
document as a whole.

  I also have some comments on the Security Considerations section:

   If the Access-Accept message is not subject to strong integrity
   protection, an attacker may be able to modify the contents of the
   PKM-Auth-Key Attribute.  For example, the Key field could be replaced
   with a key known to the attacker.

  Would it be sufficient to require that the Access-Accept contains a
Message-Authenticator for integrity protection?

   Although it is necessary for a plaintext copy of the Key field in the
   PKM-AUTH-Key Attribute to be transmitted in the Access-Accept
   message, this document does not define a method for doing so
   securely.

  How is inter-operability to be achieved if there is no specification
for how to carry a necessary field?

  I suggest changing the suggestion to use MS-MPPE-Send-Key into a
mandatory requirement, and making it part of the specification.

  Alan DeKok.

[1] http://tools.ietf.org/html/draft-ietf-radext-design-07
[2] http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-08

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Jul 2009 13:02:09 +0000
Content-class: urn:content-classes:message
Subject: AD review of draft-zorn-radius-pkmv1-04.txt
Date: Wed, 22 Jul 2009 15:01:09 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Glen Zorn" <[email-masked]>
Cc: "radext mailing list" <[email-masked]>

I have reviewed as shepherding AD draft-zorn-radius-pkmv1-04.txt and I
believe that the document is clear and stable. As the document requires
IANA to allocate attributes from the standard RADIUS type space
according to the RFC 5226 "IETF Review" policy, an IETF Last Call is
required. Please consider the comments below together with the other
IETF Last Call comments. 

1. The document makes repeated references to IEEE 802.16-2004. As this
IEEE specification is a 800+ pages document I think that readers and
users of the future RFC would appreciate if more exact references to
sections in IEEE 802/16-2004 are provided. For example in section 3.3
when referring to the IEEE 802.16 "PKM Configuration settings" attribute
the reader should be sent to section 11.9.19 of IEEE 802.16-2004, then
when talking about the "Authorize wait timeout" field section 11.9.19.1
of IEEE 802.16-2004 could be referred, etc. 

2. In the introduction section please take out "(or at least access to)"
- the access to the IEEE 802 document is now free over the Internet and
in fact the references section of this document already provides an URL
for free download. 

3. Section 3.4, first paragraph - s/contains only the 3 octet/contains
only the list of 3 octet/

Regards,

Dan

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 19 Jul 2009 14:21:50 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item
Date: Sun, 19 Jul 2009 07:19:15 -0700

--_9deab5e6-a348-4305-a865-a2fbdf3d7aa1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This

--_9deab5e6-a348-4305-a865-a2fbdf3d7aa1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
This is a reminder of an ongoing call for review of the document "RADIUS attributes for IPv6
Access Networks" for adoption as a RADEXT WG work item.&nbsp; This document is being targeted at Proposed Standard
status. <br>
&nbsp;<br>The document is available for review here:<br><span style="font-size: 10pt; color: rgb(0, 104, 207); font-family: 'Verdana','sans-serif';"><a href="http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access" rel="nofollow"><font color="#0066cc">http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access</font></a></span><br><br>This
call for review will last until August 7, 2009.&nbsp; Please send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.&nbsp; If you have comments on the
document, please also send these to the list in the format described on
the RADEXT WG Issues list:<br><a rel="nofollow" href="http://www.drizzle.com/%7Eaboba/RADEXT/" target="_blank"><font color="#0068cf">http://www.drizzle.com/~aboba/RADEXT/</font></a><br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_9deab5e6-a348-4305-a865-a2fbdf3d7aa1_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 19 Jul 2009 14:21:42 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: REMINDER: RADEXT WG Last Call on Status Server document
Date: Sun, 19 Jul 2009 07:21:31 -0700

--_a8459185-36a0-409d-b33c-16bd94af0087_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a reminder of an ongoing RADEXT WG last call on the Status Server
specification, prior to sending this document on to the IESG for
publication as an Informational RFC.  The document is available for
inspection here:
http://tools.ietf.org/html/draft-ietf-radext-status-server

RADEXT
WG last call will last until August 7, 2009.  Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list (http://www.drizzle.com/~aboba/RADEXT/).  

--_a8459185-36a0-409d-b33c-16bd94af0087_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
This is a reminder of an ongoing RADEXT WG last call on the Status Server
specification, prior to sending this document on to the IESG for
publication as an Informational RFC.&nbsp; The document is available for
inspection here:<br>http://tools.ietf.org/html/draft-ietf-radext-status-server<br><br>RADEXT
WG last call will last until August 7, 2009.&nbsp; Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list (http://www.drizzle.com/~aboba/RADEXT/).&nbsp; <br><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_a8459185-36a0-409d-b33c-16bd94af0087_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 19 Jul 2009 14:20:41 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: REMINDER: RADEXT WG Last call on the RADIUS over TCP document
Date: Sun, 19 Jul 2009 07:20:33 -0700

--_06e668dd-632b-46ef-a027-3c72fcd1606b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a reminder of an ongoing RADEXT WG last call on RADIUS over TCP
specification, prior to sending this document on to the IESG for
publication as an Experimental RFC.  The document is available for
inspection here:

http://tools.ietf.org/html/draft-ietf-radext-tcp-transport

RADEXT
WG last call will last until August 7, 2009.  Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list 
(http://www.drizzle.com/~aboba/RADEXT/).  

--_06e668dd-632b-46ef-a027-3c72fcd1606b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
This is a reminder of an ongoing RADEXT WG last call on RADIUS over TCP
specification, prior to sending this document on to the IESG for
publication as an Experimental RFC.&nbsp; The document is available for
inspection here:<br>
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport<br>
<br>
RADEXT
WG last call will last until August 7, 2009.&nbsp; Please send comments to
the RADEXT WG mailing list using the format described in the RADEXT
Issues list <br>(http://www.drizzle.com/~aboba/RADEXT/).&nbsp; <table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_06e668dd-632b-46ef-a027-3c72fcd1606b_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 19 Jul 2009 14:19:19 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: REMINDER:  Ongoing Call for adoption of RADIUS over DTLS document as a RADEXT WG work item
Date: Sun, 19 Jul 2009 07:18:18 -0700

--_a0ed79fd-a93d-40b3-aee7-2700fa37ce3f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a reminder of the ongoing call for review of the document "DTLS as a Transport Layer
for RADIUS" for adoption as a RADEXT WG work item.  This document is
being targeted at Experimental
status. 

The document is available for review here:
http://tools.ietf.org/html/draft-dekok-radext-dtls

This

--_a0ed79fd-a93d-40b3-aee7-2700fa37ce3f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
This is a reminder of the ongoing call for review of the document "DTLS as a Transport Layer
for RADIUS" for adoption as a RADEXT WG work item.&nbsp; This document is
being targeted at Experimental
status. <br>
&nbsp;<br>The document is available for review here:<br><span style="font-size: 10pt; color: rgb(0, 104, 207); font-family: 'Verdana','sans-serif';"></span>http://tools.ietf.org/html/draft-dekok-radext-dtls<br><br>This
call for review will last until August 7, 2009.&nbsp; Please send email to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.&nbsp; If you have comments on the
document, please also send these to the list in the format described on
the RADEXT WG Issues list:<br><a rel="nofollow" href="http://www.drizzle.com/%7Eaboba/RADEXT/" target="_blank"><font color="#0068cf">http://www.drizzle.com/~aboba/RADEXT/</font></a><br><table style="border-top: 1px solid black; font-weight: bold; font-family: 'Segoe UI',Tahoma,san-serif;"><tbody><tr><td><a href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood" style="font-size: 9pt; color: rgb(1, 132, 203); text-decoration: none;"><span style="padding: 0px 24px; font-size: 8pt; color: rgb(63, 181, 85); text-decoration: underline;"></span></a><br></td></tr></tbody></table></body>
</html>
--_a0ed79fd-a93d-40b3-aee7-2700fa37ce3f_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Jul 2009 10:36:32 +0000
Date: Wed, 15 Jul 2009 11:17:57 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: 'Stefan Winter' <[email-masked]>, [email-masked]
Subject: Re: Crypto-agility requirements:  Compromise of Legacy Shared Secret (from Issue 303)

Bernard Aboba wrote:
> [BA] This makes sense to me.  But beyond that -- the upgrade scenario we had
> discussed involved upgrading the server first.  So assuming that the server
> supports the new crypto-agile functionality, and the RADIUS client has also
> been upgraded, why would the RADIUS client still need to send legacy RADIUS
> packets to the server? It seems like that would only happen if the RADIUS
> client were mis-configured,  or the implementation was broken, no?

  Yes.  While I can see some systems upgrading clients before servers,
this practice should be discouraged.

> That said, there still may be some operational annoyance associated with
> having "old" and "new" RADIUS client configurations on the server,
> effectively doubling the NAS configuration.  It would be nice to be able to
> tie the "old" and "new" clients together somehow, so as to be able to remove
> configuration info on "old" NASes that have long since been upgraded.  But
> this seems like more of an operational hassle than a requirement, I think. 

  Yes.  Most servers already have per-NAS configuration.  I would
suggest something like:

  1) define client by IP, secret (and server-specific stuff)
  2) add TLS data to above client definition (PSK, certs, etc.)
  3) delete IP && secret configuration from client definition

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Jul 2009 14:27:22 +0000
Date: Tue, 14 Jul 2009 16:25:59 +0200
From: Alan DeKok <[email-masked]>
To: Stefan Winter <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: Crypto-agility requirements:  Compromise of Legacy Shared Secret (from Issue 303)

Stefan Winter wrote:
> Let's assume the peer was previously only supporting plain RADIUS, and
> was thus identified by the tuple
> 
> (IP,Shared-secret)
> 
> Now, it gets a firmware upgrade and supports TLS-PSK. It is then
> identified as
> 
> (TLS-PSK-Identity, key)

  Yes and no.  If this configuration *replaces* the previous one, then
there is no problem.  The old configuration is gone, and all packets
must use TLS-PSK with the above identity and key.

  If this configuration is in *addition* to the old one, then the old
one can be automatically deleted once TLS-PSK has been negotiated.

> For the server who receives requests it looks like client
> RADIUS/(IP,Shared-secret) became silent, while there was a new client
> from the same source IP address identifying itself as
> RadSec/(TLS-PSK-Identity, key); TLS-PSK-Identity and the old, configured
> IP are not necessarily identical. How does the server know these two are
> the same logical entity? Having the same source IP address could be due
> to two independent instances of RADIUS software running on the same device.

  Tough.  This is addressed in the DTLS draft: there SHOULD be only one
source of packets from the machine.  If this means running a local
proxy, so be it.

  The ability to accept *both* legacy && TLS authentication from the
same IP is nothing more than a down-bidding attack.  It's wrong, and
should be forbidden.

> One could set TLS-PSK-Identity = IP and Shared-secret = PSK as an
> administrative action.

  Absolutely not!  The legacy shared secret MUST NOT be the same as the
PSK!  Othewise, an attacker could break MD5 to get the shared secret,
and then leverage that to authenticate via "strong" crypto.

  The above configuration needs to be forbidden in *very* strong words.

> Should we define: if ( IP = subjectAltName:IPAddr) && (cert valid and
> from "good" CA) => same logical entity as the previous (IP,shared secret)?

  No.  Tying a certificate to an IP address negates much of the benefit
of using certificates.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Jul 2009 14:23:21 +0000
Date: Mon, 13 Jul 2009 16:22:16 +0200
From: Stefan Winter <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-radext-radsec-05.txt

Hi,

this draft accomodates most of the comments received until now, with two
exceptions

- making the wording TCP-agnostic proved difficult and with the DTLS
content remaining a separate document does not appear to make sense any
more.
- the discussion about profiles for distinguishing clients is still
unresolved (see my earlier message about how to distinguish clients for
an automatic upgrade flagging of RADIUS -> RadSec)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R�seau T�l�informatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Jul 2009 14:17:38 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-radsec-05.txt 
Date: Mon, 13 Jul 2009 07:15:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : TLS encryption for RADIUS over TCP (RadSec)
	Author(s)       : S. Winter, et al.
	Filename        : draft-ietf-radext-radsec-05.txt
	Pages           : 16
	Date            : 2009-07-13

This document specifies security on the transport layer (TLS) for the
RADIUS protocol [RFC2865] when transmitted over TCP
[I-D.dekok-radext-tcp-transport].  This enables dynamic trust
relationships between RADIUS servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-radsec-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Jul 2009 12:39:43 +0000
Date: Mon, 13 Jul 2009 14:39:11 +0200
From: Stefan Winter <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-01.txt

Hello,

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the RADIUS EXTensions Working Group of the IETF.
>
>
> 	Title           : NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS
> 	Author(s)       : S. Winter, M. McCauley
> 	Filename        : draft-ietf-radext-dynamic-discovery-01.txt
> 	Pages           : 8
> 	Date            : 2009-07-13
>   

Changes to -00 are:

- added Applicability section as discussed on the list
- modified algorithm to treat "name resolution library" as an opaque
oracle (as suggested in the IAB draft mentioned recently on the list)
- switched IPR boilerplate: all authors are happy to leave out the
pre5378 disclaimer

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R�seau T�l�informatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Jul 2009 12:31:39 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-dynamic-discovery-01.txt 
Date: Mon, 13 Jul 2009 05:30:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS
	Author(s)       : S. Winter, M. McCauley
	Filename        : draft-ietf-radext-dynamic-discovery-01.txt
	Pages           : 8
	Date            : 2009-07-13

This document specifies a means to find authoritative AAA servers for
a given NAI realm as defined in [RFC4282].  It can be used in
conjunction with RADIUS over TLS and RADIUS over DTLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-dynamic-discovery-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Jul 2009 13:55:02 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: IETF 75 RADEXT WG Agenda, Take four
Date: Fri, 10 Jul 2009 06:54:28 -0700

--_ed0a1c00-e175-4081-b76c-d7dfa24f6433_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/09jul/agenda/radext.txt

--_ed0a1c00-e175-4081-b76c-d7dfa24f6433_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
http://www.ietf.org/proceedings/09jul/agenda/radext.txt<br><br><br><br><table style="border-top: 1px solid black; font-family: 'Segoe UI',Tahoma,san-serif; font-weight: bold;"><tbody><tr><td><a style="color: rgb(1, 132, 203); font-size: 9pt; text-decoration: none;" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><span style="padding: 0px 24px; color: rgb(63, 181, 85); font-size: 8pt; text-decoration: underline;"></span></a></td></tr></tbody></table></body>
</html>
--_ed0a1c00-e175-4081-b76c-d7dfa24f6433_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Jul 2009 13:48:42 +0000
Date: Fri, 10 Jul 2009 15:46:27 +0200
From: Stefan Winter <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: Alan DeKok <[email-masked]>,  Glen Zorn <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Dynamic discovery: applicability questions

Hi,

> While my understanding is that certificates have been used in RADSEC
> deployments,  deploying certificates on NASes for use with RADIUS/DTLS
> could be considerably more difficult. 
> This raises the question of what TLS ciphersuites should be
> recommended/required
> (e.g. PSK for DTLS).

The RadSec document right now includes TLS-PSK, certificates with
fingerprint validation only, and certificates with PKI chain validation.

I share the opinion that deploying a certificate backed by a proper PKI
on a NAS would be too complicated for some deployments. Such deployments
can then use TLS-PSK or deploy a self-signed certificate *once*, and
configure the expected fingerprint on the server side. Using these two
options disables dynamic discovery due to the need for a fixed
configuration, but that is arguably not a priority for a NAS anyway.

However, deploying proper PKI-backed certificates on a NAS can also have
its merits: Alan has mentioned bootstrapping mechanisms before, which
could make use of that. (e.g. the NAS inspects its own certificate on
boot, extracts its domain name from the cert, looks up the RadSec SRV
for the domain name, connects).

> Also, typically NASes are configured with the address of the proxy or
> server, and
> therefore don't need to dynamically discover it.  The situation is a
> bit like default
> route configuration with IPv4.

Exactly. PSK modes are jsut fine for these operation modes. And a more
ambitious bootstrapping can still be done, as it is not prohibited by
the specs.

> So I'm wondering whether this is primarily a concern for proxies
> running RADSEC,
> since those seem the most likely to have a certificate as well as to
> be in need of
> dynamic discovery capability.

Dynamic discovery makes most sense in proxy environments, yes. But one
can imagine other uses.

> With respect to standardization of dynamic discovery, experience with
> SIP (e.g. RFC 3263)
> has been that supporting multiple transports can be the source of
> interoperability problems,
> and that if not carefully specified, dynamic DNS discovery can
> actually make things worse.
>
> For example, I'd suggest that a RADIUS server should probably not use
> dynamic discovery
> to decide how to answer an incoming Request.  This could result in an
> incoming RADSEC
> packet being answered with a RADIUS over DTLS packet.  The logical
> thing to do is for a
> responder (either a RADIUS server or a DAS) to respond with the same
> transport that was
> used in the Request.

Certainly. It was not intended to create "asymetric" routing of messages
on the return path. That is, an incoming Access-Request from a client
will always be responded to using the same channel the request came in.
Only if the server decides to proxy the request elsewhere, dynamic
discovery can be used to determine the proxy destination. This does not
preclude though that a client can send a request using one channel, and
proxying to  a home server can be done on another one. That is

[Access-Request] (client) --DTLS--> (proxy)  --TCP/TLS--> (home server)
[ Access-Accept] (client) <--DTLS-- (proxy)  <--TCP/TLS-- (home server)

is possible (whether the home server was determined dynamically or
statically configured is irrelevant here).

> I'm also not sure whether a DAC should use dynamic discovery to decide
> how to speak
> to a DAS.  In this situation, there is presumably information
> available on the transport used
> by the RADIUS client in the Access-Request.  Wouldn't it make more
> sense for the DAC
> to use that same transport in speaking to the DAS?

Yes. Existing transport relationships with clients should be remembered
for all communication relating to the established user sessions of these
clients.

I will update the draft accordingly to make these things clear.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R�seau T�l�informatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Jul 2009 12:59:33 +0000
Date: Fri, 10 Jul 2009 14:58:52 +0200
From: Stefan Winter <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: Crypto-agility requirements:  Compromise of Legacy Shared Secret (from Issue 303)

Hi,

>   I agree.  This *dual* configuration should be discouraged.  Most of
> the time the peers will be using *either* legacy RADIUS, or a
> crypto-agile solution.  The only time both systems can be used is when
> one peer does not know the other peers capabilities.
>
>   As soon as a peer validates that a crypto-agile solution is supported,
> the legacy RADIUS configuration MUST be disabled or discarded.
>   

While I was working on the profiles to identify a peer in TLS/DTLS, I
started wondering how in practice the above validation of support for a
peer can happen reliably.

Let's assume the peer was previously only supporting plain RADIUS, and
was thus identified by the tuple

(IP,Shared-secret)

Now, it gets a firmware upgrade and supports TLS-PSK. It is then
identified as

(TLS-PSK-Identity, key)

For the server who receives requests it looks like client
RADIUS/(IP,Shared-secret) became silent, while there was a new client
from the same source IP address identifying itself as
RadSec/(TLS-PSK-Identity, key); TLS-PSK-Identity and the old, configured
IP are not necessarily identical. How does the server know these two are
the same logical entity? Having the same source IP address could be due
to two independent instances of RADIUS software running on the same device.

One could set TLS-PSK-Identity = IP and Shared-secret = PSK as an
administrative action. Should we define this as suggested upgrading
path, and subsequently define that under these circumstances, two peers
should be regarded as logically the same?

The same question applied to TLS with certificates and a PKI behind:

Should we define: if ( IP = subjectAltName:IPAddr) && (cert valid and
from "good" CA) => same logical entity as the previous (IP,shared secret)?

The situation looks a bit more dim when considering TLS with
certificates and fingerprints for validation... I don't think any
automatic validation that the same peer is present can happen; in such
cases, manual configuration of the new capabilities of the client is
necessary, i.e. feeding the expected fingerprint into the server
configuration.

Greetings,

Stefan Winter
>   This limits the attack to forcing the peers to continue with RADIUS
> after a crypto-agile solution is available.  This attack is therefore no
> worse than existing RADIUS.
>
>   
>> If the attacker knows the legacy shared secret, and has complete
>> control over the communication channel (and in particular, can drop
>> messages going from A to B), then it seems the attacker will be
>> indistinguishable from a valid peer that supports only the legacy
>> mechanisms (and does not know the new shared secret), and detecting
>> bidding down will not be possible.
>>     
>
>   Yes.
>
>   This attack can be prevented by having an administrator configure the
> peer to *require* a crypto-agile solution.
>
>   Alan DeKok.
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>   

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R�seau T�l�informatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Jul 2009 12:40:30 +0000
Date: Fri, 10 Jul 2009 14:39:59 +0200
From: Stefan Winter <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Issue: RADSEC and DTLS docs

Hi,

>   I'll rev the DTLS document soon.  We can then see how much of it
> simply references radsec.  If the DTLS-specific portions are small, it
> may be good to add them to the radsec document.
>   

Judging from your rev from June, it looks like there are too many
changes to easily merge the two documents. I tried to do it by
mentioning at all the neuralgic points

If (... radsec...) then the following applies; if (...RDTLS...) then the
other thing applies...

but had to do it so often that the text looked really ugly, unreadable,
and might be prone for misinterpretation and decided to quit without saving.

I suggest to keep the DTLS document separate, but have it reference the
relevant portions of the radsec draft (just as section 2 of
draft-dekok-radext-dtls-01 does).

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R�seau T�l�informatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Jul 2009 12:30:45 +0000
Date: Fri, 10 Jul 2009 14:29:32 +0200
From: Stefan Winter <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: [email-masked]
Subject: Re: Issue RADSEC certificate handling

Hi,

> Requested change:
>
> 1. The discussion of TLS cipher suites is broken apart into several
> places in the document, some of them normative and some of them
> informative.  I believe the normative and informative information is
> reversed.  The implementation requirements for supported cipher suites
> should go in this section.
>   

Indeed, some cipher suites were enumerated in the informative section
and only referenced-to from the normative section. This is bad; in the
upcoming -05 draft, they are mentioned in the normative part directly.
Same goes for the optional support of compression.

> 2. When is it acceptable not to validate the SRV entry in the
> certificate? 
>   

When it's there, it should be validated. The reason for my SHOULD was
that an implementation might support TLS, but not the validation of the
SRV extensions in RFC4985. The SHOULD was supposed to express that under
such circumstances, validation doesn't have to happen. But that was
rather clumsy wording; I changed it to

"If service names as per <xref target="RFC4985" /> are present in the
certificate and dynamic discovery utilizing SRVs in DNS is used (see
<xref target="I-D.winter-dynamic-discovery" />) and the TLS
implementation supports evaluation of the extensions in <xref
target="RFC4985" />, the SRV entry MUST be validated."

(and if the implementation does not support RFC4985 then it quite
obviously can't validate the entry, and it is just some opaque
SubjectAltName:otherName for this implementation which will be ignored)
I wonder if the text in parentheses should be in the draft or if that's
superfluous?

> 3. The section should state that matching should be done against locally
> configured names (as opposed to information retrieved from DNS). 
>   

I changed the sentence to

"Peer validation always includes a check on whether the locally
configured expected DNS name or IP address of the server that is
contacted matches its presented certificate."

to make clear that the authoritative trusted information is the local
configuration.

> 4. Is there any particular URI type that would be useful for RADIUS? 
>   

This was discussed in the room last time, IIRC; the conclusion being
that this is a decision of the operators of an infrastructure what
scheme to deploy for validation. So, any type of URI could occur. An
implementation that could check the presented URI against a locally
configured regular expression of expected URIs would be flexible.

As an example, in the eduroam case, we would have a URL designating the
purpose of the server bearing the certificate in the URI field, with a
fixed prefix:

X509v3 Subject Alternative Name:
                URI:https://registry.edugain.org/resolver?urn=urn:geant:eduroam:component:...

(the three dots indicating that everything below that is variable (hence
the suggested regexp matching). In my own concrete example, the national
RADIUS proxy for Luxembourg (operated by RESTENA) contains:

X509v3 Subject Alternative Name:
                URI:https://registry.edugain.org/resolver?urn=urn:geant:eduroam:component:proxy:Europe:RESTENA:FTLR

I'm not sure if there should be more text about this in the draft than
currently is.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R�seau T�l�informatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 09 Jul 2009 21:34:09 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: IETF 75 RADEXT WG Agenda, Take three
Date: Thu, 9 Jul 2009 14:32:58 -0700

--_683f00d8-4fed-4e5d-830a-84924c138c0a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/09jul/agenda/radext.txt

 EMAILING FOR THE LEAST BAD GOOD
Join me
--_683f00d8-4fed-4e5d-830a-84924c138c0a_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<A href="http://www.ietf.org/proceedings/09jul/agenda/radext.txt">http://www.ietf.org/proceedings/09jul/agenda/radext.txt</A><BR><BR><BR>
<TABLE style="FONT-FAMILY: 'Segoe UI',Tahoma,san-serif; BORDER-TOP: black 1px solid; FONT-WEIGHT: bold">
<TBODY>
<TR>
<TD><A style="COLOR: #0184cb; FONT-SIZE: 9pt; TEXT-DECORATION: none" href="http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood"><IMG style="BORDER-BOTTOM-STYLE: none; BORDER-RIGHT-STYLE: none; BORDER-TOP-STYLE: none; BORDER-LEFT-STYLE: none" alt="i'm" src="http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif"> EMAILING FOR THE LEAST BAD GOOD<BR><SPAN style="PADDING-BOTTOM: 0px; PADDING-LEFT: 24px; PADDING-RIGHT: 24px; COLOR: #3fb555; FONT-SIZE: 8pt; TEXT-DECORATION: underline; PADDING-TOP: 0px">Join me</SPAN></A></TD></TR></TBODY></TABLE></body>
</html>
--_683f00d8-4fed-4e5d-830a-84924c138c0a_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Jul 2009 17:35:26 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: IETF 75 RADEXT WG Agenda - Take Two
Date: Wed, 8 Jul 2009 10:34:32 -0700

--_893c481c-ebc3-4875-9fee-aafc669774d5_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

RADEXT WG @ IETF 75
Stockholm, Sweden
 
Friday, July 31, 2009
9:00 � 11:30 AM
Congresshall B 
 
Preliminaries (10 minutes)
 
Bluesheets
Jabber scribe
Minute Takers
Document status
 
Documents completing IETF Last Call (10 minutes)
 
Design Guidelines document, Alan DeKok (10  minutes)
http://tools.ietf.org/html/draft-ietf-radext-design
 
Documents completing WG last call (10 minutes)
 
RADSEC, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec
 
Documents in WG Last Call (20 minutes)
 
Status-Server document, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-status-server
 
RADIUS over TCP document, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-tcp-transport
 
Documents under consideration for adoption as WG work items (30 minutes)
 
RADIUS over DTLS, Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-dekok-radext-dtls
 
NAI-based Peer Discovery, Stefan Winter (10 minutes)
http://tools.ietf.org/html/draft-winter-dynamic-discovery
 
RADIUS attributes for IEEE 802 Networks, Bernard Aboba (10 minutes)
http://tools.ietf.org/html/draft-aboba-radext-wlan

--_893c481c-ebc3-4875-9fee-aafc669774d5_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<P class=MsoNormal>RADEXT WG @ IETF 75<?XML:NAMESPACE PREFIX = O /><O:P></O:P></P>
<P class=MsoNormal>Stockholm, Sweden<O:P></O:P></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal>Friday, July 31, 2009<O:P></O:P></P>
<P class=MsoNormal>9:00 � 11:30 AM</P>
<P class=MsoNormal>Congresshall B&nbsp;</P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal><B>Preliminaries (10 minutes)</B></P>
<P class=MsoNormal><STRONG></STRONG>&nbsp;</P>
<P class=MsoNormal>Bluesheets</P>
<P class=MsoNormal>Jabber scribe<BR>Minute Takers</P>
<P class=MsoNormal>Document status</P>
<P class=MsoNormal><B></B>&nbsp;</P>
<P class=MsoNormal><B>Documents completing IETF Last Call (10 minutes)</B></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal>Design Guidelines document, Alan DeKok (10 &nbsp;minutes)<O:P></O:P></P>
<P class=MsoNormal><A href="http://tools.ietf.org/html/draft-ietf-radext-design" rel=nofollow><FONT color=#0066cc>http://tools.ietf.org/html/draft-ietf-radext-design</FONT></A><O:P></O:P></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal><B>Documents completing WG last call (10 minutes)<O:P></O:P></B></P>
<P class=MsoNormal><B><O:P>&nbsp;</O:P></B></P>
<P class=MsoNormal>RADSEC, Stefan Winter (10 minutes)<O:P></O:P></P>
<P class=MsoNormal><A href="http://tools.ietf.org/html/draft-ietf-radext-radsec" rel=nofollow><FONT color=#0066cc>http://tools.ietf.org/html/draft-ietf-radext-radsec</FONT></A><O:P></O:P></P>
<P class=MsoNormal><B><O:P>&nbsp;</O:P></B></P>
<P class=MsoNormal><B>Documents in WG Last Call (20 minutes)<O:P></O:P></B></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal>Status-Server document, Alan DeKok (10 minutes)<O:P></O:P></P>
<P class=MsoNormal><A href="http://tools.ietf.org/html/draft-ietf-radext-status-server" rel=nofollow><FONT color=#0066cc>http://tools.ietf.org/html/draft-ietf-radext-status-server</FONT></A><O:P></O:P></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal>RADIUS over TCP document, Alan DeKok (10 minutes)<O:P></O:P></P>
<P class=MsoNormal><A href="http://tools.ietf.org/html/draft-ietf-radext-tcp-transport" rel=nofollow><FONT color=#0066cc>http://tools.ietf.org/html/draft-ietf-radext-tcp-transport</FONT></A><O:P></O:P></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal><B>Documents under consideration for adoption as WG work items (30 minutes)<O:P></O:P></B></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal>RADIUS over DTLS, Alan DeKok (10 minutes)<O:P></O:P></P>
<P class=MsoNormal><A href="http://tools.ietf.org/html/draft-dekok-radext-dtls" rel=nofollow><FONT color=#0066cc>http://tools.ietf.org/html/draft-dekok-radext-dtls</FONT></A><O:P></O:P></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal>NAI-based Peer Discovery, Stefan Winter (10 minutes)<O:P></O:P></P>
<P class=MsoNormal><A href="http://tools.ietf.org/html/draft-winter-dynamic-discovery" rel=nofollow><FONT color=#0066cc>http://tools.ietf.org/html/draft-winter-dynamic-discovery</FONT></A><O:P></O:P></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal>RADIUS attributes for IEEE 802 Networks, Bernard Aboba (10 minutes)<O:P></O:P></P>
<P class=MsoNormal><A href="http://tools.ietf.org/html/draft-aboba-radext-wlan" rel=nofollow><FONT color=#0066cc>http://tools.ietf.org/html/draft-aboba-radext-wlan</FONT></A><O:P></O:P></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P>
<P class=MsoNormal><O:P>&nbsp;</O:P></P></body>
</html>
--_893c481c-ebc3-4875-9fee-aafc669774d5_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Jul 2009 08:23:21 +0000
Date: Wed, 08 Jul 2009 10:22:08 +0200
From: Stefan Winter <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: Alan DeKok <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: REMINDER: Call for review of the "NAI-based Peer Discovery" document for acceptance as a RADEXT WG work item

Hello,

> > Sounds good to me. The mangling would be: find first @ in User-Name,
> > chop off behind @, toss remainder to DNS library and hope for an answer.
> > Is that what you had in mind?
>
> It is a bit more complicated than that.  See:
> http://www.ietf.org/internet-drafts/draft-iab-idn-encoding-00.txt

Thanks! An interesting read indeed!

Apart from finally having a black-on-white confirmation that I am na�ve
[or naive?], it showed that

- Alan's recommendation to keep punycode mangling out of the RADIUS
application-layer processing and moving it to "the library" was a step
in the right direction
- my wording in -00 wasn't good enough to fully implement the IAB's
recommendation: it still leaves the question of private (possibly
$ANY_ENCODING) vs. public (ASCII + punycode) namespaces and/or a mixture
of the two (plus /etc/hosts resolution etc...).

I am thinking of modifying the algorithm, purging

"4. Generate R' = ( DNS library transformation of R to an FQDN in punycode)"

and writing

"6.   Using the host's name resolution library, perform a NAPTR query for service "AAAS+RADSECT" for R"

which leaves it to the host configuration in which order, encoding,
postfixing with domain names etc. the conversion is done.

That leaves a bit of space for surprises when the server's library does
different conversions than a client's, but I tend to think that host
software configuration issues are out of the scope of this document.

Does that sound like a way out?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R�seau T�l�informatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Jul 2009 05:59:34 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, Stefan Winter <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: REMINDER: Call for review of the "NAI-based Peer Discovery" document for acceptance as a RADEXT WG work item
Date: Mon, 6 Jul 2009 22:58:20 -0700

--_6b9064f8-e2f2-4c49-b166-4bee2e4ef497_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Stefan Winter wrote:
> Sounds good to me. The mangling would be: find first @ in User-Name,
> chop off behind @, toss remainder to DNS library and hope for an answer.
> Is that what you had in mind?

It is a bit more complicated than that.  See:
http://www.ietf.org/internet-drafts/draft-iab-idn-encoding-00.txt

--_6b9064f8-e2f2-4c49-b166-4bee2e4ef497_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<br>&gt; Stefan Winter wrote:<br>&gt; Sounds good to me. The mangling would be: find first @ in User-Name,<br>&gt; chop off behind @, toss remainder to DNS library and hope for an answer.<br>&gt; Is that what you had in mind?<br><br>It is a bit more complicated than that.&nbsp; See:<br>http://www.ietf.org/internet-drafts/draft-iab-idn-encoding-00.txt<br></body>
</html>
--_6b9064f8-e2f2-4c49-b166-4bee2e4ef497_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Jul 2009 15:35:03 +0000
Date: Mon, 06 Jul 2009 17:34:27 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: Glen Zorn <[email-masked]>,  Stefan Winter <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Dynamic discovery: applicability questions

Bernard Aboba wrote:
> While my understanding is that certificates have been used in RADSEC
> deployments,  deploying certificates on NASes for use with RADIUS/DTLS
> could be considerably more difficult. 

  It depends on how it's done.  Bob Moscowitz && I had a "RADIUS
bootstrap" draft years ago that would have helped.  But there was little
interest at the time.

> Also, typically NASes are configured with the address of the proxy or
> server, and
> therefore don't need to dynamically discover it.  The situation is a bit
> like default
> route configuration with IPv4.

  These addresses change from time to time.  (Months, maybe years).

> For example, I'd suggest that a RADIUS server should probably not use
> dynamic discovery
> to decide how to answer an incoming Request.  This could result in an
> incoming RADSEC
> packet being answered with a RADIUS over DTLS packet.  The logical thing
> to do is for a
> responder (either a RADIUS server or a DAS) to respond with the same
> transport that was
> used in the Request.

  Yes.

> I'm also not sure whether a DAC should use dynamic discovery to decide
> how to speak
> to a DAS.  In this situation, there is presumably information available
> on the transport used
> by the RADIUS client in the Access-Request.  Wouldn't it make more sense
> for the DAC
> to use that same transport in speaking to the DAS?

  Yes.  The RADIUS server should cache IP's for a client, and when
connecting to that client for purposes of dynamic authorization, use
that IP address.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Jul 2009 15:17:29 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, Glen Zorn <[email-masked]>
CC: Stefan Winter <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Dynamic discovery: applicability questions
Date: Mon, 6 Jul 2009 08:16:22 -0700

--_9b694cdd-e376-4d6b-9c5f-1dbce1fe9ac0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Of course, what was I thinking?  Setting up a CA, issuing client and server
> certs and configuring secure DNS is _so_ much simpler than laboriously
> typing an IP address.  This simplicity must explain the amazing popularity
> (indeed, true ubiquity) of the PKI today.  

One of the concerns that Pasi Eronen raised in Issue 303 was credential support. 

I'd suggest that this issue needs to be thought through both with respect to
proxies/servers as well as for NASes. 

While my understanding is that certificates have been used in RADSEC
deployments,  deploying certificates on NASes for use with RADIUS/DTLS
could be considerably more difficult.  

This raises the question of what TLS ciphersuites should be recommended/required 
(e.g. PSK for DTLS). 

Also, typically NASes are configured with the address of the proxy or server, and
therefore don't need to dynamically discover it.  The situation is a bit like default
route configuration with IPv4. 

So I'm wondering whether this is primarily a concern for proxies running RADSEC, 
since those seem the most likely to have a certificate as well as to be in need of
dynamic discovery capability. 

With respect to standardization of dynamic discovery, experience with SIP (e.g. RFC 3263) 
has been that supporting multiple transports can be the source of interoperability problems,
and that if not carefully specified, dynamic DNS discovery can actually make things worse. 

For example, I'd suggest that a RADIUS server should probably not use dynamic discovery
to decide how to answer an incoming Request.  This could result in an incoming RADSEC
packet being answered with a RADIUS over DTLS packet.  The logical thing to do is for a
responder (either a RADIUS server or a DAS) to respond with the same transport that was
used in the Request. 

I'm also not sure whether a DAC should use dynamic discovery to decide how to speak
to a DAS.  In this situation, there is presumably information available on the transport used
by the RADIUS client in the Access-Request.  Wouldn't it make more sense for the DAC
to use that same transport in speaking to the DAS? 

--_9b694cdd-e376-4d6b-9c5f-1dbce1fe9ac0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
&gt; Of course, what was I thinking?  Setting up a CA, issuing client and server<br>&gt; certs and configuring secure DNS is _so_ much simpler than laboriously<br>&gt; typing an IP address.  This simplicity must explain the amazing popularity<br>&gt; (indeed, true ubiquity) of the PKI today.  <br><br>One of the concerns that Pasi Eronen raised in Issue 303 was credential support. <br><br>I'd suggest that this issue needs to be thought through both with respect to<br>proxies/servers as well as for NASes. <br><br>While my understanding is that certificates have been used in RADSEC<br>deployments,&nbsp; deploying certificates on NASes for use with RADIUS/DTLS<br>could be considerably more difficult.&nbsp; <br><br>This raises the question of what TLS ciphersuites should be recommended/required <br>(e.g. PSK for DTLS). <br><br>Also, typically NASes are configured with the address of the proxy or server, and<br>therefore don't need to dynamically discover it.&nbsp; The situation is a bit like default<br>route configuration with IPv4. <br><br>So I'm wondering whether this is primarily a concern for proxies running RADSEC, <br>since those seem the most likely to have a certificate as well as to be in need of<br>dynamic discovery capability. <br><br>With respect to standardization of dynamic discovery, experience with SIP (e.g. RFC 3263) <br>has been that supporting multiple transports can be the source of interoperability problems,<br>and that if not carefully specified, dynamic DNS discovery can actually make things worse. <br><br>For example, I'd suggest that a RADIUS server should probably not use dynamic discovery<br>to decide how to answer an incoming Request.&nbsp; This could result in an incoming RADSEC<br>packet being answered with a RADIUS over DTLS packet.&nbsp; The logical thing to do is for a<br>responder (either a RADIUS server or a DAS) to respond with the same transport that was<br>used in the Request. <br><br>I'm also not sure whether a DAC should use dynamic discovery to decide how to speak<br>to a DAS.&nbsp; In this situation, there is presumably information available on the transport used<br>by the RADIUS client in the Access-Request.&nbsp; Wouldn't it make more sense for the DAC<br>to use that same transport in speaking to the DAS? <br><br></body>
</html>
--_9b694cdd-e376-4d6b-9c5f-1dbce1fe9ac0_--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Jul 2009 11:44:46 +0000
Date: Mon, 06 Jul 2009 13:44:01 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Stefan Winter' <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt

Glen Zorn wrote:
> Of course, what was I thinking?  Setting up a CA, issuing client and server
> certs and configuring secure DNS is _so_ much simpler than laboriously
> typing an IP address.  This simplicity must explain the amazing popularity
> (indeed, true ubiquity) of the PKI today.  

  It's done for EAP methods.

  And the choice is up to the operational people.  Doing certs for
client/server authentication is a higher up-front cost than IP/secret.
However, the ongoing maintenance costs can be lower.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Jul 2009 10:36:26 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'Stefan Winter'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt
Date: Mon, 6 Jul 2009 17:31:15 +0700

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > Inside of a trusted network?  Isn't this, then, a configuration
> issue,
> > rather than a standards issue?
> 
>   If it's *only* inside of a trusted network, yes.  But there are
> interests outside of that usage.  e.g. Eduroam, and other roaming
> operators.
> 
> > Maybe you could explain those benefits (and why they were not
> exploited by
> > the folks deploying Diameter).
> 
>   Because the deployments of Diameter and RADIUS are largely
> orthogonal.
>  They have different use-cases, and therefore different needs.
> 
> >  The only real benefit I can see is in the
> > case where a new server is added to the network or the IP address of
> an old
> > one is changed (surely a rather rare occurrence).  Are there others?
> 
>   I'm spending a fair bit of time helping people migrate RADIUS servers
> from one IP (and version of software) to another.  So while it may seem
> fairly rare, many people see the benefit of an automatic discovery
> method.

Of course, what was I thinking?  Setting up a CA, issuing client and server
certs and configuring secure DNS is _so_ much simpler than laboriously
typing an IP address.  This simplicity must explain the amazing popularity
(indeed, true ubiquity) of the PKI today.  

>   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Jul 2009 09:09:03 +0000
Date: Mon, 06 Jul 2009 11:08:38 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Stefan Winter' <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt

Glen Zorn wrote:
> Inside of a trusted network?  Isn't this, then, a configuration issue,
> rather than a standards issue?

  If it's *only* inside of a trusted network, yes.  But there are
interests outside of that usage.  e.g. Eduroam, and other roaming operators.

> Maybe you could explain those benefits (and why they were not exploited by
> the folks deploying Diameter).

  Because the deployments of Diameter and RADIUS are largely orthogonal.
 They have different use-cases, and therefore different needs.

>  The only real benefit I can see is in the
> case where a new server is added to the network or the IP address of an old
> one is changed (surely a rather rare occurrence).  Are there others?

  I'm spending a fair bit of time helping people migrate RADIUS servers
from one IP (and version of software) to another.  So while it may seem
fairly rare, many people see the benefit of an automatic discovery method.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Jul 2009 09:02:28 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'Stefan Winter'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt
Date: Mon, 6 Jul 2009 15:57:18 +0700

Alan DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
> > Just out of curiosity, why are we doing this?  In the revision of RFC
> 3588,
> > the dime WG has pretty much removed this capability because it was
> used by,
> > well, no one.  If it actually used by EDU Roam, that's fine, but does
> it
> > need to be standardized?
> 
>   I believe so.  There is interest in using this process inside of a
> trusted network.

Inside of a trusted network?  Isn't this, then, a configuration issue,
rather than a standards issue?

> 
>   e.g. An enterprise would configure NASes with CA && client
> certificates.  The NAS would use DNS to discover the server, and then
> use SSL to communicate with it.
> 
>   This has obvious benefits for operational networks.

Maybe you could explain those benefits (and why they were not exploited by
the folks deploying Diameter).  The only real benefit I can see is in the
case where a new server is added to the network or the IP address of an old
one is changed (surely a rather rare occurrence).  Are there others?

>   Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Jul 2009 08:12:45 +0000
Date: Mon, 06 Jul 2009 10:11:57 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Stefan Winter' <[email-masked]>, [email-masked]
Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt

Glen Zorn wrote:
> Just out of curiosity, why are we doing this?  In the revision of RFC 3588,
> the dime WG has pretty much removed this capability because it was used by,
> well, no one.  If it actually used by EDU Roam, that's fine, but does it
> need to be standardized?

  I believe so.  There is interest in using this process inside of a
trusted network.

  e.g. An enterprise would configure NASes with CA && client
certificates.  The NAS would use DNS to discover the server, and then
use SSL to communicate with it.

  This has obvious benefits for operational networks.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Jul 2009 06:46:24 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Stefan Winter'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt
Date: Mon, 6 Jul 2009 13:41:20 +0700

Stefan Winter [mailto://[email-masked]] writes:

> Hi,
> 
> >   My $0.02, as suggested in earlier emails:
> >
> > ...
> >    The discovery process is always susceptible to bidding down
> attacks
> >    if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as
> well
> >    as for RADIUS/TLS and/or RADIUS/DTLS.
> > ...
> >
> >   This discover should be *forbidden* for RADIUS/UDP and RADIUS/TCP.
> >
> >   The only consumer of this dynamic discovery right now is RadSec.
> So
> > forbidding RADIUS/UDP and RADIUS/TCP from using this method has no
> > impact on existing systems.
> >
> 
> I agree. I didn't put anything to that effect into the draft because it
> got discussion (and IIRC some support) from others in the room last
> time. I'm happy to restrict discovery to TLS-based methods (i.e. DTLS
> and TLS) if nobody objects.

Just out of curiosity, why are we doing this?  In the revision of RFC 3588,
the dime WG has pretty much removed this capability because it was used by,
well, no one.  If it actually used by EDU Roam, that's fine, but does it
need to be standardized?

> 
> Greetings,
> 
> Stefan Winter
> 
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R�seau T�l�informatique de l'Education Nationale et
> de la Recherche
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> 
> Tel: +352 424409 1
> Fax: +352 422473
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Jul 2009 05:37:02 +0000
Date: Mon, 06 Jul 2009 07:35:51 +0200
From: Stefan Winter <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: [email-masked]
Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt

Hi,

>   My $0.02, as suggested in earlier emails:
>
> ...
>    The discovery process is always susceptible to bidding down attacks
>    if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as well
>    as for RADIUS/TLS and/or RADIUS/DTLS.
> ...
>
>   This discover should be *forbidden* for RADIUS/UDP and RADIUS/TCP.
>
>   The only consumer of this dynamic discovery right now is RadSec.  So
> forbidding RADIUS/UDP and RADIUS/TCP from using this method has no
> impact on existing systems.
>   

I agree. I didn't put anything to that effect into the draft because it
got discussion (and IIRC some support) from others in the room last
time. I'm happy to restrict discovery to TLS-based methods (i.e. DTLS
and TLS) if nobody objects.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R�seau T�l�informatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 03 Jul 2009 16:30:00 +0000
Date: Fri, 03 Jul 2009 18:29:30 +0200
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt

[email-masked] wrote:
> 	Title           : NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS
> 	Author(s)       : S. Winter, M. McCauley
> 	Filename        : draft-ietf-radext-dynamic-discovery-00.txt

  My $0.02, as suggested in earlier emails:

...
   The discovery process is always susceptible to bidding down attacks
   if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as well
   as for RADIUS/TLS and/or RADIUS/DTLS.
...

  This discover should be *forbidden* for RADIUS/UDP and RADIUS/TCP.

  The only consumer of this dynamic discovery right now is RadSec.  So
forbidding RADIUS/UDP and RADIUS/TCP from using this method has no
impact on existing systems.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 03 Jul 2009 16:16:36 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-dynamic-discovery-00.txt 
Date: Fri,  3 Jul 2009 09:15:01 -0700 (PDT)

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS
	Author(s)       : S. Winter, M. McCauley
	Filename        : draft-ietf-radext-dynamic-discovery-00.txt
	Pages           : 7
	Date            : 2009-07-02

This document specifies a means to find authoritative AAA servers for
a given NAI realm as defined in [RFC4282].  It can be used in
conjunction with RADIUS over TLS and RADIUS over DTLS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-radext-dynamic-discovery-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>