Re: REMINDER: Call for review of the "NAI-based Peer Discovery" document for acceptance as a RADEXT WG work item

[Alan DeKok <[e-mail]>]

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?

  Yes.

>> Section 3 talks about bidding down attacks.  These attacks can be
>> largely mitigated by additional per-client configuration on the server.
>>  See the DTLS document for discussion of this topic.
> 
> Hmm... The whole purpose of dynamic discovery is that the need for
> per-client config becomes obsolete.

  Yes.  If the server determines "known" clients based on SSL
certificate, then we would require that it use RadSec / DTLS.  The issue
here is *only* for existing, IP-based clients.

> I agree that pinpointing individual
> clients to a desired transport would mitigate the bidding-down. But the
> number of clients is not necessarily known beforehand. I would be
> delighted if we'd find a solution for the generic case. But my head is
> not overflowing of ideas to that end, honestly.

  The server already tracks IP, secret, and maybe a few other things for
existing clients.  Adding one more piece of information isn't hard.

  When all existing clients have been upgraded to using RadSec / DTLS,
then I think that all client-based configuration could be removed.  The
server could then simply use TLS-based methods to verify client identity.

  Alan DeKok.

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

Envelope-to: [e-mail]
Delivery-date: Mon, 29 Jun 2009 12:38:25 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 Jun 2009 14:37:20 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Stefan Winter <[e-mail]>
CC: Bernard Aboba <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: REMINDER: Call for review of the "NAI-based Peer Discovery" document for acceptance as a RADEXT WG work item
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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?

  Yes.

>> Section 3 talks about bidding down attacks.  These attacks can be
>> largely mitigated by additional per-client configuration on the server.
>>  See the DTLS document for discussion of this topic.
> 
> Hmm... The whole purpose of dynamic discovery is that the need for
> per-client config becomes obsolete.

  Yes.  If the server determines "known" clients based on SSL
certificate, then we would require that it use RadSec / DTLS.  The issue
here is *only* for existing, IP-based clients.

> I agree that pinpointing individual
> clients to a desired transport would mitigate the bidding-down. But the
> number of clients is not necessarily known beforehand. I would be
> delighted if we'd find a solution for the generic case. But my head is
> not overflowing of ideas to that end, honestly.

  The server already tracks IP, secret, and maybe a few other things for
existing clients.  Adding one more piece of information isn't hard.

  When all existing clients have been upgraded to using RadSec / DTLS,
then I think that all client-based configuration could be removed.  The
server could then simply use TLS-based methods to verify client identity.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 29 Jun 2009 12:28:49 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 Jun 2009 14:27:18 +0200
From: Stefan Winter <[e-mail]>
User-Agent: Thunderbird 2.0.0.19 (X11/20081227)
MIME-Version: 1.0
To: Alan DeKok <[e-mail]>
CC: Bernard Aboba <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: REMINDER: Call for review of the "NAI-based Peer Discovery" document for acceptance as a RADEXT WG work item
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hello,

sorry for the late reply, inline.

> Section 2.2: says:
>
>    For a given NAI-based input realm,
>
> NAI is... ?  The document doesn't define this term, and doesn't
> reference RFC 4282 (NAI definition).
>   

I will issue a new draft soon and will include the reference.

>    ...
>    the following algorithm is used to
>    determine the AAA server to contact:
>
>    1.   Transform input realm into punycode.
>    ...
>
>  This recommendation is correct for DNS, but is problematic in practice.
>  The recommendations in RFC 4282 define how the above transformation is
> done.  *BUT* those recommendations have serious problems.
>
>   Would it be possible to simply rely on the DNS library to do the
> correct conversion, and name resolution?  This document could then
> describe how to mangle the NAI as a string, and that string then gets
> passed to the DNS library for additional punycode mangling, and finally
> lookup.
>   

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?

> Section 3 talks about bidding down attacks.  These attacks can be
> largely mitigated by additional per-client configuration on the server.
>  See the DTLS document for discussion of this topic.
>   

Hmm... The whole purpose of dynamic discovery is that the need for
per-client config becomes obsolete. I agree that pinpointing individual
clients to a desired transport would mitigate the bidding-down. But the
number of clients is not necessarily known beforehand. I would be
delighted if we'd find a solution for the generic case. But my head is
not overflowing of ideas to that end, honestly.

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: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Mon, 29 Jun 2009 10:01:38 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 Jun 2009 12:00:42 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Crypto-agility requirements: Backward Compatibility (from Issue 303)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> The intent of this paragraph is probably right, but currently, it's
> somewhat open to multiple interpretations. Would something like this
> capture the intent?

  That looks good to me.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 29 Jun 2009 10:01:30 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 Jun 2009 12:00:39 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Crypto-agility requirements:  Compromise of Legacy Shared Secret (from Issue 303)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> It seems to assume that for this particular peer, the administrator
> has configured two different shared secrets (one for the current
> security mechanisms, another for the new ones), but has not configured
> whether to use the old or new mechanisms (with this particular peer),
> and instead, that is negotiated somehow.

  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.

  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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 29 Jun 2009 09:05:47 +0000
From: "Abhishek Tiwari (NETWORKING)" <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Mon, 29 Jun 2009 17:04:47 +0800
Subject: RE: Review of draft-tiwari-radext-tunnel-type-02.txt
Thread-Topic: Review of draft-tiwari-radext-tunnel-type-02.txt
Thread-Index: Acmm7zXcIhfSbtH7Qx6NTP5oVYWjmhRqQQRQ
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_096B0C4733FD5647A3B6768792A59DF9B81E4AF013AAEXMSGC425so_"
MIME-Version: 1.0

--_000_096B0C4733FD5647A3B6768792A59DF9B81E4AF013AAEXMSGC425so_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello David,

Last I know that this document is approved for advancement but as of now it=
 has not advanced. Can you please let me know latest status or reason for n=
ot advancement? Let me know if nny information required from my side?

Thanks,
Abhishek

From: Abhishek Tiwari
Sent: Tuesday, March 17, 2009 4:28 PM
To: [e-mail]; '[e-mail]'
Subject: Review of draft-tiwari-radext-tunnel-type-02.txt

Hi David,

Can you please let me know the latest status on this document? WG last call=
 completed on December 15th, 2008 but nothing has changed since then. Let m=
e know if you need some information from my side.

Thanks,
Abhishek


-----Original Message-----

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of David B. Nelson

Sent: Tuesday, September 09, 2008 10:52 PM

To: [e-mail]

Subject: Review of draft-tiwari-radext-tunnel-type-02.txt



This is call for the RADEXT WG to review the I-D

draft-tiwari-radext-tunnel-type-02.txt, which assigns new values of the

RADIUS Tunnel-Type Attribute.



After a discussion among the draft author, our esteemed Area Director and

the WG Co-Chairs, it was decided that review of this document in RADEXT was

appropriate and that, if the WG concurred, we would make it a WG item and

forward it to the IESG to determine IETF Consensus.



This document is now in RADEXT WG Pre-WG Review.



Please review this very short (5 pages) draft located at:

http://www.ietf.org/internet-drafts/draft-tiwari-radext-tunnel-type-02.txt



Please send a message to the RADEXT list indicating:



(1) Should this document be taken on as RADEXT WG work item?



(2) Are the technical or editorial issues with this document?



The comment period will last until October 5, 2008.



Regards,



Dave


--_000_096B0C4733FD5647A3B6768792A59DF9B81E4AF013AAEXMSGC425so_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Hello David,<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Last I know that this do=
cument
is approved for advancement but as of now it has not advanced. Can you plea=
se
let me know latest status or reason for not advancement? Let me know if nny=
 information
required from my side? <o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Thanks,<o:p></o:p></span=
></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'>Abhishek<o:p></o:p></spa=
n></p>

<p class=3DMsoNormal><span style=3D'color:#1F497D'><o:p>&nbsp;</o:p></span>=
</p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Abhishek Tiwa=
ri <br>
<b>Sent:</b> Tuesday, March 17, 2009 4:28 PM<br>
<b>To:</b> [e-mail]; '[e-mail]'<br>
<b>Subject:</b> Review of draft-tiwari-radext-tunnel-type-02.txt<o:p></o:p>=
</span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div style=3D'border:none;border-bottom:double windowtext 2.25pt;padding:0i=
n 0in 1.0pt 0in'>

<p class=3DMsoNormal>Hi David,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Can you please let me know the latest status on this
document? WG last call completed on December 15<sup>th</sup>, 2008 but noth=
ing
has changed since then. Let me know if you need some information from my si=
de.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thanks,<o:p></o:p></p>

<p class=3DMsoNormal>Abhishek<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<pre>-----Original Message-----<o:p></o:p></pre><pre>From: owner-radiusext@=
ops.ietf.org [<a
href=3D"mailto:[e-mail]">mailto:[e-mail]=
f.org</a>] On Behalf Of David B. Nelson<o:p></o:p></pre><pre>Sent: Tuesday,=
 September 09, 2008 10:52 PM<o:p></o:p></pre><pre>To: [e-mail]=
g<o:p></o:p></pre><pre>Subject: Review of draft-tiwari-radext-tunnel-type-0=
2.txt<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>This is call for the=
 RADEXT WG to review the I-D<o:p></o:p></pre><pre>draft-tiwari-radext-tunne=
l-type-02.txt, which assigns new values of the<o:p></o:p></pre><pre>RADIUS =
Tunnel-Type Attribute.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Aft=
er a discussion among the draft author, our esteemed Area Director and<o:p>=
</o:p></pre><pre>the WG Co-Chairs, it was decided that review of this docum=
ent in RADEXT was<o:p></o:p></pre><pre>appropriate and that, if the WG conc=
urred, we would make it a WG item and<o:p></o:p></pre><pre>forward it to th=
e IESG to determine IETF Consensus.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p><=
/pre><pre>This document is now in RADEXT WG Pre-WG Review.<o:p></o:p></pre>=
<pre><o:p>&nbsp;</o:p></pre><pre>Please review this very short (5 pages) dr=
aft located at:<o:p></o:p></pre><pre><a
href=3D"http://www.ietf.org/internet-drafts/draft-tiwari-radext-tunnel-type=
-02.txt">http://www.ietf.org/internet-drafts/draft-tiwari-radext-tunnel-typ=
e-02.txt</a><o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Please send a=
 message to the RADEXT list indicating:<o:p></o:p></pre><pre><o:p>&nbsp;</o=
:p></pre><pre>(1) Should this document be taken on as RADEXT WG work item?<=
o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>(2) Are the technical or e=
ditorial issues with this document?<o:p></o:p></pre><pre><o:p>&nbsp;</o:p><=
/pre><pre>The comment period will last until October 5, 2008.<o:p></o:p></p=
re><pre><o:p>&nbsp;</o:p></pre><pre>Regards,<o:p></o:p></pre><pre><o:p>&nbs=
p;</o:p></pre><pre>Dave<o:p></o:p></pre>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_096B0C4733FD5647A3B6768792A59DF9B81E4AF013AAEXMSGC425so_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 29 Jun 2009 06:38:01 +0000
Message-ID: <[e-mail]>
Date: Mon, 29 Jun 2009 08:36:50 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Extended Attributes and Diameter Compatibility
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> b. Status of RFC 4005bis in DIME.  David Mitton's original proposal for
> enabling translation of *any* RADIUS VSA to Diameter is not currently on
> the (revised) DIME WG charter.  It is not clear that there is interest
> within DIME to pursue this.

  Not being a Diameter person, I would prefer (c), followed by (b).

> c. Need for RADIUS/Diameter translation.  While RADEXT WG documents need
> a Diameter considerations section, and so far this section has typically
> relied on translation, it is not clear whether translation really makes
> sense.  Few deployments appear to make use of this currently.  If RADIUS
> support is needed, then a "dual stack" approach can be taken -- run both
> a RADIUS and a Diameter server against a common backend database.  So is
> there really a need to support RAIDUS attributes within Diameter itself? 

  My discussions with people indicate that the in-use cases for Diameter
and RADIUS are very different, and have little overlap.  This indicates
to me that (c) is the current, and likely best approach.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:37:38 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_d818e426-cc0a-4989-8aff-23c0627873d6_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Crypto-agility requirements: Operational Model (from Issue 303)
Date: Sun, 28 Jun 2009 14:37:17 -0700
MIME-Version: 1.0

--_d818e426-cc0a-4989-8aff-23c0627873d6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


One approach to addressing this issue would be to refer to the Design Guide=
lines document (which also touches on discussion of changes to the Operatio=
nal Model).=20




From: [e-mail]
To: [e-mail]
Subject: Crypto-agility requirements: Operational Model (from Issue 303)
Date: Sun=2C 28 Jun 2009 14:05:54 -0700









In Issue 303=2C Pasi Eronen said:

""Operational model"?

Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes
to the RADIUS operational model=2C such as the introduction of new
commands or maintenance of [additional] state on the RADIUS server."

I'm not sure what "operational" means here -- at first I thought it
might mean "operations and management" (so the requirement would be
basically "SHOULD not complicate life for administrators")=2C but the
two examples given don't seem to fit that very well. And it seems any
solution that e.g. derives fresh session keys will involve some small
(but greater than zero) amount of additional state on clients and
servers.

If the intent was really operations and management=2C perhaps the should
be rephased something like "When using long-term shared secrets for
authentication=2C crypto-agility solutions SHOULD NOT require more
operations and management work than the current solutions."
"




 EMAILING FOR THE GREATER GOOD
Join me=

--_d818e426-cc0a-4989-8aff-23c0627873d6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
One approach to addressing this issue would be to refer to the Design Guide=
lines document (which also touches on discussion of changes to the Operatio=
nal Model). <br><br><table style=3D"border-top: 1px solid black=3B font-wei=
ght: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><t=
d><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_Greate=
rGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decor=
ation: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color=
: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><br></t=
d></tr></tbody></table><br><br><hr id=3D"stopSpelling">From: bernard_aboba@=
hotmail.com<br>To: [e-mail]<br>Subject: Crypto-agility requir=
ements: Operational Model (from Issue 303)<br>Date: Sun=2C 28 Jun 2009 14:0=
5:54 -0700<br><br>



<style>
.ExternalClass .EC_hmmessage P
{padding:0px=3B}
.ExternalClass body.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>


<br>In Issue 303=2C Pasi Eronen said:<br><br>"<pre>"Operational model"?<br>=
<br>Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes<b=
r>to the RADIUS operational model=2C such as the introduction of new<br>com=
mands or maintenance of [additional] state on the RADIUS server."<br><br>I'=
m not sure what "operational" means here -- at first I thought it<br>might =
mean "operations and management" (so the requirement would be<br>basically =
"SHOULD not complicate life for administrators")=2C but the<br>two examples=
 given don't seem to fit that very well. And it seems any<br>solution that =
e.g. derives fresh session keys will involve some small<br>(but greater tha=
n zero) amount of additional state on clients and<br>servers.<br><br>If the=
 intent was really operations and management=2C perhaps the should<br>be re=
phased something like "When using long-term shared secrets for<br>authentic=
ation=2C crypto-agility solutions SHOULD NOT require more<br>operations and=
 management work than the current solutions."<br></pre>"<br><br><br><br><br=
><table style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-f=
amily: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http:/=
/im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"fon=
t-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><im=
g style=3D"border-style: none=3B" src=3D"http://gfx1.hotmail.com/mail/w3/lt=
r/i_charity.gif" alt=3D"i'm"> EMAILING FOR THE GREATER GOOD<br><span style=
=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B t=
ext-decoration: underline=3B">Join me</span></a></td></tr></tbody></table><=
/body>
</html>=

--_d818e426-cc0a-4989-8aff-23c0627873d6_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:36:56 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_5c141c1f-3247-49c6-9829-582b3124c7c3_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Crypto-agility requirements:  RADIUS service (from Issue 303)
Date: Sun, 28 Jun 2009 14:36:35 -0700
MIME-Version: 1.0

--_5c141c1f-3247-49c6-9829-582b3124c7c3_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


One proposal for fixing this would be to change "definition of new RADIUS s=
ervices" to "definition of new values of the Service-Type attribute". =20



From: [e-mail]
To: [e-mail]
Subject: Crypto-agility requirements:  RADIUS service (from Issue 303)
Date: Sun=2C 28 Jun 2009 14:06:54 -0700








In Issue 303=2C Pasi Eronen said:

""RADIUS service?"

Section 4.3 says "For example=2C proposals SHOULD NOT [..] include
definition of new RADIUS services."

What's a RADIUS service -- i.e. what types of proposals this
definition would disqualify? (In RFC 2865=2C "service" is defined as the
service provided by the NAS to the user=2C but that definition doesn't
seem applicable here.)"





--_5c141c1f-3247-49c6-9829-582b3124c7c3_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
One proposal for fixing this would be to change "definition of new RADIUS s=
ervices" to "definition of new values of the Service-Type attribute".&nbsp=
=3B <br><table style=3D"border-top: 1px solid black=3B font-weight: bold=3B=
 font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D=
"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=
=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=
=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C=
 181=2C 85)=3B text-decoration: underline=3B"></span></a><br></td></tr></tb=
ody></table><br><br><hr id=3D"stopSpelling">From: [e-mail]=
<br>To: [e-mail]<br>Subject: Crypto-agility requirements:  RA=
DIUS service (from Issue 303)<br>Date: Sun=2C 28 Jun 2009 14:06:54 -0700<br=
><br>



<style>
.ExternalClass .EC_hmmessage P
{padding:0px=3B}
.ExternalClass body.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>


In Issue 303=2C Pasi Eronen said:<br><br>"<pre>"RADIUS service?"<br><br>Sec=
tion 4.3 says "For example=2C proposals SHOULD NOT [..] include<br>definiti=
on of new RADIUS services."<br><br>What's a RADIUS service -- i.e. what typ=
es of proposals this<br>definition would disqualify? (In RFC 2865=2C "servi=
ce" is defined as the<br>service provided by the NAS to the user=2C but tha=
t definition doesn't<br>seem applicable here.)</pre>"<br><br><br><br><table=
 style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: =
'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.liv=
e.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size:=
 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span styl=
e=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B =
text-decoration: underline=3B"></span></a><br></td></tr></tbody></table></b=
ody>
</html>=

--_5c141c1f-3247-49c6-9829-582b3124c7c3_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:36:04 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_f8e21519-8e49-4ff3-9759-aafb56be0657_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Crypto-agility requirements: Backward Compatibility (from Issue 303)
Date: Sun, 28 Jun 2009 14:35:45 -0700
MIME-Version: 1.0

--_f8e21519-8e49-4ff3-9759-aafb56be0657_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Pasi's suggested text seems reasonable to me.  Anyone object to making the =
suggested change?=20

From: [e-mail]
To: [e-mail]
Subject: Crypto-agility requirements: Backward Compatibility (from Issue 30=
3)
Date: Sun=2C 28 Jun 2009 14:04:56 -0700









In Issue 303=2C Pasi Eronen said:

"Backward compatibility/negotiation:

Section 4.3 says "Solutions to the problem MUST demonstrate backward
compatibility with existing RADIUS implementations.  That is=2C a
crypto-agility solution needs to be able to send packets that a legacy
RADIUS client or server will receive and process successfully.
Similarly=2C a crypto-agility solution needs to be capable of receiving
and processing packets from a legacy RADIUS client or server."

The intent of this paragraph is probably right=2C but currently=2C it's
somewhat open to multiple interpretations. Would something like this
capture the intent?

"Solutions to the problem MUST demonstrate backward compatibility with
existing RADIUS implementations.  That is=2C an implementation that
supports both the crypto-agility solution and legacy mechanisms MUST
be able to talk with legacy RADIUS clients and servers (using the
legacy mechanisms). Acceptable solutions to determining which set of
mechanisms is used (with a particular peer) include some kind of
negotiation=2C and manual configuration."

Note that *not* meeting this requirement would actually be quite
difficult... if the intent of this paragraph was to require some kind
of negotiation (interpreted loosely -- anything more automatic than
manual configuration)=2C the text should say so.

"




 EMAILING FOR THE GREATER GOOD
Join me=

--_f8e21519-8e49-4ff3-9759-aafb56be0657_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Pasi's suggested text seems reasonable to me.&nbsp=3B Anyone object to maki=
ng the suggested change? <br><br><hr id=3D"stopSpelling">From: bernard_abob=
[e-mail]<br>To: [e-mail]<br>Subject: Crypto-agility requ=
irements: Backward Compatibility (from Issue 303)<br>Date: Sun=2C 28 Jun 20=
09 14:04:56 -0700<br><br>



<style>
.ExternalClass .EC_hmmessage P
{padding:0px=3B}
.ExternalClass body.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>


<br>In Issue 303=2C Pasi Eronen said:<br><br>"<pre>Backward compatibility/n=
egotiation:<br><br>Section 4.3 says "Solutions to the problem MUST demonstr=
ate backward<br>compatibility with existing RADIUS implementations.  That i=
s=2C a<br>crypto-agility solution needs to be able to send packets that a l=
egacy<br>RADIUS client or server will receive and process successfully.<br>=
Similarly=2C a crypto-agility solution needs to be capable of receiving<br>=
and processing packets from a legacy RADIUS client or server."<br><br>The i=
ntent of this paragraph is probably right=2C but currently=2C it's<br>somew=
hat open to multiple interpretations. Would something like this<br>capture =
the intent?<br><br>"Solutions to the problem MUST demonstrate backward comp=
atibility with<br>existing RADIUS implementations.  That is=2C an implement=
ation that<br>supports both the crypto-agility solution and legacy mechanis=
ms MUST<br>be able to talk with legacy RADIUS clients and servers (using th=
e<br>legacy mechanisms). Acceptable solutions to determining which set of<b=
r>mechanisms is used (with a particular peer) include some kind of<br>negot=
iation=2C and manual configuration."<br><br>Note that *not* meeting this re=
quirement would actually be quite<br>difficult... if the intent of this par=
agraph was to require some kind<br>of negotiation (interpreted loosely -- a=
nything more automatic than<br>manual configuration)=2C the text should say=
 so.<br><br></pre>"<br><br><br><br><br><table style=3D"border-top: 1px soli=
d black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-seri=
f=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?sourc=
e=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C=
 203)=3B text-decoration: none=3B"><img style=3D"border-style: none=3B" src=
=3D"http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt=3D"i'm"> EMAILIN=
G FOR THE GREATER GOOD<br><span style=3D"padding: 0px 24px=3B font-size: 8p=
t=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B">Join me<=
/span></a></td></tr></tbody></table></body>
</html>=

--_f8e21519-8e49-4ff3-9759-aafb56be0657_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:34:58 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_ef7ea29f-b2cb-4a67-b0cb-084bd1fa829e_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Crypto-agility requirements:  Compromise of Legacy Shared Secret (from Issue 303)
Date: Sun, 28 Jun 2009 14:34:37 -0700
MIME-Version: 1.0

--_ef7ea29f-b2cb-4a67-b0cb-084bd1fa829e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Pasi seems to be making a valid point here.=20

Once MD5 is compromised=2C it will not be possible to avoid bidding down or=
 other attacks.=20

A proposal is to state explicitly that protection against bidding down is o=
nly possible prior to MD5 compromise.  After that=2C the only protection is=
 requiring use of improved algorithms=2C by policy.=20


From: [e-mail]
To: [e-mail]
Subject: Crypto-agility requirements:  Compromise of Legacy Shared Secret (=
from Issue 303)
Date: Sun=2C 28 Jun 2009 14:04:02 -0700









In Issue 303=2C Pasi Eronen said:

"Compromise of legacy shared secret:

Section 4.2 says "Crypto-agility solutions MUST avoid security
compromise=2C even in situations where the existing cryptographic
algorithms utilized by RADIUS implementations are shown to be weak
enough to provide little or no security (e.g. in event of compromise
of the legacy RADIUS shared secret).  Included in this would be
protection against bidding down attacks."

If interpreted literally=2C this requirement could be very difficult
to meet (perhaps impossible).

It seems to assume that for this particular peer=2C the administrator
has configured two different shared secrets (one for the current
security mechanisms=2C another for the new ones)=2C but has not configured
whether to use the old or new mechanisms (with this particular peer)=2C
and instead=2C that is negotiated somehow.

If the attacker knows the legacy shared secret=2C and has complete
control over the communication channel (and in particular=2C can drop
messages going from A to B)=2C 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)=2C and detecting
bidding down will not be possible.

Preventing bidding down in less extreme cases of compromise is of
course both possible and desirable (e.g. if the algorithms are just
weak but not breakable in real time=2C or if the attacker doesn't have
complete control over the communications). And the administrator could
always configure just the "new shared secret"=2C if he/she knows that
the peer supports it.
"




--_ef7ea29f-b2cb-4a67-b0cb-084bd1fa829e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Pasi seems to be making a valid point here. <br><br>Once MD5 is compromised=
=2C it will not be possible to avoid bidding down or other attacks. <br><br=
>A proposal is to state explicitly that protection against bidding down is =
only possible prior to MD5 compromise.&nbsp=3B After that=2C the only prote=
ction is requiring use of improved algorithms=2C by policy. <br><table styl=
e=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: 'Sego=
e UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.com=
/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=
=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D=
"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text=
-decoration: underline=3B"></span></a></td></tr></tbody></table><br><br><hr=
 id=3D"stopSpelling">From: [e-mail]<br>To: radiusext@ops.i=
etf.org<br>Subject: Crypto-agility requirements:  Compromise of Legacy Shar=
ed Secret (from Issue 303)<br>Date: Sun=2C 28 Jun 2009 14:04:02 -0700<br><b=
r>



<style>
.ExternalClass .EC_hmmessage P
{padding:0px=3B}
.ExternalClass body.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>


<br>In Issue 303=2C Pasi Eronen said:<br><br>"<pre>Compromise of legacy sha=
red secret:<br><br>Section 4.2 says "Crypto-agility solutions MUST avoid se=
curity<br>compromise=2C even in situations where the existing cryptographic=
<br>algorithms utilized by RADIUS implementations are shown to be weak<br>e=
nough to provide little or no security (e.g. in event of compromise<br>of t=
he legacy RADIUS shared secret).  Included in this would be<br>protection a=
gainst bidding down attacks."<br><br>If interpreted literally=2C this requi=
rement could be very difficult<br>to meet (perhaps impossible).<br><br>It s=
eems to assume that for this particular peer=2C the administrator<br>has co=
nfigured two different shared secrets (one for the current<br>security mech=
anisms=2C another for the new ones)=2C but has not configured<br>whether to=
 use the old or new mechanisms (with this particular peer)=2C<br>and instea=
d=2C that is negotiated somehow.<br><br>If the attacker knows the legacy sh=
ared secret=2C and has complete<br>control over the communication channel (=
and in particular=2C can drop<br>messages going from A to B)=2C then it see=
ms the attacker will be<br>indistinguishable from a valid peer that support=
s only the legacy<br>mechanisms (and does not know the new shared secret)=
=2C and detecting<br>bidding down will not be possible.<br><br>Preventing b=
idding down in less extreme cases of compromise is of<br>course both possib=
le and desirable (e.g. if the algorithms are just<br>weak but not breakable=
 in real time=2C or if the attacker doesn't have<br>complete control over t=
he communications). And the administrator could<br>always configure just th=
e "new shared secret"=2C if he/she knows that<br>the peer supports it.<br><=
/pre>"<br><br><br><table style=3D"border-top: 1px solid black=3B font-weigh=
t: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td>=
<a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterG=
ood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decorat=
ion: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: =
rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><br></td>=
</tr></tbody></table></body>
</html>=

--_ef7ea29f-b2cb-4a67-b0cb-084bd1fa829e_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:33:27 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_2c7a1002-5898-409f-8198-40eca3a47a98_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Crypto-agility requirements:  Automated Key Management concern (from Issue 303)
Date: Sun, 28 Jun 2009 14:32:48 -0700
MIME-Version: 1.0

--_2c7a1002-5898-409f-8198-40eca3a47a98_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This issue relates to previous discussions of whether the requirements of R=
FC 4107 mandate that an automated key management be part of a RADIUS crypto=
-agility solution.=20

In previous discussions=2C the conclusion seems to have been that the requi=
rements of RFC 4107 did not apply to RADIUS (e.g. only O(n) pre-shared secr=
ets needed).=20

The argument here seems to be that if you support forward secrecy and algor=
ithm negotiation then this implies automated key management.=20

That would seem to go beyond what is in RFC 4107=2C no?=20

=20





From: [e-mail]
To: [e-mail]
Subject: Crypto-agility requirements:  Automated Key Management concern (fr=
om Issue 303)
Date: Sun=2C 28 Jun 2009 14:02:59 -0700








Automated Key Management:

Well... RADIUS certainly requires only O(n) keys=2C but on the other
hand=2C the amount of data encrypted with a single key is not
necessarily small (when considering the "value of the data" and time
aspects -- in terms of gigabytes=2C it's probably small compared to what
decent algorithms can handle).

And if you anyway support negotiating the algorithms (in the
protocol)=2C generating a fresh session key may not be that much extra
effort=2C and may be needed anyway since the key can depend on the
selected algorithm (if you negotiate 256-bit AES=2C you need a 256-bit
key=3B if it's 3DES=2C 168 bits=2C etc.).  And the solutions should avoid
using the same cryptographic key with multiple algorithms (and the
easiest way to ensure this would probably be fresh session keys).

Generating a fresh session key probably also simplifies replay
protection (it's the obvious time to e.g. reset counters to zero)=2C but
other approaches to replays are certainly feasible.

And obviously=2C forward secrecy and supporting any other types of
long-term credentials than shared secrets requires automated key
management of some kind.

So=2C I think the conclusion here needs at the very least some
qualification and additional explanation.

*If* a solution not supporting forward secrecy and not supporting
other types of credentials is acceptable=2C *and* replay protection is
solved in certain way=2C *and* the solution can ensure that the
negotiated algorithms get keys appropriate for them=2C *and* the
solution can ensure that two algorithms don't use the same key=2C then
you might get away with no AKM. But even then=2C AKM might be less work.



--_2c7a1002-5898-409f-8198-40eca3a47a98_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
This issue relates to previous discussions of whether the requirements of R=
FC 4107 mandate that an automated key management be part of a RADIUS crypto=
-agility solution. <br><br>In previous discussions=2C the conclusion seems =
to have been that the requirements of RFC 4107 did not apply to RADIUS (e.g=
. only O(n) pre-shared secrets needed). <br><br>The argument here seems to =
be that if you support forward secrecy and algorithm negotiation then this =
implies automated key management. <br><br>That would seem to go beyond what=
 is in RFC 4107=2C no? <br><br>&nbsp=3B<br><br><br><table style=3D"border-t=
op: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahom=
a=2Csan-serif=3B"><tbody><tr><td><br></td></tr></tbody></table><br><br><hr =
id=3D"stopSpelling">From: [e-mail]<br>To: [e-mail]=
tf.org<br>Subject: Crypto-agility requirements:  Automated Key Management c=
oncern (from Issue 303)<br>Date: Sun=2C 28 Jun 2009 14:02:59 -0700<br><br>



<style>
.ExternalClass .EC_hmmessage P
{padding:0px=3B}
.ExternalClass body.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>


<pre>Automated Key Management:<br><br>Well... RADIUS certainly requires onl=
y O(n) keys=2C but on the other<br>hand=2C the amount of data encrypted wit=
h a single key is not<br>necessarily small (when considering the "value of =
the data" and time<br>aspects -- in terms of gigabytes=2C it's probably sma=
ll compared to what<br>decent algorithms can handle).<br><br>And if you any=
way support negotiating the algorithms (in the<br>protocol)=2C generating a=
 fresh session key may not be that much extra<br>effort=2C and may be neede=
d anyway since the key can depend on the<br>selected algorithm (if you nego=
tiate 256-bit AES=2C you need a 256-bit<br>key=3B if it's 3DES=2C 168 bits=
=2C etc.).  And the solutions should avoid<br>using the same cryptographic =
key with multiple algorithms (and the<br>easiest way to ensure this would p=
robably be fresh session keys).<br><br>Generating a fresh session key proba=
bly also simplifies replay<br>protection (it's the obvious time to e.g. res=
et counters to zero)=2C but<br>other approaches to replays are certainly fe=
asible.<br><br>And obviously=2C forward secrecy and supporting any other ty=
pes of<br>long-term credentials than shared secrets requires automated key<=
br>management of some kind.<br><br>So=2C I think the conclusion here needs =
at the very least some<br>qualification and additional explanation.<br><br>=
*If* a solution not supporting forward secrecy and not supporting<br>other =
types of credentials is acceptable=2C *and* replay protection is<br>solved =
in certain way=2C *and* the solution can ensure that the<br>negotiated algo=
rithms get keys appropriate for them=2C *and* the<br>solution can ensure th=
at two algorithms don't use the same key=2C then<br>you might get away with=
 no AKM. But even then=2C AKM might be less work.<br></pre><br><table style=
=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe=
 UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.com/=
Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=
=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D=
"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text=
-decoration: underline=3B"></span></a><br></td></tr></tbody></table></body>
</html>=

--_2c7a1002-5898-409f-8198-40eca3a47a98_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:26:50 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_2931f763-654c-443f-a221-9868b9909433_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Crypto-agility requirements:  Hop-by-hop vs. end-to-end (from Issue 303)
Date: Sun, 28 Jun 2009 14:26:10 -0700
MIME-Version: 1.0

--_2931f763-654c-443f-a221-9868b9909433_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


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

a. RADIUS currently does not support the Redirect facilities of Diameter=2C=
 which allows a NAS to directly talk to a Diameter server assuming that app=
ropriate credentials are available.=20

b. End-to-end protection requires that the NAS and RADIUS server can authen=
ticate directly.  Where pre-shared keys are used for authentication=2C this=
 creates a scaling problem.  Where certificates are available *and* re-dire=
ct (or automatic discovery) is available=2C the NAS can talk directly to th=
e RADIUS server.   However=2C this is an ongoing area of research/experimen=
tation=2C which is not yet mature enough for standardization.=20



From: [e-mail]
To: [e-mail]
Subject: Crypto-agility requirements:  Hop-by-hop vs. end-to-end (from Issu=
e 303)
Date: Sun=2C 28 Jun 2009 14:01:41 -0700









Hop-by-hop/end-to-end:

The document currently considers only "hop-by-hop" security
mechanisms=2C not any "end-to-end" protection (across proxies). I think
this is OK and perfectly reasonable -- but the document should say this=2C
and explain what this means for interpreting RFC 4962

Much of RFC 4962 is open to multiple interpretations=2C and some parts
of it can be read as requiring more than hop-by-hop security.  IMHO
exactly the same parts can also be read as saying hop-by-hop can be
sufficient (when done properly)=2C and I think this document should
explicitly say it's interpreting 4962 the latter way. (And once the
document has this explanation=2C you might want to run it by some other
ADs=2C too -- e.g. Tim and Russ)




--_2931f763-654c-443f-a221-9868b9909433_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
A proposal for addressing this would be to state explicitly that solutions =
are only required to address hop-by-hop security.&nbsp=3B&nbsp=3B If more e=
xplanation is required=2C one or more of the following points might be incl=
uded:<br><br>a. RADIUS currently does not support the Redirect facilities o=
f Diameter=2C which allows a NAS to directly talk to a Diameter server assu=
ming that appropriate credentials are available. <br><br>b. End-to-end prot=
ection requires that the NAS and RADIUS server can authenticate directly.&n=
bsp=3B Where pre-shared keys are used for authentication=2C this creates a =
scaling problem.&nbsp=3B Where certificates are available *and* re-direct (=
or automatic discovery) is available=2C the NAS can talk directly to the RA=
DIUS server. &nbsp=3B However=2C this is an ongoing area of research/experi=
mentation=2C which is not yet mature enough for standardization. <br><table=
 style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: =
'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.liv=
e.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size:=
 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span styl=
e=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B =
text-decoration: underline=3B"></span></a><br></td></tr></tbody></table><br=
><br><hr id=3D"stopSpelling">From: [e-mail]<br>To: radiuse=
[e-mail]<br>Subject: Crypto-agility requirements:  Hop-by-hop vs. en=
d-to-end (from Issue 303)<br>Date: Sun=2C 28 Jun 2009 14:01:41 -0700<br><br=
>



<style>
.ExternalClass .EC_hmmessage P
{padding:0px=3B}
.ExternalClass body.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>


<br><pre>Hop-by-hop/end-to-end:<br><br>The document currently considers onl=
y "hop-by-hop" security<br>mechanisms=2C not any "end-to-end" protection (a=
cross proxies). I think<br>this is OK and perfectly reasonable -- but the d=
ocument should say this=2C<br>and explain what this means for interpreting =
RFC 4962<br><br>Much of RFC 4962 is open to multiple interpretations=2C and=
 some parts<br>of it can be read as requiring more than hop-by-hop security=
.  IMHO<br>exactly the same parts can also be read as saying hop-by-hop can=
 be<br>sufficient (when done properly)=2C and I think this document should<=
br>explicitly say it's interpreting 4962 the latter way. (And once the<br>d=
ocument has this explanation=2C you might want to run it by some other<br>A=
Ds=2C too -- e.g. Tim and Russ)<br></pre><br><br><table style=3D"border-top=
: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=
=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/=
Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(=
1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D"padding: 0px 2=
4px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: un=
derline=3B"></span></a><br></td></tr></tbody></table></body>
</html>=

--_2931f763-654c-443f-a221-9868b9909433_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:16:43 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_c73b29d9-d12a-475a-b6f7-6e2f820073e0_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Crypto-agility requirements:  Forward Secrecy concern (from Issue 303)
Date: Sun, 28 Jun 2009 14:16:22 -0700
MIME-Version: 1.0

--_c73b29d9-d12a-475a-b6f7-6e2f820073e0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


A proposal for resolving this part of Pasi's Issue 303 would be to add a Fo=
rward Secrecy requirement=2C so that compromise of the long-term credential=
 would not necessarily result in compromise of previously transmitted keys.=
=20

From: [e-mail]
To: [e-mail]
Subject: Crypto-agility requirements:  Forward Secrecy concern (from Issue =
303)
Date: Sun=2C 28 Jun 2009 14:00:50 -0700








Forward secrecy:

Sometimes RADIUS is used to deliver keys (like EAP MSK) that will be
used (perhaps indirectly via additional key derivation steps) to
encrypt information that may be valuable for a long time.  Given this=2C
the document needs some discussion about "forward secrecy" (whether
revealing the long-term credential allows decrypting all past
communications)=2C and if the conclusion is that crypto-agility
solutions don't need to support forward secrecy (even as
optional-to-use feature)=2C explain the rationale behind this
conclusion.

--_c73b29d9-d12a-475a-b6f7-6e2f820073e0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
A proposal for resolving this part of Pasi's Issue 303 would be to add a Fo=
rward Secrecy requirement=2C so that compromise of the long-term credential=
 would not necessarily result in compromise of previously transmitted keys.=
 <br><br><hr id=3D"stopSpelling">From: [e-mail]<br>To: rad=
[e-mail]<br>Subject: Crypto-agility requirements:  Forward Secre=
cy concern (from Issue 303)<br>Date: Sun=2C 28 Jun 2009 14:00:50 -0700<br><=
br>



<style>
.ExternalClass .EC_hmmessage P
{padding:0px=3B}
.ExternalClass body.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>


<pre>Forward secrecy:<br><br>Sometimes RADIUS is used to deliver keys (like=
 EAP MSK) that will be<br>used (perhaps indirectly via additional key deriv=
ation steps) to<br>encrypt information that may be valuable for a long time=
.  Given this=2C<br>the document needs some discussion about "forward secre=
cy" (whether<br>revealing the long-term credential allows decrypting all pa=
st<br>communications)=2C and if the conclusion is that crypto-agility<br>so=
lutions don't need to support forward secrecy (even as<br>optional-to-use f=
eature)=2C explain the rationale behind this<br>conclusion.</pre><table sty=
le=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: 'Seg=
oe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.co=
m/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=
=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D=
"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text=
-decoration: underline=3B"></span></a><br></td></tr></tbody></table></body>
</html>=

--_c73b29d9-d12a-475a-b6f7-6e2f820073e0_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:15:10 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_7d4cb343-5e20-4935-bfbc-48d4b91693a2_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Crypto-agility requirements: Replay protection concern
Date: Sun, 28 Jun 2009 14:14:36 -0700
MIME-Version: 1.0

--_7d4cb343-5e20-4935-bfbc-48d4b91693a2_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Presumably=2C a crypto-agility solution would provide authentication/integr=
ity protection for every packet=2C including Access-Requests.=20

However=2C this would still allow an Access-Request to be replayed.=20

RFC 5176 Section 6.3 has a discussion of replay protection=2C which would s=
eem to apply here.  Basically=2C that section talks about either using tran=
smission layer security for replay protection=2C or including an Event-Time=
stamp attribute. =20

IMHO=2C one way to address this portion of Pasi's review would be to requir=
e that solutions support replay-protection for every packet. =20






From: [e-mail]
To: [e-mail]
Subject: Crypto-agility requirements: Replay protection concern
Date: Sun=2C 28 Jun 2009 13:59:48 -0700








Replay protection:

Section 4.2 says "Proposals MUST support replay protection.  The
existing mechanisms for replay protection are considered adequate and
should be maintained." I think the latter sentence needs some
clarification.  If the intent is to say replay protection provided by
the current mechanisms (i.e.=2C basically none for Access-Request
messages) is good enough=2C I would disagree with that (or at least
would expect to see an explanation why that's the case for
Access-Requests). If the intent is something else=2C the text needs
to be clearer.


--_7d4cb343-5e20-4935-bfbc-48d4b91693a2_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Presumably=2C a crypto-agility solution would provide authentication/integr=
ity protection for every packet=2C including Access-Requests. <br><br>Howev=
er=2C this would still allow an Access-Request to be replayed. <br><br>RFC =
5176 Section 6.3 has a discussion of replay protection=2C which would seem =
to apply here.&nbsp=3B Basically=2C that section talks about either using t=
ransmission layer security for replay protection=2C or including an Event-T=
imestamp attribute.&nbsp=3B <br><br>IMHO=2C one way to address this portion=
 of Pasi's review would be to require that solutions support replay-protect=
ion for every packet.&nbsp=3B <br><br><br><br><table style=3D"border-top: 1=
px solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Cs=
an-serif=3B"><tbody><tr><td><br></td></tr></tbody></table><br><br><hr id=3D=
"stopSpelling">From: [e-mail]<br>To: [e-mail]=
g<br>Subject: Crypto-agility requirements: Replay protection concern<br>Dat=
e: Sun=2C 28 Jun 2009 13:59:48 -0700<br><br>



<style>
.ExternalClass .EC_hmmessage P
{padding:0px=3B}
.ExternalClass body.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>


<pre>Replay protection:<br><br>Section 4.2 says "Proposals MUST support rep=
lay protection.  The<br>existing mechanisms for replay protection are consi=
dered adequate and<br>should be maintained." I think the latter sentence ne=
eds some<br>clarification.  If the intent is to say replay protection provi=
ded by<br>the current mechanisms (i.e.=2C basically none for Access-Request=
<br>messages) is good enough=2C I would disagree with that (or at least<br>=
would expect to see an explanation why that's the case for<br>Access-Reques=
ts). If the intent is something else=2C the text needs<br>to be clearer.<br=
></pre><table style=3D"border-top: 1px solid black=3B font-weight: bold=3B =
font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"=
http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=
=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=
=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C=
 181=2C 85)=3B text-decoration: underline=3B"></span></a><br></td></tr></tb=
ody></table></body>
</html>=

--_7d4cb343-5e20-4935-bfbc-48d4b91693a2_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:09:47 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_1c1e36fe-f92b-42fe-a0f8-36db8a4c57da_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RE: Crypto-agility requirements:  Credentials issue
Date: Sun, 28 Jun 2009 14:09:16 -0700
MIME-Version: 1.0

--_1c1e36fe-f92b-42fe-a0f8-36db8a4c57da_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


During the Virtual Interim=2C we discussed the potential drawbacks of requi=
ring that NASes support certificate-based authentication.=20
Given this=2C what types of credentials need to be supported in a crypto-ag=
ility solution?  Should it be necessary for a solution to support a shared =
secret or pre-shared key?=20


From: [e-mail]
To: [e-mail]
Subject: Crypto-agility requirements:  Credentials issue
Date: Sun=2C 28 Jun 2009 13:59:01 -0700








In Issue 303=2C Pasi Eronen brought up the following concern:=20

Authentication/long-term credentials:

Authenticating the RADIUS client and server will require (manual)
configuration of some kinds of credentials (currently=2C the RADIUS
shared secret). The document should say something about what kinds of
long-term authentication credentials (for RADIUS entities) the
crypto-agility solutions are expected to support.

Presumably=2C they MUST support pair-wise shared secrets. Other
possibilities for long-term credentials could include e.g. X.509
certificates with PKI=2C public keys without certification
infrastructure (generate keypair + configure fingerprint of peer's
key)=2C or Kerberos. Even if the conclusion is that nothing else than
pairwise shared secrets is needed=2C that should be said in the document
(with rationale explaining why).




--_1c1e36fe-f92b-42fe-a0f8-36db8a4c57da_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
During the Virtual Interim=2C we discussed the potential drawbacks of requi=
ring that NASes support certificate-based authentication. <br>Given this=2C=
 what types of credentials need to be supported in a crypto-agility solutio=
n?&nbsp=3B Should it be necessary for a solution to support a shared secret=
 or pre-shared key? <br><table style=3D"border-top: 1px solid black=3B font=
-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><t=
r><td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_Gr=
eaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-d=
ecoration: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B c=
olor: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><br=
></td></tr></tbody></table><br><hr id=3D"stopSpelling">From: bernard_aboba@=
hotmail.com<br>To: [e-mail]<br>Subject: Crypto-agility requir=
ements:  Credentials issue<br>Date: Sun=2C 28 Jun 2009 13:59:01 -0700<br><b=
r>



<style>
.ExternalClass .EC_hmmessage P
{padding:0px=3B}
.ExternalClass body.EC_hmmessage
{font-size:10pt=3Bfont-family:Verdana=3B}
</style>


In Issue 303=2C Pasi Eronen brought up the following concern: <br><br><pre>=
Authentication/long-term credentials:<br><br>Authenticating the RADIUS clie=
nt and server will require (manual)<br>configuration of some kinds of crede=
ntials (currently=2C the RADIUS<br>shared secret). The document should say =
something about what kinds of<br>long-term authentication credentials (for =
RADIUS entities) the<br>crypto-agility solutions are expected to support.<b=
r><br>Presumably=2C they MUST support pair-wise shared secrets. Other<br>po=
ssibilities for long-term credentials could include e.g. X.509<br>certifica=
tes with PKI=2C public keys without certification<br>infrastructure (genera=
te keypair + configure fingerprint of peer's<br>key)=2C or Kerberos. Even i=
f the conclusion is that nothing else than<br>pairwise shared secrets is ne=
eded=2C that should be said in the document<br>(with rationale explaining w=
hy).<br><br></pre><br><table style=3D"border-top: 1px solid black=3B font-w=
eight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr>=
<td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_Grea=
terGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-dec=
oration: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B col=
or: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><br><=
/td></tr></tbody></table></body>
</html>=

--_1c1e36fe-f92b-42fe-a0f8-36db8a4c57da_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:07:20 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_0121e4da-0e3d-4101-bad7-dd1bbd4f7e4c_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Crypto-agility requirements:  RADIUS service (from Issue 303)
Date: Sun, 28 Jun 2009 14:06:54 -0700
MIME-Version: 1.0

--_0121e4da-0e3d-4101-bad7-dd1bbd4f7e4c_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


In Issue 303=2C Pasi Eronen said:

""RADIUS service?"

Section 4.3 says "For example=2C proposals SHOULD NOT [..] include
definition of new RADIUS services."

What's a RADIUS service -- i.e. what types of proposals this
definition would disqualify? (In RFC 2865=2C "service" is defined as the
service provided by the NAS to the user=2C but that definition doesn't
seem applicable here.)"





--_0121e4da-0e3d-4101-bad7-dd1bbd4f7e4c_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
In Issue 303=2C Pasi Eronen said:<br><br>"<pre>"RADIUS service?"<br><br>Sec=
tion 4.3 says "For example=2C proposals SHOULD NOT [..] include<br>definiti=
on of new RADIUS services."<br><br>What's a RADIUS service -- i.e. what typ=
es of proposals this<br>definition would disqualify? (In RFC 2865=2C "servi=
ce" is defined as the<br>service provided by the NAS to the user=2C but tha=
t definition doesn't<br>seem applicable here.)</pre>"<br><br><br><br><table=
 style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: =
'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.liv=
e.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size:=
 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span styl=
e=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B =
text-decoration: underline=3B"></span></a><br></td></tr></tbody></table></b=
ody>
</html>=

--_0121e4da-0e3d-4101-bad7-dd1bbd4f7e4c_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:06:17 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_1541603c-bc7d-4f7a-bebe-bc1b80c26d4e_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Crypto-agility requirements: Operational Model (from Issue 303)
Date: Sun, 28 Jun 2009 14:05:54 -0700
MIME-Version: 1.0

--_1541603c-bc7d-4f7a-bebe-bc1b80c26d4e_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



In Issue 303=2C Pasi Eronen said:

""Operational model"?

Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes
to the RADIUS operational model=2C such as the introduction of new
commands or maintenance of [additional] state on the RADIUS server."

I'm not sure what "operational" means here -- at first I thought it
might mean "operations and management" (so the requirement would be
basically "SHOULD not complicate life for administrators")=2C but the
two examples given don't seem to fit that very well. And it seems any
solution that e.g. derives fresh session keys will involve some small
(but greater than zero) amount of additional state on clients and
servers.

If the intent was really operations and management=2C perhaps the should
be rephased something like "When using long-term shared secrets for
authentication=2C crypto-agility solutions SHOULD NOT require more
operations and management work than the current solutions."
"




 EMAILING FOR THE GREATER GOOD
Join me=

--_1541603c-bc7d-4f7a-bebe-bc1b80c26d4e_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<br>In Issue 303=2C Pasi Eronen said:<br><br>"<pre>"Operational model"?<br>=
<br>Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes<b=
r>to the RADIUS operational model=2C such as the introduction of new<br>com=
mands or maintenance of [additional] state on the RADIUS server."<br><br>I'=
m not sure what "operational" means here -- at first I thought it<br>might =
mean "operations and management" (so the requirement would be<br>basically =
"SHOULD not complicate life for administrators")=2C but the<br>two examples=
 given don't seem to fit that very well. And it seems any<br>solution that =
e.g. derives fresh session keys will involve some small<br>(but greater tha=
n zero) amount of additional state on clients and<br>servers.<br><br>If the=
 intent was really operations and management=2C perhaps the should<br>be re=
phased something like "When using long-term shared secrets for<br>authentic=
ation=2C crypto-agility solutions SHOULD NOT require more<br>operations and=
 management work than the current solutions."<br></pre>"<br><br><br><br><br=
><table style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-f=
amily: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http:/=
/im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"fon=
t-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><im=
g style=3D"border-style: none=3B" src=3D"http://gfx1.hotmail.com/mail/w3/lt=
r/i_charity.gif" alt=3D"i'm"> EMAILING FOR THE GREATER GOOD<br><span style=
=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B t=
ext-decoration: underline=3B">Join me</span></a></td></tr></tbody></table><=
/body>
</html>=

--_1541603c-bc7d-4f7a-bebe-bc1b80c26d4e_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:05:18 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_bad00583-469e-4310-8967-83e2ae41dea7_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Crypto-agility requirements: Backward Compatibility (from Issue 303)
Date: Sun, 28 Jun 2009 14:04:56 -0700
MIME-Version: 1.0

--_bad00583-469e-4310-8967-83e2ae41dea7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



In Issue 303=2C Pasi Eronen said:

"Backward compatibility/negotiation:

Section 4.3 says "Solutions to the problem MUST demonstrate backward
compatibility with existing RADIUS implementations.  That is=2C a
crypto-agility solution needs to be able to send packets that a legacy
RADIUS client or server will receive and process successfully.
Similarly=2C a crypto-agility solution needs to be capable of receiving
and processing packets from a legacy RADIUS client or server."

The intent of this paragraph is probably right=2C but currently=2C it's
somewhat open to multiple interpretations. Would something like this
capture the intent?

"Solutions to the problem MUST demonstrate backward compatibility with
existing RADIUS implementations.  That is=2C an implementation that
supports both the crypto-agility solution and legacy mechanisms MUST
be able to talk with legacy RADIUS clients and servers (using the
legacy mechanisms). Acceptable solutions to determining which set of
mechanisms is used (with a particular peer) include some kind of
negotiation=2C and manual configuration."

Note that *not* meeting this requirement would actually be quite
difficult... if the intent of this paragraph was to require some kind
of negotiation (interpreted loosely -- anything more automatic than
manual configuration)=2C the text should say so.

"




 EMAILING FOR THE GREATER GOOD
Join me=

--_bad00583-469e-4310-8967-83e2ae41dea7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<br>In Issue 303=2C Pasi Eronen said:<br><br>"<pre>Backward compatibility/n=
egotiation:<br><br>Section 4.3 says "Solutions to the problem MUST demonstr=
ate backward<br>compatibility with existing RADIUS implementations.  That i=
s=2C a<br>crypto-agility solution needs to be able to send packets that a l=
egacy<br>RADIUS client or server will receive and process successfully.<br>=
Similarly=2C a crypto-agility solution needs to be capable of receiving<br>=
and processing packets from a legacy RADIUS client or server."<br><br>The i=
ntent of this paragraph is probably right=2C but currently=2C it's<br>somew=
hat open to multiple interpretations. Would something like this<br>capture =
the intent?<br><br>"Solutions to the problem MUST demonstrate backward comp=
atibility with<br>existing RADIUS implementations.  That is=2C an implement=
ation that<br>supports both the crypto-agility solution and legacy mechanis=
ms MUST<br>be able to talk with legacy RADIUS clients and servers (using th=
e<br>legacy mechanisms). Acceptable solutions to determining which set of<b=
r>mechanisms is used (with a particular peer) include some kind of<br>negot=
iation=2C and manual configuration."<br><br>Note that *not* meeting this re=
quirement would actually be quite<br>difficult... if the intent of this par=
agraph was to require some kind<br>of negotiation (interpreted loosely -- a=
nything more automatic than<br>manual configuration)=2C the text should say=
 so.<br><br></pre>"<br><br><br><br><br><table style=3D"border-top: 1px soli=
d black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-seri=
f=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?sourc=
e=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C=
 203)=3B text-decoration: none=3B"><img style=3D"border-style: none=3B" src=
=3D"http://gfx1.hotmail.com/mail/w3/ltr/i_charity.gif" alt=3D"i'm"> EMAILIN=
G FOR THE GREATER GOOD<br><span style=3D"padding: 0px 24px=3B font-size: 8p=
t=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B">Join me<=
/span></a></td></tr></tbody></table></body>
</html>=

--_bad00583-469e-4310-8967-83e2ae41dea7_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:04:29 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_3361f1c7-0237-4b60-bc78-20ca4e53c3a4_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Crypto-agility requirements:  Compromise of Legacy Shared Secret (from Issue 303)
Date: Sun, 28 Jun 2009 14:04:02 -0700
MIME-Version: 1.0

--_3361f1c7-0237-4b60-bc78-20ca4e53c3a4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



In Issue 303=2C Pasi Eronen said:

"Compromise of legacy shared secret:

Section 4.2 says "Crypto-agility solutions MUST avoid security
compromise=2C even in situations where the existing cryptographic
algorithms utilized by RADIUS implementations are shown to be weak
enough to provide little or no security (e.g. in event of compromise
of the legacy RADIUS shared secret).  Included in this would be
protection against bidding down attacks."

If interpreted literally=2C this requirement could be very difficult
to meet (perhaps impossible).

It seems to assume that for this particular peer=2C the administrator
has configured two different shared secrets (one for the current
security mechanisms=2C another for the new ones)=2C but has not configured
whether to use the old or new mechanisms (with this particular peer)=2C
and instead=2C that is negotiated somehow.

If the attacker knows the legacy shared secret=2C and has complete
control over the communication channel (and in particular=2C can drop
messages going from A to B)=2C 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)=2C and detecting
bidding down will not be possible.

Preventing bidding down in less extreme cases of compromise is of
course both possible and desirable (e.g. if the algorithms are just
weak but not breakable in real time=2C or if the attacker doesn't have
complete control over the communications). And the administrator could
always configure just the "new shared secret"=2C if he/she knows that
the peer supports it.
"




--_3361f1c7-0237-4b60-bc78-20ca4e53c3a4_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<br>In Issue 303=2C Pasi Eronen said:<br><br>"<pre>Compromise of legacy sha=
red secret:<br><br>Section 4.2 says "Crypto-agility solutions MUST avoid se=
curity<br>compromise=2C even in situations where the existing cryptographic=
<br>algorithms utilized by RADIUS implementations are shown to be weak<br>e=
nough to provide little or no security (e.g. in event of compromise<br>of t=
he legacy RADIUS shared secret).  Included in this would be<br>protection a=
gainst bidding down attacks."<br><br>If interpreted literally=2C this requi=
rement could be very difficult<br>to meet (perhaps impossible).<br><br>It s=
eems to assume that for this particular peer=2C the administrator<br>has co=
nfigured two different shared secrets (one for the current<br>security mech=
anisms=2C another for the new ones)=2C but has not configured<br>whether to=
 use the old or new mechanisms (with this particular peer)=2C<br>and instea=
d=2C that is negotiated somehow.<br><br>If the attacker knows the legacy sh=
ared secret=2C and has complete<br>control over the communication channel (=
and in particular=2C can drop<br>messages going from A to B)=2C then it see=
ms the attacker will be<br>indistinguishable from a valid peer that support=
s only the legacy<br>mechanisms (and does not know the new shared secret)=
=2C and detecting<br>bidding down will not be possible.<br><br>Preventing b=
idding down in less extreme cases of compromise is of<br>course both possib=
le and desirable (e.g. if the algorithms are just<br>weak but not breakable=
 in real time=2C or if the attacker doesn't have<br>complete control over t=
he communications). And the administrator could<br>always configure just th=
e "new shared secret"=2C if he/she knows that<br>the peer supports it.<br><=
/pre>"<br><br><br><table style=3D"border-top: 1px solid black=3B font-weigh=
t: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td>=
<a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterG=
ood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decorat=
ion: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: =
rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><br></td>=
</tr></tbody></table></body>
</html>=

--_3361f1c7-0237-4b60-bc78-20ca4e53c3a4_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:03:26 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_f227e284-8913-445d-a9e0-83b1e01dedf0_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Crypto-agility requirements:  Automated Key Management concern (from Issue 303)
Date: Sun, 28 Jun 2009 14:02:59 -0700
MIME-Version: 1.0

--_f227e284-8913-445d-a9e0-83b1e01dedf0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Automated Key Management:

Well... RADIUS certainly requires only O(n) keys=2C but on the other
hand=2C the amount of data encrypted with a single key is not
necessarily small (when considering the "value of the data" and time
aspects -- in terms of gigabytes=2C it's probably small compared to what
decent algorithms can handle).

And if you anyway support negotiating the algorithms (in the
protocol)=2C generating a fresh session key may not be that much extra
effort=2C and may be needed anyway since the key can depend on the
selected algorithm (if you negotiate 256-bit AES=2C you need a 256-bit
key=3B if it's 3DES=2C 168 bits=2C etc.).  And the solutions should avoid
using the same cryptographic key with multiple algorithms (and the
easiest way to ensure this would probably be fresh session keys).

Generating a fresh session key probably also simplifies replay
protection (it's the obvious time to e.g. reset counters to zero)=2C but
other approaches to replays are certainly feasible.

And obviously=2C forward secrecy and supporting any other types of
long-term credentials than shared secrets requires automated key
management of some kind.

So=2C I think the conclusion here needs at the very least some
qualification and additional explanation.

*If* a solution not supporting forward secrecy and not supporting
other types of credentials is acceptable=2C *and* replay protection is
solved in certain way=2C *and* the solution can ensure that the
negotiated algorithms get keys appropriate for them=2C *and* the
solution can ensure that two algorithms don't use the same key=2C then
you might get away with no AKM. But even then=2C AKM might be less work.



--_f227e284-8913-445d-a9e0-83b1e01dedf0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<pre>Automated Key Management:<br><br>Well... RADIUS certainly requires onl=
y O(n) keys=2C but on the other<br>hand=2C the amount of data encrypted wit=
h a single key is not<br>necessarily small (when considering the "value of =
the data" and time<br>aspects -- in terms of gigabytes=2C it's probably sma=
ll compared to what<br>decent algorithms can handle).<br><br>And if you any=
way support negotiating the algorithms (in the<br>protocol)=2C generating a=
 fresh session key may not be that much extra<br>effort=2C and may be neede=
d anyway since the key can depend on the<br>selected algorithm (if you nego=
tiate 256-bit AES=2C you need a 256-bit<br>key=3B if it's 3DES=2C 168 bits=
=2C etc.).  And the solutions should avoid<br>using the same cryptographic =
key with multiple algorithms (and the<br>easiest way to ensure this would p=
robably be fresh session keys).<br><br>Generating a fresh session key proba=
bly also simplifies replay<br>protection (it's the obvious time to e.g. res=
et counters to zero)=2C but<br>other approaches to replays are certainly fe=
asible.<br><br>And obviously=2C forward secrecy and supporting any other ty=
pes of<br>long-term credentials than shared secrets requires automated key<=
br>management of some kind.<br><br>So=2C I think the conclusion here needs =
at the very least some<br>qualification and additional explanation.<br><br>=
*If* a solution not supporting forward secrecy and not supporting<br>other =
types of credentials is acceptable=2C *and* replay protection is<br>solved =
in certain way=2C *and* the solution can ensure that the<br>negotiated algo=
rithms get keys appropriate for them=2C *and* the<br>solution can ensure th=
at two algorithms don't use the same key=2C then<br>you might get away with=
 no AKM. But even then=2C AKM might be less work.<br></pre><br><table style=
=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe=
 UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.com/=
Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=
=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D=
"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text=
-decoration: underline=3B"></span></a><br></td></tr></tbody></table></body>
</html>=

--_f227e284-8913-445d-a9e0-83b1e01dedf0_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:02:09 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_a3985332-2d90-423a-b554-1f370f26fe18_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Crypto-agility requirements:  Hop-by-hop vs. end-to-end (from Issue 303)
Date: Sun, 28 Jun 2009 14:01:41 -0700
MIME-Version: 1.0

--_a3985332-2d90-423a-b554-1f370f26fe18_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Hop-by-hop/end-to-end:

The document currently considers only "hop-by-hop" security
mechanisms=2C not any "end-to-end" protection (across proxies). I think
this is OK and perfectly reasonable -- but the document should say this=2C
and explain what this means for interpreting RFC 4962

Much of RFC 4962 is open to multiple interpretations=2C and some parts
of it can be read as requiring more than hop-by-hop security.  IMHO
exactly the same parts can also be read as saying hop-by-hop can be
sufficient (when done properly)=2C and I think this document should
explicitly say it's interpreting 4962 the latter way. (And once the
document has this explanation=2C you might want to run it by some other
ADs=2C too -- e.g. Tim and Russ)




--_a3985332-2d90-423a-b554-1f370f26fe18_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<br><pre>Hop-by-hop/end-to-end:<br><br>The document currently considers onl=
y "hop-by-hop" security<br>mechanisms=2C not any "end-to-end" protection (a=
cross proxies). I think<br>this is OK and perfectly reasonable -- but the d=
ocument should say this=2C<br>and explain what this means for interpreting =
RFC 4962<br><br>Much of RFC 4962 is open to multiple interpretations=2C and=
 some parts<br>of it can be read as requiring more than hop-by-hop security=
.  IMHO<br>exactly the same parts can also be read as saying hop-by-hop can=
 be<br>sufficient (when done properly)=2C and I think this document should<=
br>explicitly say it's interpreting 4962 the latter way. (And once the<br>d=
ocument has this explanation=2C you might want to run it by some other<br>A=
Ds=2C too -- e.g. Tim and Russ)<br></pre><br><br><table style=3D"border-top=
: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=
=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/=
Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(=
1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D"padding: 0px 2=
4px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: un=
derline=3B"></span></a><br></td></tr></tbody></table></body>
</html>=

--_a3985332-2d90-423a-b554-1f370f26fe18_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:01:18 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_18e10047-0cbc-4b60-b469-44bbff8558b6_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Crypto-agility requirements:  Forward Secrecy concern (from Issue 303)
Date: Sun, 28 Jun 2009 14:00:50 -0700
MIME-Version: 1.0

--_18e10047-0cbc-4b60-b469-44bbff8558b6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Forward secrecy:

Sometimes RADIUS is used to deliver keys (like EAP MSK) that will be
used (perhaps indirectly via additional key derivation steps) to
encrypt information that may be valuable for a long time.  Given this=2C
the document needs some discussion about "forward secrecy" (whether
revealing the long-term credential allows decrypting all past
communications)=2C and if the conclusion is that crypto-agility
solutions don't need to support forward secrecy (even as
optional-to-use feature)=2C explain the rationale behind this
conclusion.

--_18e10047-0cbc-4b60-b469-44bbff8558b6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<pre>Forward secrecy:<br><br>Sometimes RADIUS is used to deliver keys (like=
 EAP MSK) that will be<br>used (perhaps indirectly via additional key deriv=
ation steps) to<br>encrypt information that may be valuable for a long time=
.  Given this=2C<br>the document needs some discussion about "forward secre=
cy" (whether<br>revealing the long-term credential allows decrypting all pa=
st<br>communications)=2C and if the conclusion is that crypto-agility<br>so=
lutions don't need to support forward secrecy (even as<br>optional-to-use f=
eature)=2C explain the rationale behind this<br>conclusion.</pre><table sty=
le=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: 'Seg=
oe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.co=
m/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=
=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D=
"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text=
-decoration: underline=3B"></span></a><br></td></tr></tbody></table></body>
</html>=

--_18e10047-0cbc-4b60-b469-44bbff8558b6_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 21:00:18 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_6de420bd-8380-46c2-ab84-df4f8db4aea1_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Crypto-agility requirements: Replay protection concern
Date: Sun, 28 Jun 2009 13:59:48 -0700
MIME-Version: 1.0

--_6de420bd-8380-46c2-ab84-df4f8db4aea1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Replay protection:

Section 4.2 says "Proposals MUST support replay protection.  The
existing mechanisms for replay protection are considered adequate and
should be maintained." I think the latter sentence needs some
clarification.  If the intent is to say replay protection provided by
the current mechanisms (i.e.=2C basically none for Access-Request
messages) is good enough=2C I would disagree with that (or at least
would expect to see an explanation why that's the case for
Access-Requests). If the intent is something else=2C the text needs
to be clearer.


--_6de420bd-8380-46c2-ab84-df4f8db4aea1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<pre>Replay protection:<br><br>Section 4.2 says "Proposals MUST support rep=
lay protection.  The<br>existing mechanisms for replay protection are consi=
dered adequate and<br>should be maintained." I think the latter sentence ne=
eds some<br>clarification.  If the intent is to say replay protection provi=
ded by<br>the current mechanisms (i.e.=2C basically none for Access-Request=
<br>messages) is good enough=2C I would disagree with that (or at least<br>=
would expect to see an explanation why that's the case for<br>Access-Reques=
ts). If the intent is something else=2C the text needs<br>to be clearer.<br=
></pre><table style=3D"border-top: 1px solid black=3B font-weight: bold=3B =
font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"=
http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=
=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=
=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C=
 181=2C 85)=3B text-decoration: underline=3B"></span></a><br></td></tr></tb=
ody></table></body>
</html>=

--_6de420bd-8380-46c2-ab84-df4f8db4aea1_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 20:59:29 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_2f9820cf-e3b0-4a78-aa62-152ad863a0bd_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Crypto-agility requirements:  Credentials issue
Date: Sun, 28 Jun 2009 13:59:01 -0700
MIME-Version: 1.0

--_2f9820cf-e3b0-4a78-aa62-152ad863a0bd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


In Issue 303=2C Pasi Eronen brought up the following concern:=20

Authentication/long-term credentials:

Authenticating the RADIUS client and server will require (manual)
configuration of some kinds of credentials (currently=2C the RADIUS
shared secret). The document should say something about what kinds of
long-term authentication credentials (for RADIUS entities) the
crypto-agility solutions are expected to support.

Presumably=2C they MUST support pair-wise shared secrets. Other
possibilities for long-term credentials could include e.g. X.509
certificates with PKI=2C public keys without certification
infrastructure (generate keypair + configure fingerprint of peer's
key)=2C or Kerberos. Even if the conclusion is that nothing else than
pairwise shared secrets is needed=2C that should be said in the document
(with rationale explaining why).




--_2f9820cf-e3b0-4a78-aa62-152ad863a0bd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
In Issue 303=2C Pasi Eronen brought up the following concern: <br><br><pre>=
Authentication/long-term credentials:<br><br>Authenticating the RADIUS clie=
nt and server will require (manual)<br>configuration of some kinds of crede=
ntials (currently=2C the RADIUS<br>shared secret). The document should say =
something about what kinds of<br>long-term authentication credentials (for =
RADIUS entities) the<br>crypto-agility solutions are expected to support.<b=
r><br>Presumably=2C they MUST support pair-wise shared secrets. Other<br>po=
ssibilities for long-term credentials could include e.g. X.509<br>certifica=
tes with PKI=2C public keys without certification<br>infrastructure (genera=
te keypair + configure fingerprint of peer's<br>key)=2C or Kerberos. Even i=
f the conclusion is that nothing else than<br>pairwise shared secrets is ne=
eded=2C that should be said in the document<br>(with rationale explaining w=
hy).<br><br></pre><br><table style=3D"border-top: 1px solid black=3B font-w=
eight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr>=
<td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_Grea=
terGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-dec=
oration: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B col=
or: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><br><=
/td></tr></tbody></table></body>
</html>=

--_2f9820cf-e3b0-4a78-aa62-152ad863a0bd_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 20:57:29 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_8da57790-3b43-4bfe-91c7-89ac6d953b7b_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Extended Attributes and Diameter Compatibility
Date: Sun, 28 Jun 2009 13:56:50 -0700
MIME-Version: 1.0

--_8da57790-3b43-4bfe-91c7-89ac6d953b7b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


During the Virtual Interim=2C we discussed the issue of translation of RADI=
US Extended Attributes to Diameter.  Some of the following points arose dur=
ing the discussion:

a. Even if RADIUS Extended attributes could be automatically translated to =
Diameter=2C does this make sense?  Diameter has more sophisticated grouping=
 facilities than are possible with Extended Attributes.  So if an attribute=
 was defined as Extended that used grouping=2C wouldn't it make more sense =
to use the Diameter grouping facilities in defining the Diameter version of=
 the attribute?=20

b. Status of RFC 4005bis in DIME.  David Mitton's original proposal for ena=
bling translation of *any* RADIUS VSA to Diameter is not currently on the (=
revised) DIME WG charter.  It is not clear that there is interest within DI=
ME to pursue this.=20

c. Need for RADIUS/Diameter translation.  While RADEXT WG documents need a =
Diameter considerations section=2C and so far this section has typically re=
lied on translation=2C it is not clear whether translation really makes sen=
se.  Few deployments appear to make use of this currently.  If RADIUS suppo=
rt is needed=2C then a "dual stack" approach can be taken -- run both a RAD=
IUS and a Diameter server against a common backend database.  So is there r=
eally a need to support RAIDUS attributes within Diameter itself? =20





--_8da57790-3b43-4bfe-91c7-89ac6d953b7b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
During the Virtual Interim=2C we discussed the issue of translation of RADI=
US Extended Attributes to Diameter.&nbsp=3B Some of the following points ar=
ose during the discussion:<br><br>a. Even if RADIUS Extended attributes cou=
ld be automatically translated to Diameter=2C does this make sense?&nbsp=3B=
 Diameter has more sophisticated grouping facilities than are possible with=
 Extended Attributes.&nbsp=3B So if an attribute was defined as Extended th=
at used grouping=2C wouldn't it make more sense to use the Diameter groupin=
g facilities in defining the Diameter version of the attribute? <br><br>b. =
Status of RFC 4005bis in DIME.&nbsp=3B David Mitton's original proposal for=
 enabling translation of *any* RADIUS VSA to Diameter is not currently on t=
he (revised) DIME WG charter.&nbsp=3B It is not clear that there is interes=
t within DIME to pursue this. <br><br>c. Need for RADIUS/Diameter translati=
on.&nbsp=3B While RADEXT WG documents need a Diameter considerations sectio=
n=2C and so far this section has typically relied on translation=2C it is n=
ot clear whether translation really makes sense.&nbsp=3B Few deployments ap=
pear to make use of this currently.&nbsp=3B If RADIUS support is needed=2C =
then a "dual stack" approach can be taken -- run both a RADIUS and a Diamet=
er server against a common backend database.&nbsp=3B So is there really a n=
eed to support RAIDUS attributes within Diameter itself?&nbsp=3B <br><br><b=
r><br><br><table style=3D"border-top: 1px solid black=3B font-weight: bold=
=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=
=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" st=
yle=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: no=
ne=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=
=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a></td></tr></tbo=
dy></table></body>
</html>=

--_8da57790-3b43-4bfe-91c7-89ac6d953b7b_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 20:43:18 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_173dd13b-bddf-4b7f-97cf-48885172a3fb_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: RADEXT WG Last Call on Status Server document
Date: Sun, 28 Jun 2009 13:42:37 -0700
MIME-Version: 1.0

--_173dd13b-bddf-4b7f-97cf-48885172a3fb_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Good question.=20

"Experimental" would imply some sort of ongoing experiment.  In this case=
=2C my understanding was that Status Server was implemented back in the 199=
0s=2C so the experiment should have either succeeded or failed by now.=20

Status Server (and other Ascend extensions=2C such as Dynamic Authorization=
) weren't originally documented as a Proposed Standard due to perceived def=
iciencies which couldn't be addressed without breaking backward compatibili=
ty.=20

So that would seem to leave Informational.=20


> Date: Sun=2C 28 Jun 2009 14:00:48 -0400
> Subject: Re: RADEXT WG Last Call on Status Server document
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]
>=20
> On Fri=2C Jun 26=2C 2009 at 2:19 AM=2C Bernard Aboba<bernard_aboba@hotmai=
l.com> wrote:
> > This is an announcement of RADEXT WG last call on the Status Server
> > specification=2C prior to sending this document on to the IESG for publ=
ication
> > as an Informational RFC.
>=20
> Can the chairs clarify the intended track of this doc?  The current chart=
er
> milestone indicates PS=3B Informational is mentioned above=3B experimenta=
l is
> in the current text's footer.
>=20
> > 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=2C 2009.  Please send comm=
ents to
> > the RADEXT WG mailing list using the format described in the RADEXT Iss=
ues
> > list (http://www.drizzle.com/~aboba/RADEXT/).
> >
> >
> >
>=20
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--_173dd13b-bddf-4b7f-97cf-48885172a3fb_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Good question. <br><br>"Experimental" would imply some sort of ongoing expe=
riment.&nbsp=3B In this case=2C my understanding was that Status Server was=
 implemented back in the 1990s=2C so the experiment should have either succ=
eeded or failed by now. <br><br>Status Server (and other Ascend extensions=
=2C such as Dynamic Authorization) weren't originally documented as a Propo=
sed Standard due to perceived deficiencies which couldn't be addressed with=
out breaking backward compatibility. <br><br>So that would seem to leave In=
formational. <br><br><br>&gt=3B Date: Sun=2C 28 Jun 2009 14:00:48 -0400<br>=
&gt=3B Subject: Re: RADEXT WG Last Call on Status Server document<br>&gt=3B=
 From: [e-mail]<br>&gt=3B To: [e-mail]<br>&gt=3B =
CC: [e-mail]<br>&gt=3B <br>&gt=3B On Fri=2C Jun 26=2C 2009 at=
 2:19 AM=2C Bernard Aboba&lt=[e-mail]&gt=3B wrote:<br>&g=
t=3B &gt=3B This is an announcement of RADEXT WG last call on the Status Se=
rver<br>&gt=3B &gt=3B specification=2C prior to sending this document on to=
 the IESG for publication<br>&gt=3B &gt=3B as an Informational RFC.<br>&gt=
=3B <br>&gt=3B Can the chairs clarify the intended track of this doc?  The =
current charter<br>&gt=3B milestone indicates PS=3B Informational is mentio=
ned above=3B experimental is<br>&gt=3B in the current text's footer.<br>&gt=
=3B <br>&gt=3B &gt=3B The document is available for inspection here:<br>&gt=
=3B &gt=3B http://tools.ietf.org/html/draft-ietf-radext-status-server<br>&g=
t=3B &gt=3B<br>&gt=3B &gt=3B RADEXT WG last call will last until August 7=
=2C 2009.&nbsp=3B Please send comments to<br>&gt=3B &gt=3B the RADEXT WG ma=
iling list using the format described in the RADEXT Issues<br>&gt=3B &gt=3B=
 list (http://www.drizzle.com/~aboba/RADEXT/).<br>&gt=3B &gt=3B<br>&gt=3B &=
gt=3B<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B --<br>&gt=3B to unsubscribe sen=
d a message to [e-mail] with<br>&gt=3B the word 'unsu=
bscribe' in a single line as the message text body.<br>&gt=3B archive: &lt=
=3Bhttp://psg.com/lists/radiusext/&gt=3B<br></body>
</html>=

--_173dd13b-bddf-4b7f-97cf-48885172a3fb_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 20:26:34 +0000
Message-ID: <[e-mail]>
Date: Sun, 28 Jun 2009 22:25:27 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: Greg Weber <[e-mail]>
CC: Bernard Aboba <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: RADEXT WG Last Call on Status Server document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Greg Weber wrote:
> Can the chairs clarify the intended track of this doc?  The current charter
> milestone indicates PS; Informational is mentioned above; experimental is
> in the current text's footer.

  The content of the document should reflect the WG and the chairs
position.  Any errors or omissions are mine.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 18:01:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gx4hQKoJuKr2J29KMNdGh0XPXMxZjD3mfWPMOI6upqQ=; b=CSZ1kSrOjpFa9WIJ3oSnuubBqFogeFZ6JnO9x/Kq/6/eJYOUXYi+7ZMv63FHm89nJw wyXz8Ei/ueSUmZC6IdVu0AAxahuCsuu7oZQ4zHCEoVimmO1YZ0t91ncVREWMCfYjiieL TMEdsHTIR1sQcAmvFkhkYDfeqfQ/Z4BRJB/AY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FyOfS4DtH5sK+GOhEBunkpnHtyODZJWGdFD5zskx3189+NixjTtnXI0alpBEqNPBP+ OKCiFnaldovTAXdEEjf1vvnjqD0eAasfSb4OaarjD4vCwCDMTBm136wqxOKBhxihlJsL 4i9G0oP5Z9j+xKQm3o6ySuoTQmr6wrUOwARCo=
MIME-Version: 1.0
Date: Sun, 28 Jun 2009 14:00:48 -0400
Message-ID: <[e-mail]>
Subject: Re: RADEXT WG Last Call on Status Server document
From: Greg Weber <[e-mail]>
To: Bernard Aboba <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 26, 2009 at 2:19 AM, Bernard Aboba<[e-mail]> w=
rote:
> This is an announcement of RADEXT WG last call on the Status Server
> specification, prior to sending this document on to the IESG for publicat=
ion
> as an Informational RFC.

Can the chairs clarify the intended track of this doc?  The current charter
milestone indicates PS; Informational is mentioned above; experimental is
in the current text's footer.

> 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.=A0 Please send commen=
ts to
> the RADEXT WG mailing list using the format described in the RADEXT Issue=
s
> list (http://www.drizzle.com/~aboba/RADEXT/).
>
>
>

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 16:42:46 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_3bb6c53d-842f-4479-9fa2-59c963736970_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Draft minutes of the Virtual Interim Meeting
Date: Sun, 28 Jun 2009 09:41:30 -0700
MIME-Version: 1.0

--_3bb6c53d-842f-4479-9fa2-59c963736970_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Here are the draft minutes from the Virtual Interim.=20

Comments/edits/additions welcome.=20

RADEXT WG Virtual Interim Meeting
June 10=2C 2009
Minutes

RADIUS Crypto-agility Requirements

Open Issues include 274=2C 275=2C 303.=20

Of the open issues=2C 303 (from Pasi Eronen's review) overlaps with some of=
 the
comments in the other issues.=20

David Nelson:  Addressing Pasi's comments will probably require a complete =
rewrite
               of the document=2C but I haven't had the time...
Bernard Aboba:  Pasi had comments in the following areas:

Hop-by-hop/end-to-end: Explaining why solutions only need to focus on "hop-=
by-hop".=20
Forward secrecy: Whether this is necessary or not.  Issue is transmission o=
f keys that
                 could be used for a long time.=20
Credentials:  what kinds of credentials solutions are expected to support.=
=20
Replay protection: Access-Request messages currently aren't replay protecte=
d.  Do we
                   need to do better?
Negotiation:  Does this require negotiation in the protocol=2C or between a=
dmins?=20
Automated Key management: If you don't have automated key management=2C the=
re can be
                          issues=3B more explanation is needed.=20
Compromise of legacy shared secret:  The requirement in the document seems =
difficult
                          to meet=2C since if MD5 is cracked=2C then how do=
 you avoid
                          bidding down attacks?=20
Backward compatibility:  It is hard *not* to meet this requirement.  Is the=
 goal to
                         require some kind of negotiation?
Operational model:  What does this mean?
RADIUS service:  What is a RADIUS service? =20
 =20
Hannes:  Do we really need the requirements document anymore?  Isn't Glen's=
 document obsolete?
Glen Zorn:  I am no longer pursuing it=2C though Cisco might want to publis=
h a document
            describing what they have implemented.=20
David Nelson:  So do we now just have a single proposed solution (TLS/DTLS)=
? The
               other approach can just go forward as an Informational RFC=
=2C via the
               RFC Editor.
Glen Zorn: To be clear -- I still think that the approach has value.  Diame=
ter adopted
           TLS=2C but it isn't deployed.  Many implementations actually  us=
e no security
           at all.  So do we really think that RADSEC will solve this probl=
em?  It seems
           unlikely.=20
David Nelson:  RADSEC is only for use by proxies=2C right?=20
Alan DeKok:  Yes.=20
David Nelson:  So how can RADSEC solve the problem of protecting communicat=
ion between
               a NAS and a proxy?=20
Bernard Aboba:  It can't.  But presumably DTLS would be used for that situa=
tion?=20
Alan DeKok:  I am revising the DTLS draft.=20
Glen Zorn:   The problem is bigger than that... what credentials will you u=
se?  Is it=20
             possible to require certificates on every NAS/proxy?
Bernard:     Judging from the situation with Diameter=2C the answer to that=
 is "No."
Glen Zorn:   The solution provided in my draft is something that has actual=
ly been
             implemented... and that operators could actually deploy.  Isn'=
t that
             important?=20
Bernard:     It would seem that Pasi's questions apply to all approaches...=
 and that they
             need to be answered in order for us to understand when we're d=
one.  For
             example=2C the "bidding down" problem can occur with TLS/DTLS =
as well.=20

Alan DeKok:  With DTLS it is possible for a RADIUS server to detect whether=
 an incoming
             packet is DTLS or not=2C and switch automatically.=20
Bernard:     But how does the NAS know to attempt DTLS?  Does it use DNS di=
scovery?  And
             what if DNSSEC isn't in use?  Couldn't that be spoofed?=20
Alan DeKok:  You can have policy to require TLS/DTLS.=20
Bernard:     That works once you know that you have transitioned the NASes.=
.. but what
             about when you're operating a mixed network?
Alan DeKok:  The RADIUS server can keep a list of what NASes have ever atte=
mpted TLS/DTLS.
Bernard:     So once the NAS tried DTLS/TLS it is assumed that it will alwa=
ys use that.=20
Alan DeKok:  Yes.=20
Glen Zorn:   Also=2C my draft provides a mechanism for encrypting RADIUS at=
tributes.  That=20
             has value beyond what TLS can provide.=20
Bernard:     In the "end-to-end" case=2C which is what Pasi was asking abou=
t.  So to answer
             Hannes' question=2C the requirements document would seem to ha=
ve value=2C=20
             since the issues Pasi raised come up regardless of the approac=
h taken.
David Nelson: So what are the next steps?  Discussion on the list?=20
Bernard:     Yes.  =20


RADIUS Extended Attributes

Open issues:  251=2C 290=2C 298.=20

These issues largely concern Diameter compatibility and IANA allocation pol=
icies.=20

Bernard:  With respect to IANA allocation policies=2C allocation of Extende=
d Attributes
          isn't just for when we run out of standard attributes.  Couldn't =
someone
          request allocation from the extended attributes space before then=
?
Glen Zorn:  Yes.=20

The Diameter compatibility issues arise because the Extended Attributes doc=
ument
does not use the VSA format recommended in RFC 2865 (one octet type field).=
  As
a result=2C the procedures described in RFC 3588 cannot be applied for tran=
slating
RADIUS Extended Attributes to Diameter.=20

David Mitton:  I had a draft long ago that covered this....
Bernard:  Yes.  Has their been progress on introducing that within DIME?
Glen Zorn:  No.=20
Hannes:  Does anyone really run mixed Diameter/RADIUS networks anyway? =20
         From what I have seen=2C they do not.=20
Glen Zorn:  I have not seen it either.=20
David Nelson:  So why do we require Diameter Compatibility boilerplate in a=
ll
               of our documents?  Is this really necessary?
Bernard:  If nobody is doing translation=2C maybe it is not necessary.  In =
any
          case=2C Diameter will have its own equivalent of the RADIUS Exten=
ded
          Attributes features (e.g. grouping)=2C so you'd probably want to=
=20
          allocate separate Diameter AVPs anyway.=20
David Nelson:  So maybe this is a non-problem?  Should we check with DIME?
Bernard:  Probably.=20







--_3bb6c53d-842f-4479-9fa2-59c963736970_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Here are the draft minutes from the Virtual Interim. <br><br>Comments/edits=
/additions welcome. <br><br>RADEXT WG Virtual Interim Meeting<br>June 10=2C=
 2009<br>Minutes<br><br>RADIUS Crypto-agility Requirements<br><br>Open Issu=
es include 274=2C 275=2C 303. <br><br>Of the open issues=2C 303 (from Pasi =
Eronen's review) overlaps with some of the<br>comments in the other issues.=
 <br><br>David Nelson:&nbsp=3B Addressing Pasi's comments will probably req=
uire a complete rewrite<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B of the doc=
ument=2C but I haven't had the time...<br>Bernard Aboba:&nbsp=3B Pasi had c=
omments in the following areas:<br><br>Hop-by-hop/end-to-end: Explaining wh=
y solutions only need to focus on "hop-by-hop". <br>Forward secrecy: Whethe=
r this is necessary or not.&nbsp=3B Issue is transmission of keys that<br>&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B could be used for a lo=
ng time. <br>Credentials:&nbsp=3B what kinds of credentials solutions are e=
xpected to support. <br>Replay protection: Access-Request messages currentl=
y aren't replay protected.&nbsp=3B Do we<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B need to do better?<br>Negotiation:=
&nbsp=3B Does this require negotiation in the protocol=2C or between admins=
? <br>Automated Key management: If you don't have automated key management=
=2C there can be<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B is=
sues=3B more explanation is needed. <br>Compromise of legacy shared secret:=
&nbsp=3B The requirement in the document seems difficult<br>&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B to meet=2C since if MD5 is cracked=2C=
 then how do you avoid<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B bidding down attacks? <br>Backward compatibility:&nbsp=3B It is hard *n=
ot* to meet this requirement.&nbsp=3B Is the goal to<br>&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B require some kind of negotiation?<br>Operational m=
odel:&nbsp=3B What does this mean?<br>RADIUS service:&nbsp=3B What is a RAD=
IUS service?&nbsp=3B <br>&nbsp=3B <br>Hannes:&nbsp=3B Do we really need the=
 requirements document anymore?&nbsp=3B Isn't Glen's document obsolete?<br>=
Glen Zorn:&nbsp=3B I am no longer pursuing it=2C though Cisco might want to=
 publish a document<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B describing what they have implemented.=
 <br>David Nelson:&nbsp=3B So do we now just have a single proposed solutio=
n (TLS/DTLS)? The<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B other approach =
can just go forward as an Informational RFC=2C via the<br>&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B RFC Editor.<br>Glen Zorn: To be clear -- I still think=
 that the approach has value.&nbsp=3B Diameter adopted<br>&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B TLS=2C but =
it isn't deployed.&nbsp=3B Many implementations actually&nbsp=3B use no sec=
urity<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B at all.&nbsp=3B So do we really think that RADSEC will solve=
 this problem?&nbsp=3B It seems<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B unlikely. <br>David Nelson:&nbsp=
=3B RADSEC is only for use by proxies=2C right? <br>Alan DeKok:&nbsp=3B Yes=
. <br>David Nelson:&nbsp=3B So how can RADSEC solve the problem of protecti=
ng communication between<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B a NAS a=
nd a proxy? <br>Bernard Aboba:&nbsp=3B It can't.&nbsp=3B But presumably DTL=
S would be used for that situation? <br>Alan DeKok:&nbsp=3B I am revising t=
he DTLS draft. <br>Glen Zorn:&nbsp=3B&nbsp=3B The problem is bigger than th=
at... what credentials will you use?&nbsp=3B Is it <br>&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B possible to require certificates on every NAS/proxy?<br>Bernard:&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B Judging from the situation with Diameter=2C the=
 answer to that is "No."<br>Glen Zorn:&nbsp=3B&nbsp=3B The solution provide=
d in my draft is something that has actually been<br>&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
 implemented... and that operators could actually deploy.&nbsp=3B Isn't tha=
t<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B important? <br>Bernard:&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B It would seem that Pasi's questions apply to all approaches... and=
 that they<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B need to be answered in order for us to =
understand when we're done.&nbsp=3B For<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B example=2C=
 the "bidding down" problem can occur with TLS/DTLS as well. <br><br>Alan D=
eKok:&nbsp=3B With DTLS it is possible for a RADIUS server to detect whethe=
r an incoming<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B packet is DTLS or not=2C and switch =
automatically. <br>Bernard:&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B But how does th=
e NAS know to attempt DTLS?&nbsp=3B Does it use DNS discovery?&nbsp=3B And<=
br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B what if DNSSEC isn't in use?&nbsp=3B Couldn't that=
 be spoofed? <br>Alan DeKok:&nbsp=3B You can have policy to require TLS/DTL=
S. <br>Bernard:&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B That works once you know th=
at you have transitioned the NASes... but what<br>&nbsp=3B&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B abo=
ut when you're operating a mixed network?<br>Alan DeKok:&nbsp=3B The RADIUS=
 server can keep a list of what NASes have ever attempted TLS/DTLS.<br>Bern=
ard:&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B So once the NAS tried DTLS/TLS it is a=
ssumed that it will always use that. <br>Alan DeKok:&nbsp=3B Yes. <br>Glen =
Zorn:&nbsp=3B&nbsp=3B Also=2C my draft provides a mechanism for encrypting =
RADIUS attributes.&nbsp=3B That <br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B has value beyon=
d what TLS can provide. <br>Bernard:&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B In the=
 "end-to-end" case=2C which is what Pasi was asking about.&nbsp=3B So to an=
swer<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B Hannes' question=2C the requirements document=
 would seem to have value=2C <br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B since the issues Pas=
i raised come up regardless of the approach taken.<br>David Nelson: So what=
 are the next steps?&nbsp=3B Discussion on the list? <br>Bernard:&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B Yes.&nbsp=3B&nbsp=3B <br><br><br>RADIUS Extended Att=
ributes<br><br>Open issues:&nbsp=3B 251=2C 290=2C 298. <br><br>These issues=
 largely concern Diameter compatibility and IANA allocation policies. <br><=
br>Bernard:&nbsp=3B With respect to IANA allocation policies=2C allocation =
of Extended Attributes<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B isn't just for when we run out of standard attribut=
es.&nbsp=3B Couldn't someone<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B request allocation from the extended attribut=
es space before then?<br>Glen Zorn:&nbsp=3B Yes. <br><br>The Diameter compa=
tibility issues arise because the Extended Attributes document<br>does not =
use the VSA format recommended in RFC 2865 (one octet type field).&nbsp=3B =
As<br>a result=2C the procedures described in RFC 3588 cannot be applied fo=
r translating<br>RADIUS Extended Attributes to Diameter. <br><br>David Mitt=
on:&nbsp=3B I had a draft long ago that covered this....<br>Bernard:&nbsp=
=3B Yes.&nbsp=3B Has their been progress on introducing that within DIME?<b=
r>Glen Zorn:&nbsp=3B No. <br>Hannes:&nbsp=3B Does anyone really run mixed D=
iameter/RADIUS networks anyway?&nbsp=3B <br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B From what I have seen=2C they do not. <=
br>Glen Zorn:&nbsp=3B I have not seen it either. <br>David Nelson:&nbsp=3B =
So why do we require Diameter Compatibility boilerplate in all<br>&nbsp=3B&=
nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B of our documents?&nbsp=3B Is this really neces=
sary?<br>Bernard:&nbsp=3B If nobody is doing translation=2C maybe it is not=
 necessary.&nbsp=3B In any<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B case=2C Diameter will have its own equivalent o=
f the RADIUS Extended<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B Attributes features (e.g. grouping)=2C so you'd prob=
ably want to <br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B allocate separate Diameter AVPs anyway. <br>David Nelson:&nb=
sp=3B So maybe this is a non-problem?&nbsp=3B Should we check with DIME?<br=
>Bernard:&nbsp=3B Probably. <br><br><br><br><br><br><table style=3D"border-=
top: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTaho=
ma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/I=
M/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rg=
b(1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D"padding: 0px=
 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: =
underline=3B"></span></a><br></td></tr></tbody></table></body>
</html>=

--_3bb6c53d-842f-4479-9fa2-59c963736970_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Jun 2009 11:50:58 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>, <[e-mail]>
Subject: RE: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item
Date: Sun, 28 Jun 2009 18:45:44 +0700
Message-ID: <015701c9f7e6$01457e00$03d07a00$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0158_01C9F820.ADA45600"
Thread-Index: Acn2JvSevgK3LIzpRDC0X3KkX2Bf5QBvuKbQ
Content-Language: en-us

This is a multi-part message in MIME format.

------=_NextPart_000_0158_01C9F820.ADA45600
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I'm in favor (it would be a little strange if I wasn't ;-).

 

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Bernard Aboba
Sent: Friday, June 26, 2009 1:24 PM
To: [e-mail]
Subject: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks
document as a WG work item

 

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>
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/%7Eaboba/RADEXT/>
http://www.drizzle.com/~aboba/RADEXT/








	

 


------=_NextPart_000_0158_01C9F820.ADA45600
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Segoe UI";
	panose-1:2 11 5 2 4 2 4 2 2 3;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Arial Black","sans-serif";
	color:#7030A0;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#7030A0'>I'm in favor (it would be a little strange if I wasn't =
;-).<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#7030A0'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
[e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Bernard =
Aboba<br>
<b>Sent:</b> Friday, June 26, 2009 1:24 PM<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> REMINDER: Call for adoption of RADIUS for IPv6 Access =
Networks
document as a WG work item<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:10.0pt;
font-family:"Verdana","sans-serif"'>This is a reminder of an ongoing =
call for
review of the document &quot;RADIUS attributes for IPv6 Access =
Networks&quot;
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=3D'color:#0068CF'><a
href=3D"http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access"><s=
pan
style=3D'color:#0066CC'>http://tools.ietf.org/html/draft-lourdelet-radext=
-ipv6-access</span></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 href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/" =
target=3D"_blank"><span
style=3D'color:#0068CF'>http://www.drizzle.com/~aboba/RADEXT/</span></a><=
br>
<br>
<br>
<br>
<br>
<br>
<br>
<o:p></o:p></span></p>

<table class=3DMsoNormalTable border=3D1 cellpadding=3D0 =
style=3D'border:none;
 border-top:solid black 1.0pt'>
 <tr>
  <td style=3D'border:none;padding:.75pt .75pt .75pt .75pt'></td>
 </tr>
</table>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0158_01C9F820.ADA45600--


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


Envelope-to: [e-mail]
Delivery-date: Fri, 26 Jun 2009 06:45:03 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_df2d9d24-6b3b-41af-9fda-c9b153d05c20_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Call for adoption of RADIUS over DTLS document as a RADEXT WG work item
Date: Thu, 25 Jun 2009 23:44:31 -0700
MIME-Version: 1.0

--_df2d9d24-6b3b-41af-9fda-c9b153d05c20_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is a call for review of the document "DTLS as a Transport Layer for RA=
DIUS" for adoption as a RADEXT WG work item.  This document is being target=
ed at Experimental
status.=20

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

This
call for review will last until August 7=2C 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=2C please also send these to the list in the format described on
the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/



--_df2d9d24-6b3b-41af-9fda-c9b153d05c20_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
This is a call for review of the document "DTLS as a Transport Layer for RA=
DIUS" for adoption as a RADEXT WG work item.&nbsp=3B This document is being=
 targeted at Experimental
status. <br>
&nbsp=3B<br>The document is available for review here:<br><span style=3D"fo=
nt-size: 10pt=3B color: rgb(0=2C 104=2C 207)=3B font-family: 'Verdana'=2C's=
ans-serif'=3B"></span>http://tools.ietf.org/html/draft-dekok-radext-dtls<br=
><br>This
call for review will last until August 7=2C 2009.&nbsp=3B Please send email=
 to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.&nbsp=3B If you have comments on the
document=2C please also send these to the list in the format described on
the RADEXT WG Issues list:<br><a rel=3D"nofollow" href=3D"http://www.drizzl=
e.com/%7Eaboba/RADEXT/" target=3D"_blank"><font color=3D"#0068cf">http://ww=
w.drizzle.com/~aboba/RADEXT/</font></a><br><br><table style=3D"border-top: =
1px solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2C=
san-serif=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/Hom=
e/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=
=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D"padding: 0px 24=
px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: und=
erline=3B"></span></a><br></td></tr></tbody></table></body>
</html>=

--_df2d9d24-6b3b-41af-9fda-c9b153d05c20_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 26 Jun 2009 06:34:48 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG Agenda for IETF 75 - take one
Date: Thu, 25 Jun 2009 23:34:16 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_23BC_01C9F5ED.74B8EB60"
Thread-Index: Acn2KAu1BaM+ERYwQUeK7+XJlDkTXAAAAtCw
Content-Language: en-us

------=_NextPart_000_23BC_01C9F5ED.74B8EB60
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Here is the strawman agenda for IETF 75:

 

RADEXT WG @ IETF 75

Stockholm, Sweden

 

Thursday, July 30, 2009

9:00 - 11:30 AM, Room 300

 

Documents completing IETF Last Call

 

Design Guidelines document, Alan DeKok (10  minutes)

http://tools.ietf.org/html/draft-ietf-radext-design

 

Documents completing WG last call

 

RADSEC, Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec

 

Documents in WG Last Call

 

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

 

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

 

 

 

 

 

 

 

 

 


------=_NextPart_000_23BC_01C9F5ED.74B8EB60
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Here is the strawman agenda for IETF =
75:<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>RADEXT WG @ IETF 75<o:p></o:p></p>

<p class=3DMsoNormal>Stockholm, Sweden<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Thursday, July 30, 2009<o:p></o:p></p>

<p class=3DMsoNormal>9:00 &#8211; 11:30 AM, Room 300<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><b>Documents completing IETF Last =
Call<o:p></o:p></b></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Design Guidelines document, Alan DeKok (10 =
&nbsp;minutes)<o:p></o:p></p>

<p class=3DMsoNormal><a =
href=3D"http://tools.ietf.org/html/draft-ietf-radext-design">http://tools=
.ietf.org/html/draft-ietf-radext-design</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><b>Documents completing WG last =
call<o:p></o:p></b></p>

<p class=3DMsoNormal><b><o:p>&nbsp;</o:p></b></p>

<p class=3DMsoNormal>RADSEC, Stefan Winter (10 minutes)<o:p></o:p></p>

<p class=3DMsoNormal><a =
href=3D"http://tools.ietf.org/html/draft-ietf-radext-radsec">http://tools=
.ietf.org/html/draft-ietf-radext-radsec</a><o:p></o:p></p>

<p class=3DMsoNormal><b><o:p>&nbsp;</o:p></b></p>

<p class=3DMsoNormal><b>Documents in WG Last Call<o:p></o:p></b></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Status-Server document, Alan DeKok (10 =
minutes)<o:p></o:p></p>

<p class=3DMsoNormal><a
href=3D"http://tools.ietf.org/html/draft-ietf-radext-status-server">http:=
//tools.ietf.org/html/draft-ietf-radext-status-server</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>RADIUS over TCP document, Alan DeKok (10 =
minutes)<o:p></o:p></p>

<p class=3DMsoNormal><a
href=3D"http://tools.ietf.org/html/draft-ietf-radext-tcp-transport">http:=
//tools.ietf.org/html/draft-ietf-radext-tcp-transport</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><b>Documents under consideration for adoption as WG =
work
items<o:p></o:p></b></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>RADIUS over DTLS, Alan DeKok (10 =
minutes)<o:p></o:p></p>

<p class=3DMsoNormal><a =
href=3D"http://tools.ietf.org/html/draft-dekok-radext-dtls">http://tools.=
ietf.org/html/draft-dekok-radext-dtls</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>NAI-based Peer Discovery, Stefan Winter (10 =
minutes)<o:p></o:p></p>

<p class=3DMsoNormal><a
href=3D"http://tools.ietf.org/html/draft-winter-dynamic-discovery">http:/=
/tools.ietf.org/html/draft-winter-dynamic-discovery</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>RADIUS attributes for IEEE 802 Networks, Bernard =
Aboba (10
minutes)<o:p></o:p></p>

<p class=3DMsoNormal><a =
href=3D"http://tools.ietf.org/html/draft-aboba-radext-wlan">http://tools.=
ietf.org/html/draft-aboba-radext-wlan</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------=_NextPart_000_23BC_01C9F5ED.74B8EB60--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 26 Jun 2009 06:24:14 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_d1eee468-4d1e-4ac9-9670-cddba9a42763_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: REMINDER: Call for adoption of RADIUS for IPv6 Access Networks document as a WG work item
Date: Thu, 25 Jun 2009 23:23:55 -0700
MIME-Version: 1.0

--_d1eee468-4d1e-4ac9-9670-cddba9a42763_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


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

=20
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=2C 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=2C please also send these to the list in the format described on
the RADEXT WG Issues list:
http://www.drizzle.com/~aboba/RADEXT/









--_d1eee468-4d1e-4ac9-9670-cddba9a42763_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
This is a reminder of an ongoing call for review of the document "RADIUS at=
tributes for IPv6
Access Networks" for adoption as a RADEXT WG work item.&nbsp=3B This docume=
nt is being targeted at Proposed Standard
status. <br>
&nbsp=3B<br>The document is available for review here:<br><span style=3D"fo=
nt-size: 10pt=3B color: rgb(0=2C 104=2C 207)=3B font-family: 'Verdana'=2C's=
ans-serif'=3B"><a href=3D"http://tools.ietf.org/html/draft-lourdelet-radext=
-ipv6-access" rel=3D"nofollow"><font color=3D"#0066cc">http://tools.ietf.or=
g/html/draft-lourdelet-radext-ipv6-access</font></a></span><br><br>This
call for review will last until August 7=2C 2009.&nbsp=3B Please send email=
 to
the RADEXT WG mailing list indicating whether you support adoption of
this document as a RADEXT WG work item.&nbsp=3B If you have comments on the
document=2C please also send these to the list in the format described on
the RADEXT WG Issues list:<br><a rel=3D"nofollow" href=3D"http://www.drizzl=
e.com/%7Eaboba/RADEXT/" target=3D"_blank"><font color=3D"#0068cf">http://ww=
w.drizzle.com/~aboba/RADEXT/</font></a><br><br><br><br><br><br><br><br><tab=
le style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family=
: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.l=
ive.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-siz=
e: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span st=
yle=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=
=3B text-decoration: underline=3B"></span></a><br></td></tr></tbody></table=
></body>
</html>=

--_d1eee468-4d1e-4ac9-9670-cddba9a42763_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 26 Jun 2009 06:21:10 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_cc2f7e23-96ea-42a2-a699-d968357e9703_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RADEXT WG Last call on the RADIUS over TCP document
Date: Thu, 25 Jun 2009 23:20:51 -0700
MIME-Version: 1.0

--_cc2f7e23-96ea-42a2-a699-d968357e9703_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is an announcement of RADEXT WG last call on RADIUS over TCP
specification=2C 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=2C 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/). =20

--_cc2f7e23-96ea-42a2-a699-d968357e9703_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
This is an announcement of RADEXT WG last call on RADIUS over TCP
specification=2C prior to sending this document on to the IESG for
publication as an Experimental RFC.&nbsp=3B 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=2C 2009.&nbsp=3B 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=3B <table style=
=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe=
 UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><br></td></tr></tbody></table>=
</body>
</html>=

--_cc2f7e23-96ea-42a2-a699-d968357e9703_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 26 Jun 2009 06:20:31 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_93a71c5f-222c-40d6-be56-ed67b79cf2f1_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RADEXT WG Last Call on Status Server document
Date: Thu, 25 Jun 2009 23:19:20 -0700
MIME-Version: 1.0

--_93a71c5f-222c-40d6-be56-ed67b79cf2f1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is an announcement of RADEXT WG last call on the Status Server
specification=2C 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=2C 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/). =20



--_93a71c5f-222c-40d6-be56-ed67b79cf2f1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
This is an announcement of RADEXT WG last call on the Status Server
specification=2C prior to sending this document on to the IESG for
publication as an Informational RFC.&nbsp=3B The document is available for
inspection here:<br>http://tools.ietf.org/html/draft-ietf-radext-status-ser=
ver<br><br>RADEXT
WG last call will last until August 7=2C 2009.&nbsp=3B 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=3B <br><br><table=
 style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: =
'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><br></td></tr></tbody></=
table></body>
</html>=

--_93a71c5f-222c-40d6-be56-ed67b79cf2f1_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 12 Jun 2009 12:35:59 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>, "'David B. Nelson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Open issues on the Crypto-Agility Requirements draft
Date: Fri, 12 Jun 2009 19:31:22 +0700
Message-ID: <003001c9eb59$bc73eb60$355bc220$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C9EB94.68D2C360"
Thread-Index: Acnqq33w6fwNOtP5QVWxchXK5JfccgAn5HtA
Content-Language: en-us

This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C9EB94.68D2C360
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:[e-mail]]  writes:

> As I mentioned in the meeting, this is making a rather huge assumption
about
> deployment issues over which the IETF has no control; in addition, the
> experience WRT Diameter security deployment is not especially encouraging.

My understanding is that many Diameter deployments use no security at all, 
making them much *less* secure than RADIUS. 

And these deployments are with NASes that are considerably more expensive
than a mass market access point.  

I'm not sure whether the issue is operational (too hard to configure) or 
with the implementation.  

 

My guess is that it's a matter of "security by assertion and assumption",
the assertion being that  our internal network is totally secure from
external attack with the assumption that all employees are both trustworthy
& incorruptible.



But something, somewhere, appears to have gone very wrong. 


------=_NextPart_000_0031_01C9EB94.68D2C360
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Arial Black";
	panose-1:2 11 10 4 2 1 2 2 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Arial Black","sans-serif";
	color:#7030A0;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Bernard
Aboba [mailto:[e-mail]] &nbsp;writes:</span><span
style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";color:#7030A0'><o:p></o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in =
0in 4.0pt'>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'>&gt;
As I mentioned in the meeting, this is making a rather huge assumption =
about<br>
&gt; deployment issues over which the IETF has no control; in addition, =
the<br>
&gt; experience WRT Diameter security deployment is not especially =
encouraging.<br>
<br>
My understanding is that many Diameter deployments use no security at =
all, <br>
making them much *less* secure than RADIUS. <br>
<br>
And these deployments are with NASes that are considerably more =
expensive<br>
than a mass market access point.&nbsp; <br>
<br>
I'm not sure whether the issue is operational (too hard to configure) or =
<br>
with the implementation.&nbsp; <span =
style=3D'color:#7030A0'><o:p></o:p></span></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#7030A0'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Arial =
Black","sans-serif";
color:#7030A0'>My guess is that it's a matter of &quot;security by =
assertion
and assumption&quot;, the assertion being that &nbsp;our internal =
network is totally
secure from external attack with the assumption that all employees are =
both
trustworthy &amp; incorruptible&#8230;<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Verdana","sans-serif"'><br>
<br>
But something, somewhere, appears to have gone very wrong. =
<o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0031_01C9EB94.68D2C360--


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


Envelope-to: [e-mail]
Delivery-date: Fri, 12 Jun 2009 10:07:10 +0000
Message-ID: <[e-mail]>
Date: Fri, 12 Jun 2009 12:06:32 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "David B. Nelson" <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: Open issues on the Crypto-Agility Requirements draft
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> In a very large deployment (e.g. thousands of NASes) keeping track of
> which ones support the new capabilities is non-trivial.

  I'm not sure I understand this.  A server can't track 1 bit of
information for each NAS that connects to it?

>> The client should also have a per-server flag saying "negotiated
>> secure RADIUS". Once that flag is set, it refuses to use legacy RADIUS.
> 
> This requires that the RADIUS client population can be enumerated and
> clearly identified.  In a deployment that has a list of RADIUS clients at
> fixed IP addresses, that requirement can be met.   In other situations,
> that's not as obvious.

 No.  It requires that the *current* NAS population be permitted to talk
to the server.  Which it is.  It then requires that the server be
upgrade to support the above flag.  It then permits each NAS to be
upgraded to use the new security measures.

  Once the server sees a NAS use a new security system, it flips a bit
in a database for that NAS from "false" to "true".  This doesn't affect
any of the other NASes.

>> My suggestion in the DTLS document is for the NAS to simply start
>> using the better security method. Once the NAS has been authenticated,
>> the "NAS supports better security" flag is set, and legacy RADIUS
>> becomes impossible.
> 
> That represents the end state where all legacy NASes have been
> replaced.

  No.  The flag is *per* NAS.  It's not global.

> But that doesn't imply that the RRs are retrieved securely, so dynamic
> discovery doesn't address the downgrade issue.

  If a server sees an unknown client connect, it will be either (a) an
attacker, or (b) a client that discovered the server via RR's.  It
doesn't know until it validates the identity of the client.  And it MUST
use a secure method to do so.  It MUST NOT use the legacy RADIUS shared
secret, because the entire reason it's an unknown client is that it
doesn't have a legacy RADIUS secret for the client.

  At that point, the server opens itself up to SSL connection exhaustion
attacks.  But there are no *RADIUS* issues with that.  Once the server
has used TLS to validate that the client is known, it uses TLS to
transport the legacy RADIUS packets.

  If a client uses RR's to discover a server, it MUST use a TLS-based
method to communicate with that server.

  If a client has a fixed IP to communicate with a server, it SHOULD be
configurable as to whether or not it uses TLS.  If the admin says "no,
don't use TLS", then there's no downbidding attack.  If the admin says
"yes, use TLS", then there's no downbidding attack: the NAS refuses to
speak legacy RADIUS, because it's been told to *not* speak legacy RADIUS.

> In fact, one could argue
> that the introduction of (insecure) dynamic discovery complicates the
> security analysis considerably.

  Yes, that's true.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 12 Jun 2009 09:41:35 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_b965a9ab-2d23-4223-a8a0-3e0f14d486af_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>
CC: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Open issues on the Crypto-Agility Requirements draft
Date: Fri, 12 Jun 2009 02:40:52 -0700
MIME-Version: 1.0

--_b965a9ab-2d23-4223-a8a0-3e0f14d486af_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   Not if the RADIUS server has an administrative flag saying "this NAS
> supports better security".
>=20
>   Once that flag is set=2C then any down-grade attack disappears.

In a very large deployment (e.g. thousands of NASes) keeping track of
which ones support the new capabilities is non-trivial.

>   The client should also have a per-server flag saying "negotiated
> secure RADIUS".  Once that flag is set=2C it refuses to use legacy RADIUS=
.

This requires that the RADIUS client population can be enumerated and
clearly identified.  In a deployment that has a list of RADIUS clients at
fixed IP addresses=2C that requirement can be met.   In other situations=2C
that's not as obvious.=20

> > It seems to me that the only way to completely address this is by havin=
g
> > the NAS indicate support *within RADIUS*.=20
>=20
>   Use an insecure protocol to negotiate a secure one... hmmm...

For this purpose=2C MD5 is not "insecure" until it is possible to forge
RADIUS messages in near real-time.  Even with all the attacks against
WEP=2C the progression from cracking it in weeks to minutes took place
over a significant time period. =20

>   My suggestion in the DTLS document is for the NAS to simply start
> using the better security method.  Once the NAS has been authenticated=2C
> the "NAS supports better security" flag is set=2C and legacy RADIUS
> becomes impossible.

That represents the end state where all legacy NASes have been
replaced.

> > Use of dynamic discovery doesn't help without DNSSEC=2C since an attack=
er
> > can forge the RRs to force a downgrade.
>=20
>   Legacy RADIUS doesn't use RR's.  If the client is found via RR's=2C it
> MUST use the newer=2C more secure=2C solution.

But that doesn't imply that the RRs are retrieved securely=2C so dynamic
discovery doesn't address the downgrade issue.  In fact=2C one could argue
that the introduction of (insecure) dynamic discovery complicates the secur=
ity=20
analysis considerably.=20




--_b965a9ab-2d23-4223-a8a0-3e0f14d486af_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B   Not if the RADIUS server has an administrative flag saying "this N=
AS<br>&gt=3B supports better security".<br>&gt=3B <br>&gt=3B   Once that fl=
ag is set=2C then any down-grade attack disappears.<br><br>In a very large =
deployment (e.g. thousands of NASes) keeping track of<br>which ones support=
 the new capabilities is non-trivial.<br><br>&gt=3B   The client should als=
o have a per-server flag saying "negotiated<br>&gt=3B secure RADIUS".  Once=
 that flag is set=2C it refuses to use legacy RADIUS.<br><br>This requires =
that the RADIUS client population can be enumerated and<br>clearly identifi=
ed.&nbsp=3B In a deployment that has a list of RADIUS clients at<br>fixed I=
P addresses=2C that requirement can be met.&nbsp=3B&nbsp=3B In other situat=
ions=2C<br>that's not as obvious. <br><br>&gt=3B &gt=3B It seems to me that=
 the only way to completely address this is by having<br>&gt=3B &gt=3B the =
NAS indicate support *within RADIUS*. <br>&gt=3B <br>&gt=3B   Use an insecu=
re protocol to negotiate a secure one... hmmm...<br><br>For this purpose=2C=
 MD5 is not "insecure" until it is possible to forge<br>RADIUS messages in =
near real-time.&nbsp=3B Even with all the attacks against<br>WEP=2C the pro=
gression from cracking it in weeks to minutes took place<br>over a signific=
ant time period.&nbsp=3B <br><br>&gt=3B   My suggestion in the DTLS documen=
t is for the NAS to simply start<br>&gt=3B using the better security method=
.  Once the NAS has been authenticated=2C<br>&gt=3B the "NAS supports bette=
r security" flag is set=2C and legacy RADIUS<br>&gt=3B becomes impossible.<=
br><br>That represents the end state where all legacy NASes have been<br>re=
placed.<br><br>&gt=3B &gt=3B Use of dynamic discovery doesn't help without =
DNSSEC=2C since an attacker<br>&gt=3B &gt=3B can forge the RRs to force a d=
owngrade.<br>&gt=3B <br>&gt=3B   Legacy RADIUS doesn't use RR's.  If the cl=
ient is found via RR's=2C it<br>&gt=3B MUST use the newer=2C more secure=2C=
 solution.<br><br>But that doesn't imply that the RRs are retrieved securel=
y=2C so dynamic<br>discovery doesn't address the downgrade issue.&nbsp=3B I=
n fact=2C one could argue<br>that the introduction of (insecure) dynamic di=
scovery complicates the security <br>analysis considerably. <br><br><br><br=
></body>
</html>=

--_b965a9ab-2d23-4223-a8a0-3e0f14d486af_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 12 Jun 2009 08:26:56 +0000
Message-ID: <[e-mail]>
Date: Fri, 12 Jun 2009 10:26:18 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "David B. Nelson" <[e-mail]>,  "[e-mail]" <[e-mail]>
Subject: Re: Open issues on the Crypto-Agility Requirements draft
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Assuming that legacy RADIUS is still supported in a NAS deployment
> (likely to be true for a long time), then it is possible for an attacker
> to attempt to convince the RADIUS server (which we presume has been
> upgraded) to utilize legacy RADIUS with MD5 security.

  Not if the RADIUS server has an administrative flag saying "this NAS
supports better security".

  Once that flag is set, then any down-grade attack disappears.

> It seems to me that the only way to completely address this is by having
> the NAS indicate support *within RADIUS*. 

  Use an insecure protocol to negotiate a secure one... hmmm...

  My suggestion in the DTLS document is for the NAS to simply start
using the better security method.  Once the NAS has been authenticated,
the "NAS supports better security" flag is set, and legacy RADIUS
becomes impossible.

> Use of dynamic discovery doesn't help without DNSSEC, since an attacker
> can forge the RRs to force a downgrade.

  Legacy RADIUS doesn't use RR's.  If the client is found via RR's, it
MUST use the newer, more secure, solution.

> Use of transport wrappers can't address it either if we assume that
> attackers have the ability to cause arbitrary packets to be lost, and that
> the NAS will drop down to ordinary RADIUS in the situation that transmission
> layer security doesn't generate a response.

  The server can keep a flag saying "NAS uses secure RADIUS".  If it
sees a legacy RADIUS packet from the NAS, it knows something is wrong.
It can return an Access-Reject, or simply discard the packet.  This
protects the server.

  The client should also have a per-server flag saying "negotiated
secure RADIUS".  Once that flag is set, it refuses to use legacy RADIUS.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 12 Jun 2009 07:59:11 +0000
Message-ID: <[e-mail]>
Date: Fri, 12 Jun 2009 09:58:12 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: REMINDER: Call for review of the "NAI-based Peer Discovery" document for acceptance as a RADEXT WG work item
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> This is a reminder of an ongoing call for review of the document
> "NAI-based Peer Discovery" for adoption as a RADEXT WG work item.  This
> document was formerly part of the RADSEC document, and is now being
> split off into its own document, which (like RADSEC) will be targeted
> toward Experimental Status.

  I support adopting this document as a WG work item.

Review
Submitter name: Alan DeKok
Submitter email address: [e-mail]
Date first submitted: June 12, 2009
Reference:
Document: dynamic-discovery
Comment type: T
Priority: 1

Section 2.2: says:

   For a given NAI-based input realm,

NAI is... ?  The document doesn't define this term, and doesn't
reference RFC 4282 (NAI definition).

   ...
   the following algorithm is used to
   determine the AAA server to contact:

   1.   Transform input realm into punycode.
   ...

 This recommendation is correct for DNS, but is problematic in practice.
 The recommendations in RFC 4282 define how the above transformation is
done.  *BUT* those recommendations have serious problems.

  Would it be possible to simply rely on the DNS library to do the
correct conversion, and name resolution?  This document could then
describe how to mangle the NAI as a string, and that string then gets
passed to the DNS library for additional punycode mangling, and finally
lookup.


Section 3 talks about bidding down attacks.  These attacks can be
largely mitigated by additional per-client configuration on the server.
 See the DTLS document for discussion of this topic.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Jun 2009 15:56:03 +0000
Message-ID: <[e-mail]>
Date: Thu, 11 Jun 2009 17:55:24 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: Glen Zorn <[e-mail]>,  "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Open issues on the Crypto-Agility Requirements draft
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> My understanding is that many Diameter deployments use no security at all,
> making them much *less* secure than RADIUS.

  I've seen that, too.

> And these deployments are with NASes that are considerably more expensive
> than a mass market access point. 
> 
> I'm not sure whether the issue is operational (too hard to configure) or
> with the implementation. 
> 
> But something, somewhere, appears to have gone very wrong.

  It's harder to insert traffic into a TCP connection than to forge UDP
packets.  But it's not impossible.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Jun 2009 15:44:07 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_00f08dba-9960-4fc4-a881-9a26c34fa28f_"
From: Bernard Aboba <[e-mail]>
To: Glen Zorn <[e-mail]>, "David B. Nelson" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Open issues on the Crypto-Agility Requirements draft
Date: Thu, 11 Jun 2009 08:43:39 -0700
MIME-Version: 1.0

--_00f08dba-9960-4fc4-a881-9a26c34fa28f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> As I mentioned in the meeting=2C this is making a rather huge assumption =
about
> deployment issues over which the IETF has no control=3B in addition=2C th=
e
> experience WRT Diameter security deployment is not especially encouraging=
.

My understanding is that many Diameter deployments use no security at all=
=2C=20
making them much *less* secure than RADIUS.=20

And these deployments are with NASes that are considerably more expensive
than a mass market access point. =20

I'm not sure whether the issue is operational (too hard to configure) or=20
with the implementation. =20

But something=2C somewhere=2C appears to have gone very wrong.=20

--_00f08dba-9960-4fc4-a881-9a26c34fa28f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
&gt=3B As I mentioned in the meeting=2C this is making a rather huge assump=
tion about<br>&gt=3B deployment issues over which the IETF has no control=
=3B in addition=2C the<br>&gt=3B experience WRT Diameter security deploymen=
t is not especially encouraging.<br><br>My understanding is that many Diame=
ter deployments use no security at all=2C <br>making them much *less* secur=
e than RADIUS. <br><br>And these deployments are with NASes that are consid=
erably more expensive<br>than a mass market access point.&nbsp=3B <br><br>I=
'm not sure whether the issue is operational (too hard to configure) or <br=
>with the implementation.&nbsp=3B <br><br>But something=2C somewhere=2C app=
ears to have gone very wrong. <br></body>
</html>=

--_00f08dba-9960-4fc4-a881-9a26c34fa28f_--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Jun 2009 15:37:38 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_32fdd514-6876-41a3-b33e-c008a9b703ea_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>, "David B. Nelson" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Open issues on the Crypto-Agility Requirements draft
Date: Thu, 11 Jun 2009 08:37:04 -0700
MIME-Version: 1.0

--_32fdd514-6876-41a3-b33e-c008a9b703ea_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I would remind people that the focus here is on the requirements=2C not
the solution.=20

One of the reasons we do requirements documents is to determine when
we are done.=20

The requirements document has already taken so long that we are now in
danger of finishing work on solutions that may not meet the requirements.=20

So we need to ratchet up the rate of progress=2C so as to finish this docum=
ent
in the next few months.=20

One big issue that we need to close on his the requirements with respect
to downgrade attacks.=20

Assuming that legacy RADIUS is still supported in a NAS deployment=20
(likely to be true for a long time)=2C then it is possible for an attacker=
=20
to attempt to convince the RADIUS server (which we presume has been=20
upgraded) to utilize legacy RADIUS with MD5 security.=20

It seems to me that the only way to completely address this is by having
the NAS indicate support *within RADIUS*. =20

Use of dynamic discovery doesn't help without DNSSEC=2C since an attacker
can forge the RRs to force a downgrade.=20

Use of transport wrappers can't address it either if we assume that=20
attackers have the ability to cause arbitrary packets to be lost=2C and tha=
t
the NAS will drop down to ordinary RADIUS in the situation that transmissio=
n
layer security doesn't generate a response.=20

However=2C if we assume that MD5 hasn't yet been cracked=2C then even if th=
e
attacker convinces the NAS to use legacy RADIUS=2C if there is an attribute
that annouces what the NAS is capable of=2C when the server receives the
Access-Request=2C it can determine that something has gone wrong (e.g.
client claims to support crypto-agility=2C but the Access-Request didn't
use it).=20

As Glen pointed out=2C if sensitive information is provided in the Access-R=
equest=2C
you still have a problem (e.g. User-Password attribute could expose the use=
r
password).  But at least the issue can be discovered after the fact.=20

--_32fdd514-6876-41a3-b33e-c008a9b703ea_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
I would remind people that the focus here is on the requirements=2C not<br>=
the solution. <br><br>One of the reasons we do requirements documents is to=
 determine when<br>we are done. <br><br>The requirements document has alrea=
dy taken so long that we are now in<br>danger of finishing work on solution=
s that may not meet the requirements. <br><br>So we need to ratchet up the =
rate of progress=2C so as to finish this document<br>in the next few months=
. <br><br>One big issue that we need to close on his the requirements with =
respect<br>to downgrade attacks. <br><br>Assuming that legacy RADIUS is sti=
ll supported in a NAS deployment <br>(likely to be true for a long time)=2C=
 then it is possible for an attacker <br>to attempt to convince the RADIUS =
server (which we presume has been <br>upgraded) to utilize legacy RADIUS wi=
th MD5 security. <br><br>It seems to me that the only way to completely add=
ress this is by having<br>the NAS indicate support *within RADIUS*.&nbsp=3B=
 <br><br>Use of dynamic discovery doesn't help without DNSSEC=2C since an a=
ttacker<br>can forge the RRs to force a downgrade. <br><br>Use of transport=
 wrappers can't address it either if we assume that <br>attackers have the =
ability to cause arbitrary packets to be lost=2C and that<br>the NAS will d=
rop down to ordinary RADIUS in the situation that transmission<br>layer sec=
urity doesn't generate a response. <br><br>However=2C if we assume that MD5=
 hasn't yet been cracked=2C then even if the<br>attacker convinces the NAS =
to use legacy RADIUS=2C if there is an attribute<br>that annouces what the =
NAS is capable of=2C when the server receives the<br>Access-Request=2C it c=
an determine that something has gone wrong (e.g.<br>client claims to suppor=
t crypto-agility=2C but the Access-Request didn't<br>use it). <br><br>As Gl=
en pointed out=2C if sensitive information is provided in the Access-Reques=
t=2C<br>you still have a problem (e.g. User-Password attribute could expose=
 the user<br>password).&nbsp=3B But at least the issue can be discovered af=
ter the fact. <br></body>
</html>=

--_32fdd514-6876-41a3-b33e-c008a9b703ea_--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Jun 2009 15:21:47 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Dave Nelson'" <[e-mail]>
Cc: "'radext mailing list'" <[e-mail]>
Subject: RE: Open issues on the Crypto-Agility Requirements draft
Date: Thu, 11 Jun 2009 22:17:41 +0700
Message-ID: <00a901c9eaa7$ce5ae070$6b10a150$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcnqYX5kNIpzzsFSS9mX04eFqNXz3QAOnJUgAAKOLhA=
Content-Language: en-us

Dave Nelson [mailto://[e-mail]] write:

> Alan DeKok writes...
> 
> >   The alternative to TLS methods is something like the following
> > (created after about 10 minutes of thought).
> >
> >   1) Change MD5 to SHA-256
> >   2) Set the high bit in the RADIUS "code" field.
> 
> Well, the term "crypto-agility" implies that the protocol is not bound
> to
> any *single* cipher-suite.  Substituting SHA-256 for MD5 would not be a
> crypto-agility solution, IMO.  It would be a "fix" for internal RADIUS
> security until such time as SHA-256 becomes ineffective.

Right.

> One *could* make the argument that RADIUS doesn't need to be crypto-
> agile,
> all we need is a "fix" for the internal security mechanisms to tide us
> over
> until the transport wrapper security mechanisms are widely deployed.

As I mentioned in the meeting, this is making a rather huge assumption about
deployment issues over which the IETF has no control; in addition, the
experience WRT Diameter security deployment is not especially encouraging.

> In terms of revising the RADIUS Crypto-agility Requirements draft, it
> would
> be helpful to know whether the WG still thinks that RADIUS needs
> internal
> security that is indeed crypto-agile.

I think that it would make the protocol much more useful; OTOH, that seems
to be a non-goal of the WG & so is likely irrelevant.  As far as providing
simple, hop-by-hop security in a better way DTLS (presupposing that its
usage is properly specified _and_ it is widely deployed) is certainly more
than adequate.

...


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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Jun 2009 15:09:57 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>, "'Dave Nelson'" <[e-mail]>
Cc: "'radext mailing list'" <[e-mail]>
Subject: RE: Open issues on the Crypto-Agility Requirements draft
Date: Thu, 11 Jun 2009 22:05:23 +0700
Message-ID: <00a501c9eaa6$198cd320$4ca67960$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acnqob98PUReMBKyT5SBbQeQYgnmDQABAaqg
Content-Language: en-us

Alan DeKok [mailto://[e-mail]] writes:

...
 
>   It makes the "wiretap via RADIUS" issue more difficult.  But I've
> never understood we can securely allow third-parties to insert
> arbitrary
> traffic into an AAA exchange, and *without* having one of the parties
> notice that the traffic exists.

It's not; fortunately, that's not necessary.

...


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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Jun 2009 14:31:49 +0000
Message-ID: <[e-mail]>
Date: Thu, 11 Jun 2009 16:31:11 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Dave Nelson <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Open issues on the Crypto-Agility Requirements draft
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dave Nelson wrote:
> Well, the term "crypto-agility" implies that the protocol is not bound to
> any *single* cipher-suite.  Substituting SHA-256 for MD5 would not be a
> crypto-agility solution, IMO.  It would be a "fix" for internal RADIUS
> security until such time as SHA-256 becomes ineffective.

  Yes.

> One *could* make the argument that RADIUS doesn't need to be crypto-agile,
> all we need is a "fix" for the internal security mechanisms to tide us over
> until the transport wrapper security mechanisms are widely deployed.

  That's my opinion.  Everyone who has tried to fix RADIUS, or add
negotiation has gotten nowhere.

> In terms of revising the RADIUS Crypto-agility Requirements draft, it would
> be helpful to know whether the WG still thinks that RADIUS needs internal
> security that is indeed crypto-agile.

  Nothing.  Give up on ad-hoc security, and wrap the entire protocol in TLS.

  It makes the "wiretap via RADIUS" issue more difficult.  But I've
never understood we can securely allow third-parties to insert arbitrary
traffic into an AAA exchange, and *without* having one of the parties
notice that the traffic exists.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Jun 2009 14:00:48 +0000
From: "Dave Nelson" <[e-mail]>
To: "'radext mailing list'" <[e-mail]>
Subject: RE: Open issues on the Crypto-Agility Requirements draft
Date: Thu, 11 Jun 2009 10:00:07 -0400
Message-ID: <4C47BAE932794C2880E4F016A803AA52@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcnqYX5kNIpzzsFSS9mX04eFqNXz3QAOnJUg

Alan DeKok writes...

>   The alternative to TLS methods is something like the following
> (created after about 10 minutes of thought).
> 
>   1) Change MD5 to SHA-256
>   2) Set the high bit in the RADIUS "code" field.

Well, the term "crypto-agility" implies that the protocol is not bound to
any *single* cipher-suite.  Substituting SHA-256 for MD5 would not be a
crypto-agility solution, IMO.  It would be a "fix" for internal RADIUS
security until such time as SHA-256 becomes ineffective.

One *could* make the argument that RADIUS doesn't need to be crypto-agile,
all we need is a "fix" for the internal security mechanisms to tide us over
until the transport wrapper security mechanisms are widely deployed.

In terms of revising the RADIUS Crypto-agility Requirements draft, it would
be helpful to know whether the WG still thinks that RADIUS needs internal
security that is indeed crypto-agile.



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


Envelope-to: [e-mail]
Delivery-date: Thu, 11 Jun 2009 06:55:41 +0000
Message-ID: <[e-mail]>
Date: Thu, 11 Jun 2009 08:54:36 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Dave Nelson <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Open issues on the Crypto-Agility Requirements draft
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dave Nelson wrote:
> One of this issues we are facing is carving out a relatively narrow scope
> for crypto-agility work in RADIUS as opposed to fixing RADIUS security, or
> making RADIUS compliant with current day IETF protocol security
> requirements.  A clear scoping statement may avoid some of these comments.

  My $0.02: the crypto-agility work can be put into two rough classes.

1) Minor changes to RADIUS

2) TLS methods

  The goal with RadSec && DTLS is to fix RADIUS security.  RadSec can
address the inter-organization security, for organizations that find
IPSec too problematic.  DTLS can address intra-organization security, so
that we have an upgrade path for when MD5 is broken completely.

  The alternative to TLS methods is something like the following
(created after about 10 minutes of thought).

  1) Change MD5 to SHA-256
  2) Set the high bit in the RADIUS "code" field.

  i.e. packets with the high bit set use SHA-256 for security, rather
than MD5.  We would need a new "SHA-only" secret, too.  Everything else
in RADIUS is unchanged.

  This would provide a *simple* upgrade path, with minimal amounts of
work for all parties involved.  It will not address the issue that 100's
of 1000's of legacy devices don't support the new system.  It won't
address the issue that many vendors won't upgrade their firmware.

  I think TLS is a better solution.  It requires more work, but many
vendors already rely on OpenSSL for HTTPS traffic, so the code exists,
and is largely already on the machines.

  The alternative to SHA-256 or TLS would be public shame and
humiliation for this WG.  Once MD5 is broken, we would be responsible
for a security protocol that has *zero* security.  A much better
approach is to have a solution in place before the break.

  The onus then gets pushed back to the vendors.  Once MD5 is broken,
vendors will be subject to shame for not implementing this WG's solution
to the problem.  The vendors that care will upgrade.  The vendors that
don't care will knowingly accept the consequences of shipping broken
equipment.

  Let's also not forget that the majority of the AAA server market is
provided by only 5-6 vendors.  Those vendors are largely on this list,
and can choose to have an upgrade path available for when MD5 is broken.

> Also, Bernard has proposed some textr around a phase-in / transition plan
> that addresses some of the backwards compatibility and negotiation issues.

  See also the DTLS document, which addresses some of this.  It assumes
that the people running the NAS communicate with the people running the
AAA server.  It assumes that the upgrade path is negotiated *once*.
After that, the NAS is marked as "DTLS enabled", and the server refuses
to talk legacy RADIUS with the NA.  Changing the flag back requires
administrator intervention.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Wed, 10 Jun 2009 15:57:26 +0000
From: "Dave Nelson" <[e-mail]>
To: "'radext mailing list'" <[e-mail]>
Subject: Open issues on the Crypto-Agility Requirements draft
Date: Wed, 10 Jun 2009 11:56:43 -0400
Message-ID: <50C5A1D479B047E5811E487440A824F0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acnp5AyaDNTzvRB3QYG3pAMiTvjJxg==

(1) (Issues 274, 275) What do we need in terms of "hint and accept/reject"
vs. actual negotiation of cipher-suites?

(2) (Issue 274) Better text regarding the security considerations
surrounding key management.

(3) (Issue 275) How much backward compatibility with "legacy" RADIUS do we
need?

(4) (Issue 275) Clarify the text regarding the potential for new commands to
fundamentally change the RADIUS operational model".

We were attempting to prohibit "submarine" revisions to the RADIUS
architecture in the guise of crypto-agility solutions.  Since there seems to
be widespread confusion as to what this really means, we need to craft some
more explicit text.

(5) (Issue 303) Too much of the text is open to multiple interpretations.
Taken outside the context of the WG discussions, this document is hard to
follow.

I suspect that this draft needs a major re-write, paying close attention to
avoiding any implicit assumptions.  It was cobbled together from WG
presentations (slide decks) and list discussions.

(5) (Issue 303) "The document currently considers only "hop-by-hop" security
mechanisms, not any "end-to-end" protection (across proxies). I think this
is OK and perfectly reasonable -- but the document should say this, and
explain what this means for interpreting RFC 4962."

(6) (Issue 303) "Much of RFC 4962 is open to multiple interpretations, and
some parts of it can be read as requiring more than hop-by-hop security.
IMHO exactly the same parts can also be read as saying hop-by-hop can be
sufficient (when done properly), and I think this document should
explicitly say it's interpreting 4962 the latter way."

(7) (Issue 303) "Sometimes RADIUS is used to deliver keys (like EAP MSK)
that will be used (perhaps indirectly via additional key derivation steps)
to encrypt information that may be valuable for a long time.  Given this,
the document needs some discussion about "forward secrecy" (whether
revealing the long-term credential allows decrypting all past
communications), and if the conclusion is that crypto-agility solutions
don't need to support forward secrecy (even as optional-to-use feature),
explain the rationale behind this conclusion."

One of this issues we are facing is carving out a relatively narrow scope
for crypto-agility work in RADIUS as opposed to fixing RADIUS security, or
making RADIUS compliant with current day IETF protocol security
requirements.  A clear scoping statement may avoid some of these comments.

(8) (Issue 303) "Authenticating the RADIUS client and server will require
(manual) configuration of some kinds of credentials (currently, the RADIUS
shared secret). The document should say something about what kinds of
long-term authentication credentials (for RADIUS entities) the
crypto-agility solutions are expected to support."

(9) (Issue 303) "Section 4.2 says "Proposals MUST support replay protection.
The existing mechanisms for replay protection are considered adequate and
should be maintained." I think the latter sentence needs some clarification.
If the intent is to say replay protection provided by the current mechanisms
(i.e., basically none for Access-Request messages) is good enough, I would
disagree with that (or at least would expect to see an explanation why
that's the case for Access-Requests). If the intent is something else, the
text needs to be clearer."

(10) (Issue 303) "The document says proposals MUST support negotiation of
cryptographic algorithms. Does "negotiation" here mean picking which
algorithm to use in the protocol (RADIUS client and server figure out an
algorithm supported by both of them), or would negotiation between system
administrators meet this requirement?

This is the "hint and accept/reject" vs. negotiation issue again.

(11) (Issue 303) " Well... RADIUS certainly requires only O(n) keys, but on
the other hand, the amount of data encrypted with a single key is not
necessarily small (when considering the "value of the data" and time
aspects -- in terms of gigabytes, it's probably small compared to what
decent algorithms can handle)."

<snip>

"So, I think the conclusion here needs at the very least some
qualification and additional explanation."

OK. We need more/better text.

There are a few other elements to Issue 303, but many of them may be
resolved by a narrower/clearer scoping statement.

Also, Bernard has proposed some textr around a phase-in / transition plan
that addresses some of the backwards compatibility and negotiation issues.



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


Envelope-to: [e-mail]
Delivery-date: Wed, 10 Jun 2009 15:51:24 +0000
Message-ID: <27882354.50011244648982319.JavaMail.javamailuser@localhost>
Date: Wed, 10 Jun 2009 11:49:42 -0400 (EDT)
From: Dimdim Invitations <[e-mail]>
Reply-To: [e-mail]
To: [e-mail]
Subject: Your Dimdim Web Meeting has started
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Dimdim Web Meeting Invitation</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><style type="text/css">
<!--
body {
	margin-left: 0px;
	margin-top: 0px;
	margin-right: 0px;
	margin-bottom: 0px;
}
body,td,th {
	font-family: Lucida Grande;
	font-size: 9.0pt;
	color:#505252;
}
body a:link{
color:#436AB8; text-decoration:none;
}
body a:visited{
color:#436AB8; text-decoration:none;
}
body a:hover{
color:#436AB8; text-decoration:underline;
}
body a:active{
color:#436AB8; text-decoration:none;
}

body b{
color:#333333;
}

#joinbtn
{
	background-image:url(https://webmeeting.dimdim.com:443/portal/images/joinmeeting_btn.png);
	background-repeat:no-repeat;
	background-position: 0 0;
	width:138px;
	height: 33;
}

-->
            </style></head>
<body>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" bgcolor="#DBDBDB">
  <tr>
    <td>
<table width="550" border="0" align="center" cellpadding="0" cellspacing="0" bgcolor="#FFFFFF">
  <tr>
    <td colspan="2" bgcolor="#dbdbdb">&nbsp;<br>
      <br>
    <br></td>
  </tr>
  <tr>
    <td valign="top"><table width="100%" border="0" align="center" cellpadding="2" cellspacing="2">
      <tr>
        <td colspan="2"><div style="font-size:11.0pt;"><b><br>Hello!</b></div></td>
        <td align="right"><div style="3px;"><img src="https://webmeeting.dimdim.com:443/portal/images/bubbles.jpg" alt=""></div></td>
      </tr>
      <tr>
        <td colspan="3" align="right">&nbsp;</td>
      </tr>
      <tr>
        <td colspan="3">RADEXT has started the Dimdim Web Meeting. <a href="https://webmeeting.dimdim.com:443/portal/JoinForm.action?confKey=aboba&email=[e-mail]&asPresenter=false&meetingId=aefbcf54-a726-102c-a3c1-003048642bd7&attendeePwd=">To join the meeting, simply click here</a></td>
      </tr>
				<tr>
        <td colspan="3" align="center"><a href="https://webmeeting.dimdim.com:443/portal/JoinForm.action?confKey=aboba&email=[e-mail]&asPresenter=false&meetingId=aefbcf54-a726-102c-a3c1-003048642bd7&attendeePwd="><img src="https://webmeeting.dimdim.com:443/portal/images/joinmeeting_btn.png" alt="Join Meeting" border="0"></a></div></td>
      </tr>
      <tr>
		  <td colspan="3" align="left">You can also join by entering aboba at <a href="www.dimdim.com/join">www.dimdim.com/join</a></td>
		  </tr>
     <tr>
        <td width="6%">&nbsp;</td>
        <td colspan="2"><b>Meeting : </b>RADEXT</td>
        </tr>
      <tr>
        <td>&nbsp;</td>
        <td><b>Key: </b></td>
        <td>&nbsp;</td>
      </tr>
      <tr>
        <td>&nbsp;</td>
        <td><b>Dial In: </b>712-432-6139</td>
        <td><b>Pass Code: </b>226220</td>
      </tr>
	  <tr>
	    <td width="6%">&nbsp;</td><td width="49%"><b>Meeting Agenda: </b>http://www.drizzle.com/~aboba/RADEXT/jun-virtual-interim.txt</td>
	  </tr>

      <tr>
        <td colspan="3"><br>
          <b>Hint:</b> You don&#39;t need to be a member of Dimdim to attend this meeting. It&#39;s easy to join and get started, <a href="http://www.dimdim.com/registration/Dimdim_Signup.html">Click here to sign up for Dimdim Free.</a></td>
      </tr>
      <tr>
        <td colspan="3"><br>
          This is a personal meeting invitation, please do not forward.</td>
      </tr>
      <tr>
        <td colspan="3"><br>
          Sincerely,</td>
      </tr>
      <tr>
        <td colspan="3"><div style="font-size:11.0pt;"><strong>Your Dimdim Team</strong></div></td>
      </tr>
      <tr>
        <td colspan="3">&nbsp;</td>
      </tr>
      <tr>
        <td colspan="3"><div style="font-size:8.0pt;">*If the link above is broken (as can happen with some email systems) simply copy and paste the following URL into your browser address bar: https://webmeeting.dimdim.com:443/portal/JoinForm.action?confKey=aboba&email=[e-mail]&asPresenter=false&meetingId=aefbcf54-a726-102c-a3c1-003048642bd7&attendeePwd=</div></td>
      </tr>
      <tr>
        <td colspan="3">Note: Some email clients will split the above link into multiple lines.<br>
         &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Please make sure you copy the entire link (all lines) to join your meeting.</td>
      </tr>
    </table></td>
  </tr>
  <tr>
    <td colspan="2" bgcolor="#dbdbdb"><br>
   <div style="font-size:7.0pt;"> <strong>Copyright &copy; 2009 Dimdim.</b></strong> Meet freely.<br>
    	<br>	<a href="http://www.dimdim.com/tm">All Rights Reserved</a> / <a href="http://www.dimdim.com/ppolicy">Privacy Policy</a></div>
      <br>
<br></td>
  </tr>
</table>
   </td>
  </tr>
</table>

</body>
</html>



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


Envelope-to: [e-mail]
Delivery-date: Wed, 10 Jun 2009 05:06:08 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_67235628-c392-4edf-943f-fd3a9e610767_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: REMINDER:  RADEXT WG Interim Virtual Meeting, June 10, 2009
Date: Tue, 9 Jun 2009 22:05:08 -0700
MIME-Version: 1.0

--_67235628-c392-4edf-943f-fd3a9e610767_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The RADEXT WG Interim Virtual Meeting will be held tomorrow=2C June 10=2C 2=
009 from 9 AM - 11 AM PDT.=20

Please start off by entering the Jabber room=2C which will be hosted at rad=
[e-mail] and bringing up the RADEXT Issues Web page=2C which is =
located here:
http://www.drizzle.com/~aboba/RADEXT/

The Meeting Agenda is available here:
http://www.drizzle.com/~aboba/RADEXT/jun-virtual-interim.txt

Agenda slides are available here:
http://www.drizzle.com/~aboba/RADEXT/radext_virtual_interim_agenda.ppt

Instructions for use of the DimDim teleconference bridge and web conferenci=
ng facility are available here:
http://ops.ietf.org/lists/radiusext/2009/msg00233.html

See you online tomorrow!




--_67235628-c392-4edf-943f-fd3a9e610767_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
The RADEXT WG Interim Virtual Meeting will be held tomorrow=2C June 10=2C 2=
009 from 9 AM - 11 AM PDT. <br><br>Please start off by entering the Jabber =
room=2C which will be hosted at [e-mail] and bringing up the =
RADEXT Issues Web page=2C which is located here:<br>http://www.drizzle.com/=
~aboba/RADEXT/<br><br>The Meeting Agenda is available here:<br>http://www.d=
rizzle.com/~aboba/RADEXT/jun-virtual-interim.txt<br><br>Agenda slides are a=
vailable here:<br>http://www.drizzle.com/~aboba/RADEXT/radext_virtual_inter=
im_agenda.ppt<br><br>Instructions for use of the DimDim teleconference brid=
ge and web conferencing facility are available here:<br>http://ops.ietf.org=
/lists/radiusext/2009/msg00233.html<br><br>See you online tomorrow!<br><br>=
<br><table style=3D"border-top: 1px solid black=3B font-weight: bold=3B fon=
t-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"htt=
p://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"=
font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B">=
<span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=
=2C 85)=3B text-decoration: underline=3B"></span></a><br></td></tr></tbody>=
</table></body>
</html>=

--_67235628-c392-4edf-943f-fd3a9e610767_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 09 Jun 2009 16:57:37 +0000
Message-ID: <[e-mail]>
Date: Tue, 09 Jun 2009 18:55:13 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: [Fwd: New Version Notification for draft-dekok-radext-dtls-01]
Content-Type: multipart/mixed; boundary="------------040404040300010600080505"

This is a multi-part message in MIME format.
--------------040404040300010600080505
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

  I've updated the DTLS document prior to the call for tomorrow.  I
don't expect to discuss it in the call, but it might be relevant to the
RadSec discussions.

  Alan DeKok.

--------------040404040300010600080505
Content-Type: message/rfc822;
 name="New Version Notification for draft-dekok-radext-dtls-01.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename*0="New Version Notification for draft-dekok-radext-dtls-01.eml"

X-Account-Key: account3
X-Mozilla-Keys:                                                                                 
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])
	by liberty.deployingradius.com (Postfix) with ESMTP id E22771234097
	for <[e-mail]>; Tue,  9 Jun 2009 18:53:37 +0200 (CEST)
Received: by core3.amsl.com (Postfix, from userid 30)
	id 0B2E93A6BD6; Tue,  9 Jun 2009 09:53:30 -0700 (PDT)
From: IETF I-D Submission Tool <[e-mail]>
To: [e-mail]
Subject: New Version Notification for draft-dekok-radext-dtls-01 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Tue,  9 Jun 2009 09:53:31 -0700 (PDT)


A new version of I-D, draft-dekok-radext-dtls-01.txt has been successfuly submitted by Alan DeKok and posted to the IETF repository.

Filename:	 draft-dekok-radext-dtls
Revision:	 01
Title:		 DTLS as a Transport Layer for RADIUS
Creation_date:	 2009-06-09
WG ID:		 Independent Submission
Number_of_pages: 17

Abstract:
The RADIUS protocol [RFC2865] has limited support for authentication
and encryption of RADIUS packets.  The protocol transports data "in
the clear", although some parts of the packets can have "hidden"
content.  Packets may be replayed verbatim by an attacker, and
client-server authentication is based on fixed shared secrets.  This
document specifies how the Datagram Transport Layer Security (DTLS)
protocol may be used as a solution to these problems.  It also
describes how this proposal can co-exist with current RADIUS systems.
                                                                                  


The IETF Secretariat.





--------------040404040300010600080505--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 09 Jun 2009 16:49:13 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: FW: Protocol Action: 'Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management' to Proposed Standard 
Date: Tue, 9 Jun 2009 18:48:11 +0200
Message-ID: <[e-mail]>
Thread-Topic: Protocol Action: 'Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management' to Proposed Standard 
Thread-Index: AcnpIRl+buf/Wir2Sy2zcs2CU/NstwAANqlQ
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "radext mailing list" <[e-mail]>

 Congratulations to the editors, chairs and to the whole WG for the
approval of this document.=20

Regards,

Dan
=20

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of The IESG
Sent: Tuesday, June 09, 2009 7:40 PM
To: IETF-Announce
Cc: Internet Architecture Board; radext mailing list; radext chair; RFC
Editor
Subject: Protocol Action: 'Remote Authentication Dial-In User Service
(RADIUS) Authorization for Network Access Server (NAS) Management' to
Proposed Standard=20

The IESG has approved the following document:

- 'Remote Authentication Dial-In User Service (RADIUS) Authorization for

   Network Access Server (NAS) Management '
   <draft-ietf-radext-management-authorization-07.txt> as a Proposed
Standard

This document is the product of the RADIUS EXTensions Working Group.=20

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
zation-07.txt

Technical Summary

This document specifies RADIUS attributes for authorization and service
provisioning of Network Access Server (NAS) management.
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 specification
of a protected transport protocol.=20

Working Group Summary

There have been 2 WGLCs on the document. Much of the discussion on the
document has centered around the model for provisioning of protected
transports, as well as the different remote administration mechanisms
(secure and insecure) to be supported. There has also been discussion of
the relationship between Framed Management (introduced in this draft)
and the pseudo-TTY management model supported in RFC 2865.

Document Quality

The document was reviewed by the Juergen Schenwaelder for the ISMS WG
and by Vijay Gurbani for Gen-ART.=20

Personnel

Bernard Aboba is the PROTO-shepherd, and Dan Romascanu is the
responsible AD.

_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce

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


Envelope-to: [e-mail]
Delivery-date: Tue, 09 Jun 2009 16:41:38 +0000
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>,  radext mailing list <[e-mail]>,  radext chair <[e-mail]>
Subject: Protocol Action: 'Remote Authentication Dial-In User  Service (RADIUS) Authorization for Network Access Server (NAS)  Management' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Tue,  9 Jun 2009 09:40:21 -0700 (PDT)

The IESG has approved the following document:

- 'Remote Authentication Dial-In User Service (RADIUS) Authorization for 
   Network Access Server (NAS) Management '
   <draft-ietf-radext-management-authorization-07.txt> as a Proposed Standard

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

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-07.txt

Technical Summary

This document specifies RADIUS attributes for authorization and
service provisioning of Network Access Server (NAS) management.
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 
specification of a protected transport protocol. 

Working Group Summary

There have been 2 WGLCs on the document. Much of the discussion on
the document has centered around the model for provisioning of 
protected transports, as well as the different remote administration
mechanisms (secure and insecure) to be supported. There has also
been discussion of the relationship between Framed Management 
(introduced in this draft) and the pseudo-TTY management model 
supported in RFC 2865.

Document Quality

The document was reviewed by the Juergen Schenwaelder for the ISMS WG and
by Vijay Gurbani for Gen-ART. 

Personnel

Bernard Aboba is the PROTO-shepherd, and Dan Romascanu is the responsible
AD.


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


Envelope-to: [e-mail]
Delivery-date: Sun, 07 Jun 2009 13:05:40 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: FW: Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard 
Date: Sun, 7 Jun 2009 15:04:01 +0200
Message-ID: <[e-mail]>
Thread-Topic: Protocol Action: 'Carrying Location Objects in RADIUS and Diameter' to Proposed Standard 
Thread-Index: AcnmFRUp5Uq3IbPsR8KuYhAOimg0XABW0k8g
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: <[e-mail]>, "radext mailing list" <[e-mail]>, <[e-mail]>

=20

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of The IESG
Sent: Friday, June 05, 2009 10:37 PM
To: IETF-Announce
Cc: geopriv mailing list; geopriv chair; Internet Architecture Board;
RFC Editor
Subject: Protocol Action: 'Carrying Location Objects in RADIUS and
Diameter' to Proposed Standard=20

The IESG has approved the following document:

- 'Carrying Location Objects in RADIUS and Diameter '
   <draft-ietf-geopriv-radius-lo-24.txt> as a Proposed Standard

This document is the product of the Geographic Location/Privacy Working
Group.=20

The IESG contact persons are Cullen Jennings and Robert Sparks.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-24.txt

Technical Summary

 This document specifies RADIUS attributes for conveying access  network
location information, in both civic and geospatial location  formats,
along with access network ownership.  The distribution of  location
information is a privacy sensitive task.  Dealing with  mechanisms to
preserve the user's privacy is important and is  addressed throughout,
for various scenarios of location information  function within AAA.

WG Summary

 The WG reached solid consensus to advance this document after  a number
of iterations.  The WG had initial hesitation about  taking on the work,
because the RFC 4119 pidf_lo object could  not be used within RADIUS
attribute size constraints.  The  WG concerns were met with an eventual
functional compromise,  providing a mandated attribute with the pidf_lo
policy markers,  and opaque attributes pointing to the geopriv location
formats developed for DHCP which had constraints similar
 to RADIUS.  =20

 This document is a Critical Requirement for 3GPP.  Both the  GSM
Association and the ITU have specified Operator Namespace  Tokens for
use in this protocol.  (The document has customers).

Document Quality

 The protocol was reviewed in depth by both the GEOPRIV and  RADEXT
Working Groups.  RADEXT's formal issues list was  cleared.  GEOPRIV and
RADEXT had some overlapping  issues, especially location information
design,  and scenario evaluation.  The conclusion that location-  aware
AAA systems need to be able to implement the  formats and processing
found in the GEOPRIV documents  was very useful, because it meant that
GEOPRIV did not  have to intercept or anticipate any enhancements of the
RADIUS data model.=20

 The document is especially careful in projecting GEOPRIV's  paranoia
towards exposing location information.  Section
 8.3 contains a detailed review against the previously  defined
requirements related to this, and the Security  Considerations details
the use of security services  RADIUS provides as the using protocol to
meet requirements.

_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce

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


Envelope-to: [e-mail]
Delivery-date: Wed, 03 Jun 2009 18:08:58 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_1f3a53d2-0a6c-4a42-8d61-e5817d56142b_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: IETF 75 Agenda
Date: Wed, 3 Jun 2009 11:07:44 -0700
MIME-Version: 1.0

--_1f3a53d2-0a6c-4a42-8d61-e5817d56142b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


We're now getting started on setting the RADEXT WG Agenda for IETF 75.=20

If you would like time on the agenda=2C please send a request to Dave or my=
self.=20




--_1f3a53d2-0a6c-4a42-8d61-e5817d56142b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
We're now getting started on setting the RADEXT WG Agenda for IETF 75. <br>=
<br>If you would like time on the agenda=2C please send a request to Dave o=
r myself. <br><br><br><table style=3D"border-top: 1px solid black=3B font-w=
eight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr>=
<td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_Grea=
terGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-dec=
oration: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B col=
or: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><br><=
/td></tr></tbody></table></body>
</html>=

--_1f3a53d2-0a6c-4a42-8d61-e5817d56142b_--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 03 Jun 2009 10:03:38 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_95feaebc-e683-47f3-9efc-7ea4c6126289_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Virtual Interim Meeting presentations
Date: Wed, 3 Jun 2009 03:02:55 -0700
MIME-Version: 1.0

--_95feaebc-e683-47f3-9efc-7ea4c6126289_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


As noted in the previous message=2C the virtual interim meeting will focus =
on making progress on the Cryptoagility Requirements and Extended Attribute=
s documents.=20

In particular=2C the goal will be to discuss each of the outstanding issues=
 on these documents=2C and come up with proposed resolutions. =20

To help guide the group through each of the issues=2C we are asking that th=
e editors prepare slide presentations describing each of the open issues=2C=
 along with some potential next steps.  This could include potential altern=
ative approaches to resolving the issue=2C or (preferably) proposed text to=
 be discussed/massaged/improved during the virtual interim. =20

Slide presentations should be sent to the chairs no later than Monday=2C Ju=
ne 8 so that they can be made available on the Internet ahead of time.=20

In the case of the Cryptoagilty Requirements document=2C the open issues in=
clude the following:

RADIUS Crypto-Agility Requirements

      Issue Number

    Status
    Type
    Description
    Owner
 =20
    Issue 274
    Pending
    Technical
   =20
	Review
    Joe Salowey
=09
=09
    Issue 275
    Pending
    Technical
   =20
	Comments
    Glen Zorn
=09
=09
    Issue 303
    Pending
    Technical
   =20
=09
	Review
    Pasi Eronen

In the case of the Extended Attributes document=2C the open issues are as f=
ollows:

Extended=20
      Attributes=20
      Issue Number

    Status
    Type
    Description
    Owner
 =20
    Issue 251
    Pending
    Technical
   =20
	Review
    Bernard=20
      Aboba
=09
    Issue 290
    No Discussion
    Technical
   =20
	RFC=20
	4005bis Dependency
    Bernard=20
	Aboba
=09
 =20
    Issue 298
    No Discussion
    Technical
   =20
=09
	Extended Attributes Restriction
    Bernard=20
	Aboba
=09
 =20



 EMAILING FOR THE GOODER GOOD
Join me=

--_95feaebc-e683-47f3-9efc-7ea4c6126289_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
As noted in the previous message=2C the virtual interim meeting will focus =
on making progress on the Cryptoagility Requirements and Extended Attribute=
s documents. <br><br>In particular=2C the goal will be to discuss each of t=
he outstanding issues on these documents=2C and come up with proposed resol=
utions.&nbsp=3B <br><br>To help guide the group through each of the issues=
=2C we are asking that the editors prepare slide presentations describing e=
ach of the open issues=2C along with some potential next steps.&nbsp=3B Thi=
s could include potential alternative approaches to resolving the issue=2C =
or (preferably) proposed text to be discussed/massaged/improved during the =
virtual interim.&nbsp=3B <br><br>Slide presentations should be sent to the =
chairs no later than Monday=2C June 8 so that they can be made available on=
 the Internet ahead of time. <br><br>In the case of the Cryptoagilty Requir=
ements document=2C the open issues include the following:<br><br><table id=
=3D"table63" border=3D"1" height=3D"1" width=3D"761"><tbody><tr><td height=
=3D"34" width=3D"118"><b><font size=3D"4">RADIUS Crypto-Agility Requirement=
s</font></b><BR>
      <b><font size=3D"4">Issue Number</font></b><BR></td>
    <td height=3D"34" width=3D"143"><b><font size=3D"4">Status</font></b></=
td>
    <td height=3D"34" width=3D"78"><font size=3D"4"><b>Type</b></font></td>
    <td height=3D"34" width=3D"277"><b><font size=3D"4">Description</font><=
/b></td>
    <td height=3D"34" width=3D"116"><b><font size=3D"4">Owner</font></b></t=
d></tr>
  <tr>
    <td height=3D"62" width=3D"117">Issue 274</td>
    <td height=3D"34" width=3D"146">Pending</td>
    <td height=3D"62" width=3D"73">Technical</td>
    <td height=3D"62" width=3D"277">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
274">Review</a></td>
    <td height=3D"51" width=3D"117"><a href=3D"mailto:[e-mail]">J=
oe Salowey</a></td>
	</tr>
	<tr>
    <td height=3D"62" width=3D"117">Issue 275</td>
    <td height=3D"34" width=3D"146">Pending</td>
    <td height=3D"62" width=3D"73">Technical</td>
    <td height=3D"62" width=3D"277">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
275">Comments</a></td>
    <td height=3D"51" width=3D"117"><a href=3D"mailto:[e-mail]"=
>Glen Zorn</a></td>
	</tr>
	<tr>
    <td height=3D"62" width=3D"117">Issue 303</td>
    <td height=3D"34" width=3D"146">Pending</td>
    <td height=3D"62" width=3D"73">Technical</td>
    <td height=3D"62" width=3D"277">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues3.html#Issue%20=
303">
	Review</a></td>
    <td height=3D"51" width=3D"117"><a href=3D"mailto:[e-mail]=
">Pasi Eronen</a></td></tr></tbody></table><br><br>In the case of the Exten=
ded Attributes document=2C the open issues are as follows:<br><br><table id=
=3D"table62" border=3D"1" height=3D"1" width=3D"761"><tbody><tr><td height=
=3D"34" width=3D"117"><font size=3D"4"><strong>Extended=20
      Attributes</strong></font>=20
      <b><font size=3D"4">Issue Number</font></b><BR></td>
    <td height=3D"34" width=3D"146"><b><font size=3D"4">Status</font></b></=
td>
    <td height=3D"34" width=3D"84"><font size=3D"4"><b>Type</b></font></td>
    <td height=3D"34" width=3D"272"><b><font size=3D"4">Description</font><=
/b></td>
    <td height=3D"34" width=3D"112"><b><font size=3D"4">Owner</font></b></t=
d></tr>
  <tr>
    <td style=3D"height: 62px=3B" width=3D"117">Issue 251</td>
    <td style=3D"height: 62px=3B" width=3D"146">Pending</td>
    <td style=3D"height: 62px=3B" width=3D"84">Technical</td>
    <td style=3D"height: 62px=3B" width=3D"272">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
251">Review</a></td>
    <td style=3D"height: 62px=3B" width=3D"112"><a href=3D"mailto:Bernard_A=
[e-mail]">Bernard=20
      Aboba</a></td></tr>
	<tr>
    <td height=3D"62" width=3D"116">Issue 290</td>
    <td height=3D"34" width=3D"143">No Discussion</td>
    <td height=3D"62" width=3D"80">Technical</td>
    <td height=3D"62" width=3D"276">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
290">RFC=20
	4005bis Dependency</a></td>
    <td height=3D"51" width=3D"111"><a href=3D"mailto:bernard_aboba@hotmail=
.com">Bernard=20
	Aboba</a></td>
	</tr>
  <tr>
    <td height=3D"62" width=3D"116">Issue 298</td>
    <td height=3D"34" width=3D"143">No Discussion</td>
    <td height=3D"62" width=3D"80">Technical</td>
    <td height=3D"62" width=3D"276">
	<a href=3D"http://www.drizzle.com/%7Eaboba/RADEXT/radissues2.html#Issue%20=
298">
	Extended Attributes Restriction</a></td>
    <td height=3D"51" width=3D"111"><a href=3D"mailto:bernard_aboba@hotmail=
.com">Bernard=20
	Aboba</a></td>
	</tr>
  </tbody></table>
<br><BR><br><table style=3D"border-top: 1px solid black=3B font-weight: bol=
d=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a hre=
f=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" s=
tyle=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: n=
one=3B"><img style=3D"border-style: none=3B" src=3D"http://gfx1.hotmail.com=
/mail/w3/ltr/i_charity.gif" alt=3D"i'm"> EMAILING FOR THE GOODER GOOD<br><s=
pan style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C=
 85)=3B text-decoration: underline=3B">Join me</span></a></td></tr></tbody>=
</table></body>
</html>=

--_95feaebc-e683-47f3-9efc-7ea4c6126289_--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 03 Jun 2009 09:53:00 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_1e061ada-e951-48f0-b344-b36961421429_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: REMINDER: June 10 Interim Virtual Meeting
Date: Wed, 3 Jun 2009 02:52:27 -0700
MIME-Version: 1.0

--_1e061ada-e951-48f0-b344-b36961421429_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





On Wednesday=2C June 10=2C 2009=2C 09:00-11:00AM PDT (12:00-14:00 EDT)=2C R=
ADEXT WG will be having a virtual interim meeting=2C with the following age=
nda:

* Crypto-agility Requirements
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements

* Extended RADIUS Attributes
http://tools.ietf.org/html/draft-ietf-radext-extended-attributes

Virtual meeting information is available here:
http://www.drizzle.com/~aboba/RADEXT/jun-virtual-interim.txt


 EMAILING FOR THE GOODER GOOD
Join me=

--_1e061ada-e951-48f0-b344-b36961421429_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<hr>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<pre>On Wednesday=2C June 10=2C 2009=2C 09:00-11:00AM PDT (12:00-14:00 EDT)=
=2C RADEXT WG will be having a virtual interim meeting=2C with the followin=
g agenda:<br><br>* Crypto-agility Requirements<br><a rel=3D"nofollow" href=
=3D"http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirement=
s">http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements=
</a><br><br>* Extended RADIUS Attributes<br><a rel=3D"nofollow" href=3D"htt=
p://tools.ietf.org/html/draft-ietf-radext-extended-attributes">http://tools=
.ietf.org/html/draft-ietf-radext-extended-attributes</a><br><br>Virtual mee=
ting information is available here:<br><a rel=3D"nofollow" href=3D"http://w=
ww.drizzle.com/%7Eaboba/RADEXT/jun-virtual-interim.txt">http://www.drizzle.=
com/~aboba/RADEXT/jun-virtual-interim.txt</a><br></pre><br><br><table style=
=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe=
 UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.com/=
Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=
=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><img style=3D"=
border-style: none=3B" src=3D"http://gfx1.hotmail.com/mail/w3/ltr/i_charity=
.gif" alt=3D"i'm"> EMAILING FOR THE GOODER GOOD<br><span style=3D"padding: =
0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text-decoratio=
n: underline=3B">Join me</span></a></td></tr></tbody></table></body>
</html>=

--_1e061ada-e951-48f0-b344-b36961421429_--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 03 Jun 2009 09:44:15 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_626d6048-0636-4228-a22f-95a4de2abec1_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>, <[e-mail]>
Subject: RADEXT Milestone Update
Date: Wed, 3 Jun 2009 02:43:07 -0700
MIME-Version: 1.0

--_626d6048-0636-4228-a22f-95a4de2abec1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Please update the milestones for the RADEXT working group:

----------------------------------
Goals and Milestones:


Done  Updates to RFC 2618-2621 RADIUS MIBs submitted for publication=20
Done  SIP RADIUS authentication draft submitted as a Proposed=20
                Standard RFC=20
Done  RFC 2486bis submitted as a Proposed Standard RFC=20
Done  RFC 3576 MIBs submitted as an Informational RFC=20
Done  RADIUS VLAN and Priority Attributes draft submitted as a=20
                Proposed Standard RFC (reduced in scope)=20
Done  RADIUS Implementation Issues and Fixes draft submitted as an=20
                Informational RFC=20
Done  RADIUS Filtering Attributes draft submitted as a Proposed=20
                Standard RFC (split out from VLAN & Priority draft)=20
Done  RFC 3576bis submitted as an Informational RFC (split out from=20
                Issues & Fixes draft)=20
Done  RADIUS Redirection Attributes draft submitted as a Proposed=20
                Standard RFC (split out from VLAN & Priority draft)=20
Done  RADIUS Design Guidelines submitted as a Best Current Practice=20
                RFC=20
Done  RADIUS Management Authorization I-D submitted as a Proposed=20
                Standard RFC=20
Sep 2008  Extended Attributes I-D submitted as a Proposed Standard RFC=20
Sep 2008  RADIUS Crypto-agility Requirements submitted as an=20
                Informational RFC=20
Dec 2008  IEEE 802 Attributes I-D submitted as a Proposed Standard RFC=20
Jan 2009  Reliable Transport Profile for RADIUS I-D submitted as a=20
                Proposed Standard RFC=20
Mar 2009  Status-Server I-D submitted as a Proposed Standard RFC=20
Mar 2009  RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental=20
                RFC=20
Jun 2009  RADIUS Cryptographic Algorithm Agility I-D submitted as an=20
                Experimental RFC=20
Jun 2009  RADIUS over DTLS I-D submitted as an Experimental RFC=20

--_626d6048-0636-4228-a22f-95a4de2abec1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Please update the milestones for the RADEXT working group:<br><br>---------=
-------------------------<br><h2>Goals and Milestones:</h2>


<table><tbody><tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D=
"70">Done</td><td>&nbsp=3B&nbsp=3B</td><td>Updates to RFC 2618-2621 RADIUS =
MIBs submitted for publication </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>SIP RADIUS authentication draft submitted as a=
 Proposed=20
                Standard RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>RFC 2486bis submitted as a Proposed Standard R=
FC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>RFC 3576 MIBs submitted as an Informational RF=
C </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>RADIUS VLAN and Priority Attributes draft subm=
itted as a=20
                Proposed Standard RFC (reduced in scope) </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>RADIUS Implementation Issues and Fixes draft s=
ubmitted as an=20
                Informational RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>RADIUS Filtering Attributes draft submitted as=
 a Proposed=20
                Standard RFC (split out from VLAN &amp=3B Priority draft) <=
/td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>RFC 3576bis submitted as an Informational RFC =
(split out from=20
                Issues &amp=3B Fixes draft) </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>RADIUS Redirection Attributes draft submitted =
as a Proposed=20
                Standard RFC (split out from VLAN &amp=3B Priority draft) <=
/td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>RADIUS Design Guidelines submitted as a Best C=
urrent Practice=20
                RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Done</td>=
<td>&nbsp=3B&nbsp=3B</td><td>RADIUS Management Authorization I-D submitted =
as a Proposed=20
                Standard RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Sep 2008<=
/td><td>&nbsp=3B&nbsp=3B</td><td>Extended Attributes I-D submitted as a Pro=
posed Standard RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Sep 2008<=
/td><td>&nbsp=3B&nbsp=3B</td><td>RADIUS Crypto-agility Requirements submitt=
ed as an=20
                Informational RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Dec 2008<=
/td><td>&nbsp=3B&nbsp=3B</td><td>IEEE 802 Attributes I-D submitted as a Pro=
posed Standard RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Jan 2009<=
/td><td>&nbsp=3B&nbsp=3B</td><td>Reliable Transport Profile for RADIUS I-D =
submitted as a=20
                Proposed Standard RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Mar 2009<=
/td><td>&nbsp=3B&nbsp=3B</td><td>Status-Server I-D submitted as a Proposed =
Standard RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Mar 2009<=
/td><td>&nbsp=3B&nbsp=3B</td><td>RADSEC (RADIUS over TCP/TLS) draft submitt=
ed as an Experimental=20
                RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Jun 2009<=
/td><td>&nbsp=3B&nbsp=3B</td><td>RADIUS Cryptographic Algorithm Agility I-D=
 submitted as an=20
                Experimental RFC </td></tr>
<tr align=3D"left" valign=3D"top"><td valign=3D"top" width=3D"70">Jun 2009<=
/td><td>&nbsp=3B&nbsp=3B</td><td>RADIUS over DTLS I-D submitted as an Exper=
imental RFC </td></tr></tbody></table><br></body>
</html>=

--_626d6048-0636-4228-a22f-95a4de2abec1_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 01 Jun 2009 17:46:06 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-radext-management-authorization-07.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  1 Jun 2009 10:45: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		: Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
	Author(s)	: D. Nelson, G. Weber
	Filename	: draft-ietf-radext-management-authorization-07.txt
	Pages		: 25
	Date		: 2009-5-31
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-07.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-management-authorization-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--


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