Subject: submission of DNS-based dynamic discovery for RadSec (and DTLS)

From: Stefan Winter <[email-masked]>
Date: Fri, 27 Feb 2009 09:11:39 +0100

Hello,

I just uploaded the individual submission

"NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS"

( http://tools.ietf.org/html/draft-winter-dynamic-discovery-00 )
( http://tools.ietf.org/id/draft-winter-dynamic-discovery-00.txt )

with an intial attempt of

- fixing the old diameter underscore-with-A-records algorithm
- attempting to get internationalisation right (just a pathetic stub of what needs to be done)
- described use cases where NAIs might be unrelated to DNS domains (please comment...)
- reduced prose in the algorithm

This is just a rough start, and I guess many things need discussion at SFO.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Fri, 27 Feb 2009 08:12:46 +0000
Date: Fri, 27 Feb 2009 09:11:39 +0100
From: Stefan Winter <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: submission of DNS-based dynamic discovery for RadSec (and DTLS)

Hello,

I just uploaded the individual submission

"NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS"

( http://tools.ietf.org/html/draft-winter-dynamic-discovery-00 )
( http://tools.ietf.org/id/draft-winter-dynamic-discovery-00.txt )

with an intial attempt of

- fixing the old diameter underscore-with-A-records algorithm
- attempting to get internationalisation right (just a pathetic stub of what needs to be done)
- described use cases where NAIs might be unrelated to DNS domains (please comment...)
- reduced prose in the algorithm

This is just a rough start, and I guess many things need discussion at SFO.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Thu, 26 Feb 2009 17:23:31 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Comments on  "RADIUS Design Guidelines" document
Date: Thu, 26 Feb 2009 09:23:14 -0800

--_ab6632cf-3486-4839-a96c-c8cba327e2c9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> > OK.  The question still remains=2C though.  If an attribute is only use=
d in
> > Accounting-Request packets=2C does the argument against complex
> > attributes still apply?=20
>=20
>   My preference would be to say yes=2C especially where the contents of
> that attribute are interpreted by *later* policies on the server.

Now that we have RFC 5176=2C accounting data can be kept as "state" that is
later used to construct CoA/Disconnect-Requests.  Is this what you mean?

--_ab6632cf-3486-4839-a96c-c8cba327e2c9_
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 &gt=3B OK.  The question still remains=2C though.  If an attribute i=
s only used in<br>&gt=3B &gt=3B Accounting-Request packets=2C does the argu=
ment against complex<br>&gt=3B &gt=3B attributes still apply? <br>&gt=3B <b=
r>&gt=3B   My preference would be to say yes=2C especially where the conten=
ts of<br>&gt=3B that attribute are interpreted by *later* policies on the s=
erver.<br><br>Now that we have RFC 5176=2C accounting data can be kept as "=
state" that is<br>later used to construct CoA/Disconnect-Requests.&nbsp=3B =
Is this what you mean?<br><br><br></body>
</html>=

--_ab6632cf-3486-4839-a96c-c8cba327e2c9_--

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

Delivery-date: Thu, 26 Feb 2009 17:05:26 +0000
Date: Thu, 26 Feb 2009 18:05:11 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Comments on  "RADIUS Design Guidelines" document

Bernard Aboba wrote:
>> > Since [EXTEN] defines extensions to the standard RADIUS attribute
>> > space and this section is talking about VSAs, the reference is a bit
>> > confusing. Is the intent to suggest that VSAs other than type 0
>> > can also use the [EXTEN] format?
>>
>> Yes.
> 
> You might say, "with a different vendor-type" to make that clear.

  OK.  I'll add some text to that effect.

>> RFC 2869, Section 5.19 (Table of Attributes) indicates that
>> Connect-Info is permitted in Access-Request packets. Admins would like
>> to use this information to perform policy checks.
> 
> OK.  The question still remains, though.  If an attribute is only used in
> Accounting-Request packets, does the argument against complex
> attributes still apply? 

  My preference would be to say yes, especially where the contents of
that attribute are interpreted by *later* policies on the server.

  Alan DeKok.

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

Delivery-date: Thu, 26 Feb 2009 16:58:45 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Comments on  "RADIUS Design Guidelines" document
Date: Thu, 26 Feb 2009 08:58:03 -0800

--_a7cdaa28-eff1-4581-a693-4eb01b4958b3_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> > Also=2C the use of SHOULD NOT implies that there are circumstances in w=
hich
> > protocol changes or new commands can be standardized outside the IETF. =
Is
> > this what was intended?
>=20
>   No.  We can change this to a MUST NOT.
>=20
> > Since [EXTEN] defines extensions to the standard RADIUS attribute
> > space and this section is talking about VSAs=2C the reference is a bit
> > confusing.  Is the intent to suggest that VSAs other than type 0
> > can also use the [EXTEN] format?
>=20
>   Yes.

You might say=2C "with a different vendor-type" to make that clear.=20

>   RFC 2869=2C Section 5.19 (Table of Attributes) indicates that
> Connect-Info is permitted in Access-Request packets.  Admins would like
> to use this information to perform policy checks.

OK.  The question still remains=2C though.  If an attribute is only used in
Accounting-Request packets=2C does the argument against complex
attributes still apply? =20

--_a7cdaa28-eff1-4581-a693-4eb01b4958b3_
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>&gt=3B &gt=3B Also=2C the use of SHOULD NOT implies that there are circ=
umstances in which<br>&gt=3B &gt=3B protocol changes or new commands can be=
 standardized outside the IETF. Is<br>&gt=3B &gt=3B this what was intended?=
<br>&gt=3B <br>&gt=3B   No.  We can change this to a MUST NOT.<br>&gt=3B <b=
r>&gt=3B &gt=3B Since [EXTEN] defines extensions to the standard RADIUS att=
ribute<br>&gt=3B &gt=3B space and this section is talking about VSAs=2C the=
 reference is a bit<br>&gt=3B &gt=3B confusing.  Is the intent to suggest t=
hat VSAs other than type 0<br>&gt=3B &gt=3B can also use the [EXTEN] format=
?<br>&gt=3B <br>&gt=3B   Yes.<br><br>You might say=2C "with a different ven=
dor-type" to make that clear. <br><br>&gt=3B   RFC 2869=2C Section 5.19 (Ta=
ble of Attributes) indicates that<br>&gt=3B Connect-Info is permitted in Ac=
cess-Request packets.  Admins would like<br>&gt=3B to use this information =
to perform policy checks.<br><br>OK.&nbsp=3B The question still remains=2C =
though.&nbsp=3B If an attribute is only used in<br>Accounting-Request packe=
ts=2C does the argument against complex<br>attributes still apply?&nbsp=3B =
<br></body>
</html>=

--_a7cdaa28-eff1-4581-a693-4eb01b4958b3_--

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

Delivery-date: Thu, 26 Feb 2009 08:17:32 +0000
Date: Thu, 26 Feb 2009 09:16:29 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: Comments on  "RADIUS Design Guidelines" document

Bernard Aboba wrote:
...
> This document includes quotes from pre-5738 RFCs.  Should we be using
> the new "pre-5738" boilerplate?

  Likely, yes.

> This would seem to suggest that support for new authentication mechanisms
> can be standardized outside the IETF, as long as the guidelines are
> followed.

  If it's SDO specific...

> Also, the use of SHOULD NOT implies that there are circumstances in which
> protocol changes or new commands can be standardized outside the IETF. Is
> this what was intended?

  No.  We can change this to a MUST NOT.

> Since [EXTEN] defines extensions to the standard RADIUS attribute
> space and this section is talking about VSAs, the reference is a bit
> confusing.  Is the intent to suggest that VSAs other than type 0
> can also use the [EXTEN] format?

  Yes.

> s/discovery/discover/

  Fixed, thanks.

>    Even though the type is Text, the rest of the description indicates
>    that it is a complex attribute:
> 
> Since accounting data is typically only written to stable storage without
> examination, does the reasoning against complex attributes really apply
> here?

  RFC 2869, Section 5.19 (Table of Attributes) indicates that
Connect-Info is permitted in Access-Request packets.  Admins would like
to use this information to perform policy checks.

  e.g. Customer X has service Y, which doesn't permit them access to the
"high bandwidth" connection.

  Right now, they have to write regular expressions to parse the
Connect-Info attribute into multiple fields, and then apply the
bandwidth checks.

  This text was added as a direct result of seeing this problem occur in
the field.

  Alan DeKok.

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

Delivery-date: Wed, 25 Feb 2009 16:11:26 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Comments on  "RADIUS Design Guidelines" document
Date: Wed, 25 Feb 2009 08:10:43 -0800

--_565f5acc-1fea-4ff9-a45d-1679ff0ec532_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully=2C as they describe your rights
   and restrictions with respect to this document.

This document includes quotes from pre-5738 RFCs.  Should we be using
the new "pre-5738" boilerplate?

   It is RECOMMENDED that SDOs and vendors seek review of RADIUS
   attribute specifications from the IETF.  However=2C when specifications
   are SDO specific=2C re-use existing data types=2C and follow these
   guidelines=2C they do not require IETF review.

 . . .

   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes=2C or specification of attributes (such as Service-Type) that
   can be used to=2C in effect=2C provide new RADIUS commands require
   greater expertise and deeper review=2C as do changes to the RADIUS
   operational model=2C as described in Section 3.3 .  Such changes SHOULD
   NOT be undertaken outside the IETF and when handled within the IETF
   require "IETF Consensus" for adoption=2C as noted in [RFC3575] Section
   2.1.

This would seem to suggest that support for new authentication mechanisms
can be standardized outside the IETF=2C as long as the guidelines are follo=
wed.
Also=2C the use of SHOULD NOT implies that there are circumstances in which
protocol changes or new commands can be standardized outside the IETF. Is
this what was intended?

   Note that the Vendor type field in the recommended VSA format is only
   a single octet=2C like the RADIUS type field.  While this limitation
   results in an efficient encoding=2C there are situations in which a
   vendor or SDO will eventually wish to define more than 255
   attributes.  Also=2C an SDO can be comprised of multiple subgroups=2C
   each of whom can desire autonomy over the definition of attributes
   within their group.  In such a situation=2C a 16-bit Vendor type field
   would be more appropriate:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Length       |            Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor-Id (cont)           |           Vendor type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor length |   Attribute-Specific...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If additional functionality is required=2C the format defined in
   [EXTEN] SHOULD be used.

Since [EXTEN] defines extensions to the standard RADIUS attribute
space and this section is talking about VSAs=2C the reference is a bit
confusing.  Is the intent to suggest that VSAs other than type 0
can also use the [EXTEN] format?

        As a last resort=2C where
        the above techniques cannot be made to work=2C it may be possible
        to apply the techniques described in [RFC4821] to discovery the
        maximum supported RADIUS packet size on the path between a
        RADIUS client and a home server.

s/discovery/discover/

   Even though the type is Text=2C the rest of the description indicates
   that it is a complex attribute:

Since accounting data is typically only written to stable storage without
examination=2C does the reasoning against complex attributes really apply
here?

--_565f5acc-1fea-4ff9-a45d-1679ff0ec532_
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'>
&nbsp=3B&nbsp=3B Copyright (c) 2009 IETF Trust and the persons identified a=
s the<br>&nbsp=3B&nbsp=3B document authors.&nbsp=3B All rights reserved.<br=
><br>&nbsp=3B&nbsp=3B This document is subject to BCP 78 and the IETF Trust=
's Legal<br>&nbsp=3B&nbsp=3B Provisions Relating to IETF Documents in effec=
t on the date of<br>&nbsp=3B&nbsp=3B publication of this document (http://t=
rustee.ietf.org/license-info).<br>&nbsp=3B&nbsp=3B Please review these docu=
ments carefully=2C as they describe your rights<br>&nbsp=3B&nbsp=3B and res=
trictions with respect to this document.<br><br>This document includes quot=
es from pre-5738 RFCs.&nbsp=3B Should we be using<br>the new "pre-5738" boi=
lerplate?<br><br>&nbsp=3B&nbsp=3B It is RECOMMENDED that SDOs and vendors s=
eek review of RADIUS<br>&nbsp=3B&nbsp=3B attribute specifications from the =
IETF.&nbsp=3B However=2C when specifications<br>&nbsp=3B&nbsp=3B are SDO sp=
ecific=2C re-use existing data types=2C and follow these<br>&nbsp=3B&nbsp=
=3B guidelines=2C they do not require IETF review.<br><br>&nbsp=3B. . .<br>=
<br>&nbsp=3B&nbsp=3B The advice in this document applies to attributes used=
 to encode<br>&nbsp=3B&nbsp=3B service-provisioning or authentication data.=
&nbsp=3B RADIUS protocol<br>&nbsp=3B&nbsp=3B changes=2C or specification of=
 attributes (such as Service-Type) that<br>&nbsp=3B&nbsp=3B can be used to=
=2C in effect=2C provide new RADIUS commands require<br>&nbsp=3B&nbsp=3B gr=
eater expertise and deeper review=2C as do changes to the RADIUS<br>&nbsp=
=3B&nbsp=3B operational model=2C as described in Section 3.3 .&nbsp=3B Such=
 changes SHOULD<br>&nbsp=3B&nbsp=3B NOT be undertaken outside the IETF and =
when handled within the IETF<br>&nbsp=3B&nbsp=3B require "IETF Consensus" f=
or adoption=2C as noted in [RFC3575] Section<br>&nbsp=3B&nbsp=3B 2.1.<br><b=
r>This would seem to suggest that support for new authentication mechanisms=
<br>can be standardized outside the IETF=2C as long as the guidelines are f=
ollowed.<br>Also=2C the use of SHOULD NOT implies that there are circumstan=
ces in which<br>protocol changes or new commands can be standardized outsid=
e the IETF. Is<br>this what was intended?<br><br>&nbsp=3B&nbsp=3B Note that=
 the Vendor type field in the recommended VSA format is only<br>&nbsp=3B&nb=
sp=3B a single octet=2C like the RADIUS type field.&nbsp=3B While this limi=
tation<br>&nbsp=3B&nbsp=3B results in an efficient encoding=2C there are si=
tuations in which a<br>&nbsp=3B&nbsp=3B vendor or SDO will eventually wish =
to define more than 255<br>&nbsp=3B&nbsp=3B attributes.&nbsp=3B Also=2C an =
SDO can be comprised of multiple subgroups=2C<br>&nbsp=3B&nbsp=3B each of w=
hom can desire autonomy over the definition of attributes<br>&nbsp=3B&nbsp=
=3B within their group.&nbsp=3B In such a situation=2C a 16-bit Vendor type=
 field<br>&nbsp=3B&nbsp=3B would be more appropriate:<br><br>&nbsp=3B&nbsp=
=3B&nbsp=3B 0&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 1&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&nbs=
p=3B 2&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=
 3<br>&nbsp=3B&nbsp=3B&nbsp=3B 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 =
2 3 4 5 6 7 8 9 0 1<br>&nbsp=3B&nbsp=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>&nbsp=3B&nbsp=3B |&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B Type&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B |&nbsp=3B Length&n=
bsp=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&nbsp=3B&nbsp=3B&nbsp=3B Vendor-Id<br>=
&nbsp=3B&nbsp=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Vendor-=
Id (cont)&nbsp=3B&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&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B Vendor type&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B |<br>&nbsp=3B&nbsp=3B +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>&nbsp=3B&nbsp=3B | Vendor length |&n=
bsp=3B&nbsp=3B Attribute-Specific...<br>&nbsp=3B&nbsp=3B +-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br>&nbsp=3B&nbsp=3B If additional functiona=
lity is required=2C the format defined in<br>&nbsp=3B&nbsp=3B [EXTEN] SHOUL=
D be used.<br><br>Since [EXTEN] defines extensions to the standard RADIUS a=
ttribute<br>space and this section is talking about VSAs=2C the reference i=
s a bit<br>confusing.&nbsp=3B Is the intent to suggest that VSAs other than=
 type 0<br>can also use the [EXTEN] format?<br><br>&nbsp=3B&nbsp=3B&nbsp=3B=
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B As a last resort=2C where<br>&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B the above techniques cannot be =
made to work=2C it may be possible<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=
=3B&nbsp=3B&nbsp=3B to apply the techniques described in [RFC4821] to disco=
very the<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B maximu=
m supported RADIUS packet size on the path between a<br>&nbsp=3B&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B RADIUS client and a home server.<br><=
br>s/discovery/discover/<br><br>&nbsp=3B&nbsp=3B Even though the type is Te=
xt=2C the rest of the description indicates<br>&nbsp=3B&nbsp=3B that it is =
a complex attribute:<br><br>Since accounting data is typically only written=
 to stable storage without<br>examination=2C does the reasoning against com=
plex attributes really apply<br>here?<br><br><br><br><br><br><br><br><br><b=
lockquote style=3D"border-left: 2px solid rgb(0=2C 0=2C 255)=3B padding-lef=
t: 5px=3B margin-left: 5px=3B margin-right: 0px=3B"><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><br></td></tr></tbody></table></blockquot=
e></body>
</html>=

--_565f5acc-1fea-4ff9-a45d-1679ff0ec532_--

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

Delivery-date: Wed, 25 Feb 2009 14:17:26 +0000
Date: Wed, 25 Feb 2009 15:16:53 +0100
From: Alan DeKok <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
CC: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Last look at "RADIUS Design Guidelines" document

Romascanu, Dan (Dan) wrote:
> */Does the new version of the document address the issues raised by the
> Secdir review? /*

  Yes.

> *//* 
> */If the answer is positive it would be good to prompt the revised I-D
> to the reviewer and ask him to confirm that the issues were addressed by
> the document or clarified some other way. /*

  I'll send him a link.

  Alan DeKok.

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

Delivery-date: Wed, 25 Feb 2009 11:39:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Last look at "RADIUS Design Guidelines" document
Date: Wed, 25 Feb 2009 12:38:38 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9973D.9ABE0F3B
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Does the new version of the document address the issues raised by the
Secdir review?=20
=20
If the answer is positive it would be good to prompt the revised I-D to
the reviewer and ask him to confirm that the issues were addressed by
the document or clarified some other way.=20
=20
Thanks and Regards,
=20
Dan
=20

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba
	Sent: Tuesday, February 24, 2009 6:28 PM
	To: [email-masked]
	Subject: Last look at "RADIUS Design Guidelines" document
=09
=09
	This is an announcement of a "Last Look" at the RADIUS Design
Guidelines document, prior to sending this back to the IESG for
publication as a Best Current Practice (BCP).=20
=09
	The document is available for inspection here:
=09
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt
=09
	This "last look" will last until March 10, 2009.  Please send
comments to the RADEXT WG mailing list in the Issue format used by the
RADEXT Issues list (http://www.drizzle.com/~aboba/RADEXT/).=20
=09
=09
=09
=09
<http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood>=20
=09

------_=_NextPart_001_01C9973D.9ABE0F3B
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>.hmmessage P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY.hmmessage {
	FONT-SIZE: 10pt; FONT-FAMILY: Verdana
}
</STYLE>

<META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD>
<BODY class=3Dhmmessage>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D670343611-25022009>Does the new version of the document address =
the issues=20
raised by the Secdir review? </SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D670343611-25022009></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D670343611-25022009>If the answer is positive it would be good=20
to&nbsp;prompt&nbsp;the revised I-D to&nbsp;the reviewer and ask him to =
confirm=20
that the issues were addressed by the document or clarified some other =
way.=20
</SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D670343611-25022009></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D670343611-25022009>Thanks and =
Regards,</SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D670343611-25022009></SPAN></FONT></EM></STRONG>&nbsp;</DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D670343611-25022009>Dan</SPAN></FONT></EM></STRONG></DIV>
<DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff><SPAN=20
class=3D670343611-25022009></SPAN></FONT></EM></STRONG>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Bernard=20
  Aboba<BR><B>Sent:</B> Tuesday, February 24, 2009 6:28 PM<BR><B>To:</B> =

  [email-masked]<BR><B>Subject:</B> Last look at "RADIUS Design=20
  Guidelines" document<BR></FONT><BR></DIV>
  <DIV></DIV>This is an announcement of a "Last Look" at the RADIUS =
Design=20
  Guidelines document, prior to sending this back to the IESG for =
publication as=20
  a Best Current Practice (BCP). <BR><BR>The document is available for=20
  inspection=20
  =
here:<BR>http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.=
txt<BR><BR>This=20
  "last look" will last until March 10, 2009.&nbsp; Please send comments =
to the=20
  RADEXT WG mailing list in the Issue format used by the RADEXT Issues =
list=20
  (http://www.drizzle.com/~aboba/RADEXT/). <BR><BR><BR><BR>
  <TABLE=20
  style=3D"BORDER-TOP: black 1px solid; FONT-WEIGHT: bold; FONT-FAMILY: =
'Segoe UI',Tahoma,san-serif">
    <TBODY>
    <TR>
      <TD><A=20
        style=3D"FONT-SIZE: 9pt; COLOR: rgb(1,132,203); TEXT-DECORATION: =
none"=20
        =
href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGo=
od"><SPAN=20
        style=3D"PADDING-RIGHT: 24px; PADDING-LEFT: 24px; FONT-SIZE: =
8pt; PADDING-BOTTOM: 0px; COLOR: rgb(63,181,85); PADDING-TOP: 0px; =
TEXT-DECORATION: =
underline"></SPAN></A><BR></TD></TR></TBODY></TABLE></BLOCKQUOTE></BODY><=
/HTML>

------_=_NextPart_001_01C9973D.9ABE0F3B--

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

Delivery-date: Tue, 24 Feb 2009 16:28:57 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Last look at "RADIUS Design Guidelines" document
Date: Tue, 24 Feb 2009 08:27:40 -0800

--_ad9722fa-1b3a-417b-bb89-11aada963bef_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is an announcement of a "Last Look" at the RADIUS Design Guidelines do=
cument=2C prior to sending this back to the IESG for publication as a Best =
Current Practice (BCP).=20

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt

This "last look" will last until March 10=2C 2009.  Please send comments to=
 the RADEXT WG mailing list in the Issue format used by the RADEXT Issues l=
ist (http://www.drizzle.com/~aboba/RADEXT/).=20

--_ad9722fa-1b3a-417b-bb89-11aada963bef_
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 a "Last Look" at the RADIUS Design Guidelines do=
cument=2C prior to sending this back to the IESG for publication as a Best =
Current Practice (BCP). <br><br>The document is available for inspection he=
re:<br>http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt<=
br><br>This "last look" will last until March 10=2C 2009.&nbsp=3B Please se=
nd comments to the RADEXT WG mailing list in the Issue format used by the R=
ADEXT Issues list (http://www.drizzle.com/~aboba/RADEXT/). <br><br><br><br>=
<table style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-fa=
mily: '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"><spa=
n style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 8=
5)=3B text-decoration: underline=3B"></span></a><br></td></tr></tbody></tab=
le></body>
</html>=

--_ad9722fa-1b3a-417b-bb89-11aada963bef_--

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

Delivery-date: Tue, 24 Feb 2009 16:16:49 +0000
Date: Tue, 24 Feb 2009 17:16:36 +0100
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>,  Greg Weber <[email-masked]>
Subject: New version of the Design Guidelines document.

http://tools.ietf.org/id/draft-ietf-radext-design-06.txt

  I've submitted a new version of the design guidelines document, with
changes as noted earlier.

  Additional modifications:

- add a few sentences to the Security Considerations section as per
PHB's security review

- update boilerplate.

  Alan DeKok.

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

Delivery-date: Tue, 24 Feb 2009 16:15:30 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-design-06.txt 
Date: Tue, 24 Feb 2009 08:15:01 -0800 (PST)

--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           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-06.txt
	Pages           : 37
	Date            : 2009-02-24

This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs).

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

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

--NextPart--

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

Delivery-date: Tue, 24 Feb 2009 16:11:40 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: SECDIR Review of draft-ietf-radext-design-05 (fwd)
Date: Tue, 24 Feb 2009 08:10:54 -0800

--_430c2f5f-bb0c-4d4c-98f5-307a6ffc3edb_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

--Forwarded Message Attachment--
Subject: SECDIR Review of draft-ietf-radext-design-05
Date: Mon=2C 9 Feb 2009 14:04:59 -0800
From: [email-masked]
To: [email-masked]=3B [email-masked]=3B [email-masked]
CC: [email-masked]=3B [email-masked]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.=20
=20
The purpose of this document is to explain the workings of RADIUS attribute=
s for the benefit of those involved in the design of future RADIUS attribut=
e specifications. As such the document is very clear and provides advice th=
at will no doubt prove useful.
=20
The Security Considerations section could do with some additional work howe=
ver.
=20
The discussion of encryption of attributes is somewhat confusing. Mention i=
s made of encryption=2C followed by mention of MD5 and SHA1. While it was c=
ommon to describe the use of one way functions to obfusticate passwords as =
'encryption' in the 1980s=2C this is not current terminology and this needs=
 to be explained.
=20
Also I would like to see specific mention made of whatever provisions are m=
ade for message authentication in the protocol=2C if none=2C then this shou=
ld also be specified. This is a major concern in what is essentially a prot=
ocol that supports the authentication/authorization process.
=20
Finally=2C I would like to see some mention of the use of a secure tunnel s=
uch as IPSEC and which types of attributes might need superencryption withi=
n such a tunnel.=

--_430c2f5f-bb0c-4d4c-98f5-307a6ffc3edb_
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>--Forwarded Message Attachment--<br>Subject: SECDIR Review of draft-iet=
f-radext-design-05<br>Date: Mon=2C 9 Feb 2009 14:04:59 -0800<br>From: pbake=
[email-masked]<br>To: [email-masked]=3B [email-masked]=3B radiusex=
[email-masked]<br>CC: [email-masked]=3B [email-masked]<br><br>

<div><font size=3D"2" color=3D"#000000">I have reviewed this document as pa=
rt of the security directorate's<br>ongoing effort to review all IETF docum=
ents being processed by the<br>IESG.&nbsp=3B These comments were written pr=
imarily for the benefit of the<br>security area directors.&nbsp=3B Document=
 editors and WG chairs should treat<br>these comments just like any other l=
ast call comments.<font size=3D"3"> </font></font></div>
<div>&nbsp=3B</div>
<div>The purpose of this document is to explain the workings of RADIUS attr=
ibutes for the benefit of those involved in the design of future RADIUS att=
ribute specifications. As such the document is very clear and provides advi=
ce that will no doubt prove useful.</div>
<div>&nbsp=3B</div>
<div>The Security Considerations section could do with some additional work=
 however.</div>
<div>&nbsp=3B</div>
<div>The discussion of encryption of attributes is somewhat confusing. Ment=
ion is made of encryption=2C followed by mention of MD5 and SHA1. While it =
was common to describe the use of one way functions to obfusticate password=
s as 'encryption' in the 1980s=2C this is not current terminology and this =
needs to be explained.</div>
<div>&nbsp=3B</div>
<div>Also I would like to see specific mention made of whatever provisions =
are made for message authentication in the protocol=2C if none=2C then this=
 should also be specified. This is a major concern in what is essentially a=
 protocol that supports the&nbsp=3Bauthentication/authorization process.</d=
iv>
<div>&nbsp=3B</div>
<div>Finally=2C I would like to see some mention of the use of a secure tun=
nel such as IPSEC and which types of attributes might need superencryption =
within such a tunnel.</div></body>
</html>=

--_430c2f5f-bb0c-4d4c-98f5-307a6ffc3edb_--

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

Delivery-date: Mon, 23 Feb 2009 23:04:53 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Several ways you can publish I-Ds with pre 5378 content - TODAY (fwd)
Date: Mon, 23 Feb 2009 15:04:02 -0800

--_7507b4f9-22c9-4ed3-9db4-9004ad360dea_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

FYI.

> From: [email-masked]
> To: [email-masked]=3B [email-masked]
> Subject: Several ways you can publish I-Ds with pre 5378 content - TODAY
> Date: Mon=2C 23 Feb 2009 15:19:13 -0700
>=20
>=20
> Method 1: (Not recommended)
>=20
> Go read the BCP and Trust statement and edit your .txt to have the =20
> right text.
>=20
> Method 2: (Recommended for people using word template)
>=20
> Go look at a draft that did work=2C such as
> http://tools.ietf.org/html/draft-jennings-http-srv-01
>=20
> And copy the Copyright Notice section into your draft
>=20
> Method 3: XML2RFC approach recommended for folks that run xml2rfc =20
> locally
>=20
> Get the very hacked version at
> http://svn.resiprocate.org/rep/ietf-drafts/xml2rfc/1.34pre2-fluffy/xml2rf=
c.tcl
>=20
> This will soon be obsoleted when the real xml2rfc tool gets updated. =20
> Don't worry=2C Julian=2C Bill=2C and Marshal are working on that. They wi=
ll =20
> produce something much better than my hack of xml2rfc
>=20
> Set the ipr attribute in the <rfc> element to ipr=3D"pre5378Trust200902" =
=20
> and it will produce a txt file that id submission tool will accept.
>=20
> Method 4: XML2RFC approach for folks that run xml2rfc on the web
>=20
> Use the experimental version from http://xml.resource.org/experimental.ht=
ml=20
> . You can download the zip or tgz file on this page or use the online =20
> version at this page.
>=20
> Make sure you have
>=20
> <?rfc strict=3D"no" ?>
> somewhere above the <rfc> element.
> In the <rfc> element=2C set the ipr attribute to ipr=3D"trust200811"
> Change your abstract to use a note. Do this by changing
> <abstract> <t> This draft is about ... </t> </abstract>
> To
> <note title=3D"Abstract"><t> This draft is about ...</t> </note>
> And before this not insert a note like
> <note title=3D""> <t> This document may contain material from IETF =20
> Documents or IETF Contributions published or made publicly available =20
> before November 10=2C 2008. The person(s) controlling the copyright in =20
> some of this material may not have granted the IETF Trust the right to =20
> allow modifications of such material outside the IETF Standards =20
> Process. Without obtaining an adequate license from the person(s) =20
> controlling the copyright in such materials=2C this document may not be =
=20
> modified outside the IETF Standards Process=2C and derivative works of =20
> it may not be created outside the IETF Standards Process=2C except to =20
> format it for publication as an RFC or to translate it into languages =20
> other than English. </t> </note>
>=20
> You can seen the XML for an example I-D that does this at
> http://svn.resiprocate.org/rep/ietf-drafts/fluffy/example.xml
>=20
> That should work - good luck

--_7507b4f9-22c9-4ed3-9db4-9004ad360dea_
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'>
FYI.<br><br><br>&gt=3B From: [email-masked]<br>&gt=3B To: [email-masked]=
rg=3B [email-masked]<br>&gt=3B Subject: Several ways you can publish I-Ds wi=
th pre 5378 content - TODAY<br>&gt=3B Date: Mon=2C 23 Feb 2009 15:19:13 -07=
00<br>&gt=3B <br>&gt=3B <br>&gt=3B Method 1: (Not recommended)<br>&gt=3B <b=
r>&gt=3B Go read the BCP and Trust statement and edit your .txt to have the=
  <br>&gt=3B right text.<br>&gt=3B <br>&gt=3B Method 2: (Recommended for pe=
ople using word template)<br>&gt=3B <br>&gt=3B Go look at a draft that did =
work=2C such as<br>&gt=3B http://tools.ietf.org/html/draft-jennings-http-sr=
v-01<br>&gt=3B <br>&gt=3B And copy the Copyright Notice section into your d=
raft<br>&gt=3B <br>&gt=3B Method 3: XML2RFC approach recommended for folks =
that run xml2rfc  <br>&gt=3B locally<br>&gt=3B <br>&gt=3B Get the very hack=
ed version at<br>&gt=3B http://svn.resiprocate.org/rep/ietf-drafts/xml2rfc/=
1.34pre2-fluffy/xml2rfc.tcl<br>&gt=3B <br>&gt=3B This will soon be obsolete=
d when the real xml2rfc tool gets updated.  <br>&gt=3B Don't worry=2C Julia=
n=2C Bill=2C and Marshal are working on that. They will  <br>&gt=3B produce=
 something much better than my hack of xml2rfc<br>&gt=3B <br>&gt=3B Set the=
 ipr attribute in the &lt=3Brfc&gt=3B element to ipr=3D"pre5378Trust200902"=
  <br>&gt=3B and it will produce a txt file that id submission tool will ac=
cept.<br>&gt=3B <br>&gt=3B Method 4: XML2RFC approach for folks that run xm=
l2rfc on the web<br>&gt=3B <br>&gt=3B Use the experimental version from htt=
p://xml.resource.org/experimental.html <br>&gt=3B . You can download the zi=
p or tgz file on this page or use the online  <br>&gt=3B version at this pa=
ge.<br>&gt=3B <br>&gt=3B Make sure you have<br>&gt=3B <br>&gt=3B &lt=3B?rfc=
 strict=3D"no" ?&gt=3B<br>&gt=3B somewhere above the &lt=3Brfc&gt=3B elemen=
t.<br>&gt=3B In the &lt=3Brfc&gt=3B element=2C set the ipr attribute to ipr=
=3D"trust200811"<br>&gt=3B Change your abstract to use a note. Do this by c=
hanging<br>&gt=3B &lt=3Babstract&gt=3B &lt=3Bt&gt=3B This draft is about ..=
. &lt=3B/t&gt=3B &lt=3B/abstract&gt=3B<br>&gt=3B To<br>&gt=3B &lt=3Bnote ti=
tle=3D"Abstract"&gt=3B&lt=3Bt&gt=3B This draft is about ...&lt=3B/t&gt=3B &=
lt=3B/note&gt=3B<br>&gt=3B And before this not insert a note like<br>&gt=3B=
 &lt=3Bnote title=3D""&gt=3B &lt=3Bt&gt=3B This document may contain materi=
al from IETF  <br>&gt=3B Documents or IETF Contributions published or made =
publicly available  <br>&gt=3B before November 10=2C 2008. The person(s) co=
ntrolling the copyright in  <br>&gt=3B some of this material may not have g=
ranted the IETF Trust the right to  <br>&gt=3B allow modifications of such =
material outside the IETF Standards  <br>&gt=3B Process. Without obtaining =
an adequate license from the person(s)  <br>&gt=3B controlling the copyrigh=
t in such materials=2C this document may not be  <br>&gt=3B modified outsid=
e the IETF Standards Process=2C and derivative works of  <br>&gt=3B it may =
not be created outside the IETF Standards Process=2C except to  <br>&gt=3B =
format it for publication as an RFC or to translate it into languages  <br>=
&gt=3B other than English. &lt=3B/t&gt=3B &lt=3B/note&gt=3B<br>&gt=3B <br>&=
gt=3B You can seen the XML for an example I-D that does this at<br>&gt=3B h=
ttp://svn.resiprocate.org/rep/ietf-drafts/fluffy/example.xml<br>&gt=3B <br>=
&gt=3B That should work - good luck<br></body>
</html>=

--_7507b4f9-22c9-4ed3-9db4-9004ad360dea_--

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

Delivery-date: Wed, 18 Feb 2009 17:26:32 +0000
From: "Dave Nelson" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: One SEC AD's review of draft-ietf-radext-crypto-agility-requirements-01
Date: Wed, 18 Feb 2009 12:25:49 -0500

Pasi Eronen writes...

> The outcome I'd really like to avoid is having IESG first approve
> these requirements, and then getting a solution draft that in WG's
> opinion meets the requiremnts, but is very different from how IESG
> understood the requirements. So, the main intent of the remaining
> comments is reducing the likelihood of this happening.

Exactly!

I can propose some text to resolve the editorial issues -- lack of clarity
because of poor wording.  I'll need assistance from the WG in resolving the
substantive issues, such as whether RADIUS should have a true negotiation
mechanism for cipher-suites and whether RADIUS needs forward secrecy or to
be retrofitted with Automated Key Management.

WG members, please comment on the issues that Pasi has raised in his review,
ASAP.  If we get some good discussion going, we could have a -02 version of
the draft prior to IETF 74 (coming up real soon now).

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

Delivery-date: Wed, 18 Feb 2009 14:34:07 +0000
Date: Wed, 18 Feb 2009 15:33:59 +0100
From: Stefan Winter <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  "Joseph Salowey (jsalowey)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Issue 282: backward compatibility, proposed text

Alan DeKok schrieb:
> Bernard Aboba wrote:
>   
>> Question:  At various points we have talked about separating out the
>> material on DNS SRV-based discovery.  How does this recommendation
>> relate to that?  For example, assuming that DNS SRV RR queries aren't
>> protected by DNSSEC, couldn't the discovery process generate a "fallback
>> to classic RADIUS"?
>>     
>
>   Yes.
>   

*If* classic RADIUS were to be specified with DNS SRV discovery, yes.
AFAIK, there are no plans to do that - only TLS and DTLS. It would be
rather tricky to do so, because the shared secret would need to be
discovered, and the DNS channel offers no adequate protection for such a
keying material exchange, AFAICT.

>> (e.g. if only the FQDN of the server is provided and
>> DNS SRV RR queries are used to determine whether RADSEC and/or RADIUS
>> was supported).   For example, couldn't an attacker spoof a response to
>> the DNS SRV RR query and convince the querier that only RADIUS was
>> available? 
>>     
>
>   Systems should be implemented so that administrators can require
> RADSEC for particular home servers.  This turns the down-bidding attack
> into a DoS attack, as the proxy will refuse to connect over plain RADIUS.
>   

That sounds good. Configuration details are not a part of the on-wire
protocol though, so: does it make sense to recommend this in the draft?
This sounds like an issue to mention in the dynamic discovery draft
itself (see below).

>> And overall, I'm curious about where the text relating to DNS discovery
>> is going/belongs.  In the draft?  Outside of it in a separate document? 
>> None of these?
>>     
>
>   In a separate draft.  DTLS and normal RADIUS could be using dynamic
> discovery, too.
>   

I have a stub of a draft on my disk, which is basically copy&paste from
the contents of the earlier radsec-02 revision. The issues discussed in
this thread (+i18n) should/will end up there.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Wed, 18 Feb 2009 14:33:16 +0000
Date: Wed, 18 Feb 2009 14:30:12 +0100
From: Stefan Winter <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>,  "[email-masked]" <[email-masked]>
Subject: Re: Issue 282: backward compatibility, proposed text

Hi,

> Question:  At various points we have talked about separating out the
> material on DNS SRV-based discovery.  How does this recommendation
> relate to that?  For example, assuming that DNS SRV RR queries aren't
> protected by DNSSEC, couldn't the discovery process generate a
> "fallback to classic RADIUS"? (e.g. if only the FQDN of the server is
> provided and DNS SRV RR queries are used to determine whether RADSEC
> and/or RADIUS was supported).   For example, couldn't an attacker
> spoof a response to the DNS SRV RR query and convince the querier that
> only RADIUS was available?

DNSSEC could secure the SRV response, yes. The overall security of
discovery also depends on the subsequent A/AAAA lookups, and I think
there's a loophole DNSSEC can't close. Which would in turn mean that
adding DNSSEC doesn't completely secure the process in the end, and so
manual configuration of a desired minimum security level is the only
proper answer. In the (yet unpublished) dynamic discovery draft, I've
just scribbled down the following (the second para relating to bidding
down):

   When using DNS without security, the replies to NAPTR, SRV and A/AAAA
   requests as described in section Section 2 can not be trusted.
   RADIUS transports have an out-of-DNS-band means to verify that the
   discovery attempt led to the intended target (TLD/DTLS: ceritifcate
   verification or TLS shared secret ciphers; UDP/TCP: the RADIUS shared
   secret) and are safe from DNS-based redirection attacks.  [Note:
   assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT
   deliver the shared secret in the DNS response!]

   The discovery process is always susceptible to bidding down attacks
   if a realm has SRV records for RADIUS/UDP and/or RADIUS/TCP as well
   as for RADIUS/TLS and/or RADIUS/DTLS.  While the SRV query will
   expose both transports, an attacker in the routing path might
   suppress the subsequent A/AAAA results for the TLS or DTLS peer and
   trick the inititating peer into using the weakly protected UDP or TCP
   transports.  The use of DNSSEC can not fully mitigate this attack,
since it
   does not provide a means to detect packet suppression.  The only way
   to disable such bidding down attacks is by intiating connections only
   to the peer(s) which match or exceed a configured minimum security
   level.  An implementation SHOULD provide a means to configure the
   administratively desired minimum security level.

Does that make sense?

Greetings,

Stefan Winter

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

Delivery-date: Wed, 18 Feb 2009 14:32:18 +0000
Date: Wed, 18 Feb 2009 09:31:25 -0500
From: "David B. Nelson" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Design Guidelines document

Bernard Aboba wrote:
> Great.   I guess we now have boilerplate to post drafts?
We know what the boilerplate ought to be, but as far as I can tell, we 
don't yet have automated tool support in xml2rfc.  Let's put it this 
way, there is no new version announced on the web site that supports 
February 2009 boilerplate text.  I am also following the xlm2rfc mailing 
list.

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

Delivery-date: Wed, 18 Feb 2009 13:25:53 +0000
Date: Wed, 18 Feb 2009 14:25:12 +0100
From: Stefan Winter <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "'Joseph Salowey (jsalowey)'" <[email-masked]>,  [email-masked]
Subject: Re: Issue 282: cipher suites, discussion needed

Hi,

>> "RADSEC implementation MUST support he mandatory to implement cipher
>> suites specified in TLS.  For purposes of compatibility with some
>> current deployments implementations SHOULD support
>> TLS_RSA_WITH_RC4_128_SHA as well."
>>     
>
> Seems like a good idea to me.
>   

Great! I'll update the document with this text and will likely post a
new revision before the SF cutoff date.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Wed, 18 Feb 2009 11:15:00 +0000
From: <[email-masked]>
To: <[email-masked]>
Date: Wed, 18 Feb 2009 12:13:39 +0100
Subject: One SEC AD's review of draft-ietf-radext-crypto-agility-requirements-01
Accept-Language: en-US
acceptlanguage: en-US

Hi,

At Dan Romascanu's request, I've taken an early look at draft-ietf-
radext-crypto-agility-requirements-01. This was probably a good idea
from Dan, since if I had sent a DISCUSS this long at IESG evaluation
time, the WG might have (somewhat justifiably) suggested doing some
rubber-hose discuss clearing on a dark San Francisco back alley :-)

Overall comment:

Currently, much of the text in this draft seems to be open to multiple
interpretations. It's possible that the WG members agree on the
interpretation (but it's also possible that they only *think* they
agree...), but someone who hasn't participated in the WG discussions
will be somewhat confused.

Personally, I'm not really a big fan of requirements RFCs (and would
rather spend the energy in getting the solutions right)... but the
AAA space certainly has some history of requirements open to multiple
interpretations (including the infamous "Housley criteria" that became
RFC 4962), and a special branch of hermeneutics devoted to interpreting
them in ways that were not always very productive :-) [and BTW -- I've
certainly done some of that myself...]

The outcome I'd really like to avoid is having IESG first approve
these requirements, and then getting a solution draft that in WG's
opinion meets the requiremnts, but is very different from how IESG
understood the requirements. So, the main intent of the remaining
comments is reducing the likelihood of this happening.

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

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

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. (And once the
document has this explanation, you might want to run it by some other
ADs, too -- e.g. Tim and Russ)

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,
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.

Authentication/long-term credentials:

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.

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

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., 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.

Meaning of negotiation:

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?

I assume the WG has rough consensus about what this means, and
ordinarily, I would have automatically assumed it's the former.  But
some earlier proposals in this space have supported only the latter
kind (which does provide some kind of algorithm agility -- it's better
than hardcoding MD5 -- but could mean synchronized manual work for
every transition)...

Automated Key Management:

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).

And if you anyway support negotiating the algorithms (in the
protocol), generating a fresh session key may not be that much extra
effort, and may be needed anyway since the key can depend on the
selected algorithm (if you negotiate 256-bit AES, you need a 256-bit
key; if it's 3DES, 168 bits, 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), but
other approaches to replays are certainly feasible.

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

So, 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, *and* replay protection is
solved in certain way, *and* the solution can ensure that the
negotiated algorithms get keys appropriate for them, *and* the
solution can ensure that two algorithms don't use the same key, then
you might get away with no AKM. But even then, AKM might be less work.

Compromise of legacy shared secret:

Section 4.2 says "Crypto-agility solutions MUST avoid security
compromise, 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, this requirement could be very difficult
to meet (perhaps impossible).

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.

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.

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, or if the attacker doesn't have
complete control over the communications). And the administrator could
always configure just the "new shared secret", if he/she knows that
the peer supports it.

Backward compatibility/negotiation:

Section 4.3 says "Solutions to the problem MUST demonstrate backward
compatibility with existing RADIUS implementations.  That is, a
crypto-agility solution needs to be able to send packets that a legacy
RADIUS client or server will receive and process successfully.
Similarly, 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, but currently, 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, 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, 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), the text should say so.

"Operational model"?

Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes
to the RADIUS operational model, 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"), 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, perhaps the should
be rephased something like "When using long-term shared secrets for
authentication, crypto-agility solutions SHOULD NOT require more
operations and management work than the current solutions."

"RADIUS service?"

Section 4.3 says "For example, 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, "service" is defined as the
service provided by the NAS to the user, but that definition doesn't
seem applicable here.)

Best regards,
Pasi

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

Delivery-date: Tue, 17 Feb 2009 23:39:14 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Design Guidelines document
Date: Tue, 17 Feb 2009 15:38:25 -0800

--_0655c766-b377-4186-a480-aee44d8e91c3_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Great.   I guess we now have boilerplate to post drafts?

Also=2C could you post PHB's review to the list?

> Date: Tue=2C 17 Feb 2009 11:39:17 +0100
> From: [email-masked]
> To: [email-masked]
> Subject: Design Guidelines document
>=20
>   Hearing no major objections to the changes posted on
> http://ietf.freeradius.org/=2C I will shortly submit an updated version.
> This version will include comments coming from PHB's review.
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--_0655c766-b377-4186-a480-aee44d8e91c3_
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'>
Great.&nbsp=3B&nbsp=3B I guess we now have boilerplate to post drafts?<br><=
br>Also=2C could you post PHB's review to the list?<br><br>&gt=3B Date: Tue=
=2C 17 Feb 2009 11:39:17 +0100<br>&gt=3B From: [email-masked]<br=
>&gt=3B To: [email-masked]<br>&gt=3B Subject: Design Guidelines doc=
ument<br>&gt=3B <br>&gt=3B   Hearing no major objections to the changes pos=
ted on<br>&gt=3B http://ietf.freeradius.org/=2C I will shortly submit an up=
dated version.<br>&gt=3B This version will include comments coming from PHB=
's review.<br>&gt=3B <br>&gt=3B   Alan DeKok.<br>&gt=3B <br>&gt=3B --<br>&g=
t=3B to unsubscribe send a message to [email-masked] with<b=
r>&gt=3B the word 'unsubscribe' in a single line as the message text body.<=
br>&gt=3B archive: &lt=3Bhttp://psg.com/lists/radiusext/&gt=3B<br></body>
</html>=

--_0655c766-b377-4186-a480-aee44d8e91c3_--

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

Delivery-date: Tue, 17 Feb 2009 12:43:20 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Joseph Salowey \(jsalowey\)'" <[email-masked]>, "'Stefan Winter'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Issue 282: cipher suites, discussion needed
Date: Tue, 17 Feb 2009 19:42:22 +0700

Joseph Salowey [mailto:[email-masked]] writes:

> You could just leave this to the TLS specification.  For version 1.0
> and 1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it is
> TLS_RSA_WITH_AES_128_CBC_SHA.   If it is common today for
> implementations also to implement the RC4 ciphers you can have that as
> a recommendation as well.  Something like:
>=20
> "RADSEC implementation MUST support he mandatory to implement cipher
> suites specified in TLS.  For purposes of compatibility with some
> current deployments implementations SHOULD support
> TLS_RSA_WITH_RC4_128_SHA as well."

Seems like a good idea to me.

>=20
> Cheers,
>=20
> Joe
>=20
> > -----Original Message-----
> > From: Stefan Winter [mailto:[email-masked]]
> > Sent: Wednesday, February 11, 2009 1:13 AM
> > To: Joseph Salowey (jsalowey)
> > Cc: [email-masked]
> > Subject: Issue 282: cipher suites, discussion needed
> >
> > Hi,
> >
> > > 3.  I'm not sure I understand the choice of ciphersuites.
> > >
> > > Why is TLS_RSA_WITH_RC4_128_SHA recommended?  It seems that
> > it would
> > > be much preferable to use AES or 3DES?
> > >
> >
> > I could use a little help here. Is there anyone willing to
> > investigate cipher suite selection? An alternative would be
> > to follow the path of e.g. the EAP tunnel reqs, which cite
> > NIST references for acceptable cipher suites...
> >
> > Greetings,
> >
> > Stefan Winter
> >
> > --
> > Stefan WINTER
> > Ingenieur de Recherche
> > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education
> > Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi
> > L-1359 Luxembourg
> >
> > Tel: +352 424409 1
> > Fax: +352 422473
> >
> >
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Tue, 17 Feb 2009 10:40:07 +0000
Date: Tue, 17 Feb 2009 11:39:17 +0100
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: Design Guidelines document

  Hearing no major objections to the changes posted on
http://ietf.freeradius.org/, I will shortly submit an updated version.
This version will include comments coming from PHB's review.

  Alan DeKok.

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

Delivery-date: Tue, 17 Feb 2009 07:32:06 +0000
From: Bernard Aboba <[email-masked]>
To: Glen Zorn <[email-masked]>, Russ Housley <[email-masked]>, <[email-masked]>
Subject: RE: New Version Notification -  draft-ietf-geopriv-radius-lo-22.txt
Date: Mon, 16 Feb 2009 23:31:43 -0800

--_42c4f0fc-d6f6-466f-90c8-a41e1eff7c88_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Watching the latest review comments=2C I wasn't sure whether the issue rela=
ting to request for location data had been resolved. The draft states that =
the RADIUS server can request location-data if the client indicated that it=
 was location capable.  However=2C  since the location data provided was to=
 be considered opaque=2C it can't check whether the actual data corresponde=
d to the requested info without code modifications. =20

There was also the question of the meaning of "retransmission allowed" in t=
his context=3B this issue has also arisen in http://www.ietf.org/internet-d=
rafts/draft-ietf-geopriv-sip-lo-retransmission-01.txt.   For example=2C tha=
t document states:

   Bear in mind=2C however=2C that <retransmission-allowed> is not intended
   to provide any protocol-level mechanism to prevent unauthorized
   parties from learning location through means like eavesdropping.  It
   is merely a way to express the preferences of the Rule Maker to the
   LR.  If the LR were=2C for example=2C legally bound to follow the privac=
y
   preferences expressed by Rule Makers=2C then they might incur liability
   of they ignored the <retransmission-allowed> parameter.  No further
   privacy protection is assumed to be provided by <retransmission-
   allowed>....

   In this architecture=2C the question of who is an "authorized
   recipient" from the point of view of the Rule Maker has been muddy.
   The ... elements along the path are authorized to receive and forward
   the ... message=3B does that make them automatically authorized
   recipients of the LI it contains?  The final target of the ...
   message will receive the LI along with other information=2C but it may
   be different than the initial target in a variety of scenarios=3B is it
   authorized to read the LI?

   These questions and concerns are particularly problematic when
   <retransmission-allowed> is set to "no" (the default case).  This
   core concern might be put as "to whom does <retransmission-allowed>
   apply in location-based routing?"=20

These issues also arise in RADIUS since standard RADIUS attributes like NAS=
-IP-Address=2C=20
NAS-IPv6-Address=2C NAS-Identifier are required by [RFC2865] to be sent in =
an Access-Request and
also can be used for the purposes of location determination.  RADIUS proxie=
s will forward these=20
attributes along the path to the the RADIUS server regardless of whether th=
e rules allow
retransmission or not.  Since the RADIUS protocol doesn't provide confident=
iality=2C=20
user location is sent in the clear.  Are any of these existing practices af=
fected by
the carriage of rules within RADIUS packets? =20

--_42c4f0fc-d6f6-466f-90c8-a41e1eff7c88_
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'>
Watching the latest review comments=2C I wasn't sure whether the issue rela=
ting to request for location data had been resolved. The draft states that =
the RADIUS server can request location-data if the client indicated that it=
 was location capable.&nbsp=3B However=2C&nbsp=3B since the location data p=
rovided was to be considered opaque=2C it can't check whether the actual da=
ta corresponded to the requested info without code modifications.&nbsp=3B <=
br><br>There was also the question of the meaning of "retransmission allowe=
d" in this context=3B this issue has also arisen in http://www.ietf.org/int=
ernet-drafts/draft-ietf-geopriv-sip-lo-retransmission-01.txt.&nbsp=3B&nbsp=
=3B For example=2C that document states:<br><br><pre>   Bear in mind=2C how=
ever=2C that &lt=3Bretransmission-allowed&gt=3B is not intended<br>   to pr=
ovide any protocol-level mechanism to prevent unauthorized<br>   parties fr=
om learning location through means like eavesdropping.  It<br>   is merely =
a way to express the preferences of the Rule Maker to the<br>   LR.  If the=
 LR were=2C for example=2C legally bound to follow the privacy<br>   prefer=
ences expressed by Rule Makers=2C then they might incur liability<br>   of =
they ignored the &lt=3Bretransmission-allowed&gt=3B parameter.  No further<=
br>   privacy protection is assumed to be provided by &lt=3Bretransmission-=
<br>   allowed&gt=3B....<br><br>   In this architecture=2C the question of =
who is an "authorized<br>   recipient" from the point of view of the Rule M=
aker has been muddy.<br>   The ... elements along the path are authorized t=
o receive and forward<br>   the ... message=3B does that make them automati=
cally authorized<br>   recipients of the LI it contains?  The final target =
of the ...<br>   message will receive the LI along with other information=
=2C but it may<br>   be different than the initial target in a variety of s=
cenarios=3B is it<br>   authorized to read the LI?<br><br>   These question=
s and concerns are particularly problematic when<br>   &lt=3Bretransmission=
-allowed&gt=3B is set to "no" (the default case).  This<br>   core concern =
might be put as "to whom does &lt=3Bretransmission-allowed&gt=3B<br>   appl=
y in location-based routing?" <br><br>These issues also arise in RADIUS sin=
ce standard RADIUS attributes like NAS-IP-Address=2C <br>NAS-IPv6-Address=
=2C NAS-Identifier are required by [RFC2865] to be sent in an Access-Reques=
t and<br>also can be used for the purposes of location determination.  RADI=
US proxies will forward these <br>attributes along the path to the the RADI=
US server regardless of whether the rules allow<br>retransmission or not.  =
Since the RADIUS protocol doesn't provide confidentiality=2C <br>user locat=
ion is sent in the clear.  Are any of these existing practices affected by<=
br>the carriage of rules within RADIUS packets?  <br><br><br></pre></body>
</html>=

--_42c4f0fc-d6f6-466f-90c8-a41e1eff7c88_--

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

Delivery-date: Tue, 17 Feb 2009 07:15:21 +0000
Date: Tue, 17 Feb 2009 08:15:06 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "Joseph Salowey (jsalowey)" <[email-masked]>,  Stefan Winter <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: Issue 282: backward compatibility, proposed text

Bernard Aboba wrote:
> Question:  At various points we have talked about separating out the
> material on DNS SRV-based discovery.  How does this recommendation
> relate to that?  For example, assuming that DNS SRV RR queries aren't
> protected by DNSSEC, couldn't the discovery process generate a "fallback
> to classic RADIUS"?

  Yes.

> (e.g. if only the FQDN of the server is provided and
> DNS SRV RR queries are used to determine whether RADSEC and/or RADIUS
> was supported).   For example, couldn't an attacker spoof a response to
> the DNS SRV RR query and convince the querier that only RADIUS was
> available? 

  Systems should be implemented so that administrators can require
RADSEC for particular home servers.  This turns the down-bidding attack
into a DoS attack, as the proxy will refuse to connect over plain RADIUS.

> I think you need to say a bit more about the assumed deployment model
> and configuration/discovery.  For example, that RADSEC is deployed for
> use by proxies in talking to each other, and that as a result, these
> proxies *only* talk RADSEC.

  And are configured to require RADSEC.

>  It's a bit trickier if a NAS is capable of
> speaking both RADSEC and RADIUS.  In that situation it seems that the
> NAS would be configured to speak one or the other to a given RADIUS
> server, and that DNS-based discovery would play no role.  Is that
> right?

  Likely, yes.  However, it may be simple for clients to use SRV
lookups, too, as it avoids manual reconfiguration when the network
changes.  Clients should also be configurable to require RADSEC.

  If you assume that the client DNS lookups are performed over a
"secure" administrative network, then DNSSEC may not be required.

>   Is this advice still true if the RADIUS client has a
> DNSSEC-validating stub resolver and therefore is able to do secure
> discovery?

  Dynamic discover is always useful, and should be implemented where
possible.

> In the discussion of RADIUS over DTLS, there had been discussion of the
> ability to distinguish RADIUS/DTLS from RADIUS on the fly.  So I'm
> wondering if this advice on manual configuration applies there too, or not.

  Yes.

> And overall, I'm curious about where the text relating to DNS discovery
> is going/belongs.  In the draft?  Outside of it in a separate document? 
> None of these?

  In a separate draft.  DTLS and normal RADIUS could be using dynamic
discovery, too.

  Alan DeKok.

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

Delivery-date: Tue, 17 Feb 2009 07:03:51 +0000
From: Bernard Aboba <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>, Stefan Winter <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue 282: cipher suites, discussion needed
Date: Mon, 16 Feb 2009 23:03:39 -0800

--_9a21f70a-3fb1-468e-90ac-51bf57830343_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes=2C in general it's a good idea to acknowledge that TLS implementations =
need to implement the mandatory-to-implement ciphersuites for the versions =
they support.   With respect to NIST guidance=2C I'm a bit puzzled  (e.g. S=
P 800-120 seems to imply that the 1.1 mandatory-to-implement ciphersuite is=
 ok=2C but the 1.2 one is not). =20

> Subject: RE: Issue 282: cipher suites=2C discussion needed
> Date: Mon=2C 16 Feb 2009 21:48:38 -0800
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
>=20
> You could just leave this to the TLS specification.  For version 1.0 and =
1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it is TLS_RSA_WITH_=
AES_128_CBC_SHA.   If it is common today for implementations also to implem=
ent the RC4 ciphers you can have that as a recommendation as well.  Somethi=
ng like:
>=20
> "RADSEC implementation MUST support he mandatory to implement cipher suit=
es specified in TLS.  For purposes of compatibility with some current deplo=
yments implementations SHOULD support TLS_RSA_WITH_RC4_128_SHA as well."=20
>=20
> Cheers=2C
>=20
> Joe=20

--_9a21f70a-3fb1-468e-90ac-51bf57830343_
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'>
Yes=2C in general it's a good idea to acknowledge that TLS implementations =
need to implement the mandatory-to-implement ciphersuites for the versions =
they support.&nbsp=3B&nbsp=3B With respect to NIST guidance=2C I'm a bit pu=
zzled&nbsp=3B (e.g. SP 800-120 seems to imply that the 1.1 mandatory-to-imp=
lement ciphersuite is ok=2C but the 1.2 one is not).&nbsp=3B <br><br>&gt=3B=
 Subject: RE: Issue 282: cipher suites=2C discussion needed<br>&gt=3B Date:=
 Mon=2C 16 Feb 2009 21:48:38 -0800<br>&gt=3B From: [email-masked]<br>&g=
t=3B To: [email-masked]<br>&gt=3B CC: [email-masked]<br>&=
gt=3B <br>&gt=3B You could just leave this to the TLS specification.  For v=
ersion 1.0 and 1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it i=
s TLS_RSA_WITH_AES_128_CBC_SHA.   If it is common today for implementations=
 also to implement the RC4 ciphers you can have that as a recommendation as=
 well.  Something like:<br>&gt=3B <br>&gt=3B "RADSEC implementation MUST su=
pport he mandatory to implement cipher suites specified in TLS.  For purpos=
es of compatibility with some current deployments implementations SHOULD su=
pport TLS_RSA_WITH_RC4_128_SHA as well." <br>&gt=3B <br>&gt=3B Cheers=2C<br=
>&gt=3B <br>&gt=3B Joe <br><br></body>
</html>=

--_9a21f70a-3fb1-468e-90ac-51bf57830343_--

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

Delivery-date: Tue, 17 Feb 2009 07:00:27 +0000
From: Bernard Aboba <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>, Stefan Winter <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: RE: Issue 282: backward compatibility, proposed text
Date: Mon, 16 Feb 2009 22:59:55 -0800

--_246a6d5a-ca91-412b-8044-3a11c120690b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> As a consequence=2C the selection of transports to communicate from a
> client to a server is a manual administrative action.  An automatic
> fallback to classic RADIUS is NOT RECOMMENDED=2C as it may lead to
> down-bidding attacks on the peer communication.

Question:  At various points we have talked about separating out the materi=
al on DNS SRV-based discovery.  How does this recommendation relate to that=
?  For example=2C assuming that DNS SRV RR queries aren't protected by DNSS=
EC=2C couldn't the discovery process generate a "fallback to classic RADIUS=
"? (e.g. if only the FQDN of the server is provided and DNS SRV RR queries =
are used to determine whether RADSEC and/or RADIUS was supported).   For ex=
ample=2C couldn't an attacker spoof a response to the DNS SRV RR query and =
convince the querier that only RADIUS was available? =20

> Please comment if this text can satisfactorily close this sub-issue.

I think you need to say a bit more about the assumed deployment model and c=
onfiguration/discovery.  For example=2C that RADSEC is deployed for use by =
proxies in talking to each other=2C and that as a result=2C these proxies *=
only* talk RADSEC.  It's a bit trickier if a NAS is capable of speaking bot=
h RADSEC and RADIUS.  In that situation it seems that the NAS would be conf=
igured to speak one or the other to a given RADIUS server=2C and that DNS-b=
ased discovery would play no role.  Is that right?   Is this advice still t=
rue if the RADIUS client has a DNSSEC-validating stub resolver and therefor=
e is able to do secure discovery?=20

In the discussion of RADIUS over DTLS=2C there had been discussion of the a=
bility to distinguish RADIUS/DTLS from RADIUS on the fly.  So I'm wondering=
 if this advice on manual configuration applies there too=2C or not.=20

And overall=2C I'm curious about where the text relating to DNS discovery i=
s going/belongs.  In the draft?  Outside of it in a separate document?  Non=
e of these?

--_246a6d5a-ca91-412b-8044-3a11c120690b_
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 a consequence=2C the selection of transports to communicate from =
a<br>&gt=3B client to a server is a manual administrative action.  An autom=
atic<br>&gt=3B fallback to classic RADIUS is NOT RECOMMENDED=2C as it may l=
ead to<br>&gt=3B down-bidding attacks on the peer communication.<br><br>Que=
stion:&nbsp=3B At various points we have talked about separating out the ma=
terial on DNS SRV-based discovery.&nbsp=3B How does this recommendation rel=
ate to that?&nbsp=3B For example=2C assuming that DNS SRV RR queries aren't=
 protected by DNSSEC=2C couldn't the discovery process generate a "fallback=
 to classic RADIUS"? (e.g. if only the FQDN of the server is provided and D=
NS SRV RR queries are used to determine whether RADSEC and/or RADIUS was su=
pported).&nbsp=3B&nbsp=3B For example=2C couldn't an attacker spoof a respo=
nse to the DNS SRV RR query and convince the querier that only RADIUS was a=
vailable?&nbsp=3B <br><br>&gt=3B Please comment if this text can satisfacto=
rily close this sub-issue.<br><br>I think you need to say a bit more about =
the assumed deployment model and configuration/discovery.&nbsp=3B For examp=
le=2C that RADSEC is deployed for use by proxies in talking to each other=
=2C and that as a result=2C these proxies *only* talk RADSEC.&nbsp=3B It's =
a bit trickier if a NAS is capable of speaking both RADSEC and RADIUS.&nbsp=
=3B In that situation it seems that the NAS would be configured to speak on=
e or the other to a given RADIUS server=2C and that DNS-based discovery wou=
ld play no role.&nbsp=3B Is that right?&nbsp=3B&nbsp=3B Is this advice stil=
l true if the RADIUS client has a DNSSEC-validating stub resolver and there=
fore is able to do secure discovery? <br><br>In the discussion of RADIUS ov=
er DTLS=2C there had been discussion of the ability to distinguish RADIUS/D=
TLS from RADIUS on the fly.&nbsp=3B So I'm wondering if this advice on manu=
al configuration applies there too=2C or not. <br><br>And overall=2C I'm cu=
rious about where the text relating to DNS discovery is going/belongs.&nbsp=
=3B In the draft?&nbsp=3B Outside of it in a separate document?&nbsp=3B Non=
e of these?<br></body>
</html>=

--_246a6d5a-ca91-412b-8044-3a11c120690b_--

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

Delivery-date: Tue, 17 Feb 2009 05:49:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 282: cipher suites, discussion needed
Date: Mon, 16 Feb 2009 21:48:38 -0800
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Stefan Winter" <[email-masked]>
Cc: <[email-masked]>

You could just leave this to the TLS specification.  For version 1.0 and =
1.1 it is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and for 1.2 it is =
TLS_RSA_WITH_AES_128_CBC_SHA.   If it is common today for =
implementations also to implement the RC4 ciphers you can have that as a =
recommendation as well.  Something like:

"RADSEC implementation MUST support he mandatory to implement cipher =
suites specified in TLS.  For purposes of compatibility with some =
current deployments implementations SHOULD support =
TLS_RSA_WITH_RC4_128_SHA as well."=20

Cheers,

Joe=20

> -----Original Message-----
> From: Stefan Winter [mailto:[email-masked]]=20
> Sent: Wednesday, February 11, 2009 1:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Issue 282: cipher suites, discussion needed
>=20
> Hi,
>=20
> > 3.  I'm not sure I understand the choice of ciphersuites.
> >
> > Why is TLS_RSA_WITH_RC4_128_SHA recommended?  It seems that=20
> it would=20
> > be much preferable to use AES or 3DES?
> >  =20
>=20
> I could use a little help here. Is there anyone willing to=20
> investigate cipher suite selection? An alternative would be=20
> to follow the path of e.g. the EAP tunnel reqs, which cite=20
> NIST references for acceptable cipher suites...
>=20
> Greetings,
>=20
> Stefan Winter
>=20
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education=20
> Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
>=20
> Tel: +352 424409 1
> Fax: +352 422473
>=20
>=20

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

Delivery-date: Tue, 17 Feb 2009 05:35:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 282: backward compatibility, proposed text
Date: Mon, 16 Feb 2009 21:34:49 -0800
From: "Joseph Salowey (jsalowey)" <[email-masked]>
To: "Stefan Winter" <[email-masked]>
Cc: <[email-masked]>

Hi Stefan,

This looks good.

Thanks,

Joe

> -----Original Message-----
> From: Stefan Winter [mailto:[email-masked]]=20
> Sent: Wednesday, February 11, 2009 1:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Issue 282: backward compatibility, proposed text
>=20
> Hi,
>=20
> > 1.  How is backward compatibility/forward migration of=20
> RADSEC handled?
> > Operational recommendations in this area should be discussed.   The
> > potential for rollback attacks should also be covered in=20
> the security=20
> > considerations section.
> >  =20
>=20
> Section 4 of the new -03 revision reads:
>=20
> 4.  Compatibility with other RADIUS transports
>=20
>    Ongoing work in the IETF defines multiple alternative transports to
>    the classic UDP transport model as defined in [RFC2865], namely
>    RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS
>    [I-D.dekok-radext-dtls] and the present document on RadSec.
>=20
>    RadSec does not specify any inherent backwards compatibility to
>    classic RADIUS or cross compatibility to the other transports, i.e.
>    an implementation which implements RadSec only will not be able to
>    receive or send RADIUS packet payloads over other transports.  An
>    implementation wishing to be backward or cross compatible (i.e.
>    wishes to serve clients using other transports than=20
> RadSec) will need
>    to implement the other transports and RadSec transport and be
>    prepared to send and receive on all implemented=20
> transports, which is
>    called a multi-stack implementation.
>=20
>    If a given IP device is able to receive RADIUS payloads on multiple
>    transports, this may or may not be the same instance of=20
> software, and
>    it may or may not serve the same purposes.  It is not safe=20
> to assume
>    that both ports are interchangeable.  In particular, it can not be
>    assumed that state is maintained for the packet payloads=20
> between the
>    transports.  Two such instances MUST be considered separate RADIUS
>    server entities.
>=20
>    As a consequence, the selection of transports to communicate from a
>    client to a server is a manual administrative action.  An automatic
>    fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to
>    down-bidding attacks on the peer communication.
>=20
> And the Security Consideration contains:
>=20
>    If peer communication between two devices is configured for both
>    RadSec and classic RADIUS, a failover from RadSec to classic RADIUS
>    opens the way for a down-bidding attack if an adversary can
>    maliciously close the TCP connection, or prevent it from being
>    established.  In this case, security of the packet payload=20
> is reduced
>    from the selected TLS cipher suite packet encryption to the classic
>    MD5 per-attribute encryption.
>=20
> Please comment if this text can satisfactorily close this sub-issue.
>=20
> Greetings,
>=20
> Stefan Winter
>=20
> --=20
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education=20
> Nationale et de la Recherche
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
>=20
> Tel: +352 424409 1
> Fax: +352 422473
>=20
>=20

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

Delivery-date: Fri, 13 Feb 2009 22:04:31 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: IETF Trustees announcement
Date: Fri, 13 Feb 2009 14:03:53 -0800

I am assuming this is in the works... does anyone know details?

-----Original Message-----
From: David B. Nelson [mailto:[email-masked]] 
Sent: Friday, February 13, 2009 11:45 AM
To: 'Bernard Aboba'; [email-masked]
Subject: RE: IETF Trustees announcement

Do we know the xml2rfc will be updated?

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

Delivery-date: Fri, 13 Feb 2009 19:45:33 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: IETF Trustees announcement
Date: Fri, 13 Feb 2009 14:45:10 -0500
Organization: Elbrys Networks, Inc.

Do we know the xml2rfc will be updated?

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

Delivery-date: Fri, 13 Feb 2009 19:34:45 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: IETF Trustees announcement
Date: Fri, 13 Feb 2009 11:33:57 -0800

--_dd1b05e0-ae9f-4e57-bb6b-0c144e72e326_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ed Juskevicius has recently sent a message to the IETF Announce list=2C upd=
ating the IETF community on the status of the revision to the "Legal Provis=
ions Relating to IETF Documents" policy:http://www.ietf.org/mail-archive/we=
b/ietf-announce/current/msg05741.html
=20
The approved text available now on the IETF Trust website at:
 http://trustee.ietf.org/policyandprocedures.html
As Ed notes=2C the newly approved policy is dated February 12=2C 2009=2C an=
d the effective date is February 15=2C 2009.=20
=20
If you are involved in authoring=2C editing or revising Internet Drafts=2C =
then I would strongly encourage you familiarize yourself with the new polic=
y so that you are aware of the latest copyright statements and other boiler=
plate legend text that will be required on all contributions to the IETF st=
arting on February 15=2C 2009.=20
=20
=20
 =

--_dd1b05e0-ae9f-4e57-bb6b-0c144e72e326_
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'>
Ed Juskevicius has recently sent a message to the IETF Announce list=2C upd=
ating the IETF community on the status of&nbsp=3Bthe revision to the "Legal=
 Provisions Relating to IETF Documents" policy:<BR><A href=3D"http://www.ie=
tf.org/mail-archive/web/ietf-announce/current/msg05741.html">http://www.iet=
f.org/mail-archive/web/ietf-announce/current/msg05741.html</A><BR>
&nbsp=3B<BR>
The approved text available now on the IETF Trust website at:<BR>
<DIV>&nbsp=3B<A href=3D"http://trustee.ietf.org/policyandprocedures.html" r=
el=3Dnofollow>http://trustee.ietf.org/policyandprocedures.html</A></DIV>
<DIV><BR>As Ed notes=2C the newly approved policy is dated February 12=2C 2=
009=2C and the effective date is February 15=2C 2009. </DIV>
<DIV>&nbsp=3B</DIV>
<DIV>If you are involved in authoring=2C editing or revising Internet Draft=
s=2C then I would strongly encourage you familiarize yourself with the new =
policy so that you are aware of the latest copyright statements and other b=
oilerplate legend text that will be required on all contributions to the IE=
TF starting on February 15=2C 2009. </DIV>
<DIV>&nbsp=3B</DIV>
<DIV><FONT face=3DVerdana color=3D#444444 size=3D2></FONT>&nbsp=3B</DIV>
<DIV><A href=3D"http://trustee.ietf.org/policyandprocedures.html" rel=3Dnof=
ollow></A>&nbsp=3B</DIV></body>
</html>=

--_dd1b05e0-ae9f-4e57-bb6b-0c144e72e326_--

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

Delivery-date: Wed, 11 Feb 2009 22:02:31 +0000
Content-Class: urn:content-classes:message
Subject: RE: IPR Claim on RFC 2865
Date: Wed, 11 Feb 2009 16:59:28 -0500
From: Stephen Hanna <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I would like to clarify Juniper's position on this IPR claim.
The claim was filed erroneously. We have withdrawn it and do not
intend to submit it again. Please disregard this claim. I apologize
for this error, although I was not personally involved in it.

Sorry,

Steve=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Sunday, February 08, 2009 11:15 AM
> To: [email-masked]
> Subject: IPR Claim on RFC 2865
>=20
>=20
> The IETF Secretariat has received an IPR claim relating to RF=20
> 2865, submitted by
> Juniper Networks:
>=20
> http://www.ietf.org/ietf/IPR/juniper-ipr-rfc-2865.txt
>=20
> At this time, the IPR entry, available below, indicates that=20
> the claim has been withdrawn:
> https://datatracker.ietf.org/ipr/1049/
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Wed, 11 Feb 2009 09:15:13 +0000
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-radsec-03.txt 
Date: Wed, 11 Feb 2009 01:15:01 -0800 (PST)

--NextPart

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

	Title           : TLS encryption for RADIUS over TCP (RadSec)
	Author(s)       : S. Winter, et al.
	Filename        : draft-ietf-radext-radsec-03.txt
	Pages           : 17
	Date            : 2009-02-11

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

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

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

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

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

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

--NextPart--

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

Delivery-date: Wed, 11 Feb 2009 09:14:18 +0000
Date: Wed, 11 Feb 2009 10:13:05 +0100
From: Stefan Winter <[email-masked]>
To: [email-masked]
Subject: Issue 281: new (separate) draft upcoming

Hello,

the algorithm discussed in this issue has been clarified in the last
meeting. As discussed in that meeting, the entire dynamic discovery part
of the RadSec draft will go into a separate draft. This makes the issue
obsolete for the RadSec document. A draft for dynamic discovery will
follow soon.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Wed, 11 Feb 2009 09:14:12 +0000
Date: Wed, 11 Feb 2009 10:12:45 +0100
From: Stefan Winter <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: [email-masked]
Subject: Issue 282: cert validation, proposed text

Hi,

> 2.  I think the certificate handling and authorization section needs to
> be more specific for supporting mandatory to implement options.
> Currently, the document implicitly requires trust root based
> authorization where all certs issued by a given trust root are
> authorized.  Some more specific rules are discussed in an informative
> section.  I believe some of this needs to be normative and more specific
> in order to have interoperable implementations.  This should also be
> discussed in the security considerations. 
>   

Section 2.2 now reads:

2.2.  Connection Setup

   RadSec nodes

   1.  establish TCP connections as per [I-D.dekok-radext-tcp-transport]

   2.  negotiate TLS sessions according to [RFC5246] or its predecessor
       TLS 1.1.  The following restrictions apply:

       *  The authentication MUST be mutual, i.e. both the RadSec server
          and the RadSec client authenticate each other.

       *  The client MUST NOT negotiate cipher suites which only provide
          integrity protection.

       *  The TLS session MAY use mutual PSKs for connection setup.

       *  The cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA MUST be
          supported.

       *  The cipher suites TLS_RSA_WITH_AES_128_CBC_SHA and
          TLS_RSA_WITH_RC4_128_SHA SHOULD be supported. (see Section 3.2
          (1) )

   3.  If TLS is used in an X.509 certificate based operation mode, the
       following list of certificate validation options applies:

       *  Implementations MUST allow to configure a list of acceptable
          Certification Authorities for incoming connections.

       *  Certificate validation MUST include the verification rules as
          per [RFC5280].  If an SRV entry is present in the certificate
          and dynamic discovery based on DNS is used, the SRV entry
          SHOULD be validated. refence x.y.z here.

       *  Implementations SHOULD indicate their acceptable Certification
          Authorities as per section 7.4.4 (server side) and x.y.z
          ["Trusted CA Indication"] (client side) of [RFC5246] (see
          Section 3.1 (1) )

       *  Implementations SHOULD allow to configure a list of acceptable
          certificates, identified via certificate fingerprint.

       *  Peer validation always includes a check on whether the DNS
          name or the IP address of the server that is contacted matches
          its certificate.  DNS names and IP addresses can be contained
          in the Common Name (CN) or subjectAltName entries.  For
          verification, only one these entries is to be considered.  The
          following precedence applies: for DNS name validation,
          subjectAltName:DNS has precedence over CN; for IP address
          validation, subjectAltName:iPAddr has precedence over CN.

       *  Implementations SHOULD allow to configure a set of acceptable
          values for subjectAltName:URI.

There's no additional text in Security Considerations since was not sure
if additional text was needed with this new text.

Please comment if this text can satisfactorily close this sub-issue.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Wed, 11 Feb 2009 09:14:02 +0000
Date: Wed, 11 Feb 2009 10:12:49 +0100
From: Stefan Winter <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: [email-masked]
Subject: Issue 282: cipher suites, discussion needed

Hi,

> 3.  I'm not sure I understand the choice of ciphersuites.
>
> Why is TLS_RSA_WITH_RC4_128_SHA recommended?  It seems that it would be
> much preferable to use AES or 3DES? 
>   

I could use a little help here. Is there anyone willing to investigate
cipher suite selection? An alternative would be to follow the path of
e.g. the EAP tunnel reqs, which cite NIST references for acceptable
cipher suites...

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Wed, 11 Feb 2009 09:13:54 +0000
Date: Wed, 11 Feb 2009 10:12:57 +0100
From: Stefan Winter <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: [email-masked]
Subject: Issue 282: dynamic discovery text cleanup

Hi,

> 5. The terms "dynamic peer resolution" and "dynamic peer discovery" are
> used in the document and not clearly defined.  
>   

The terms have been unified and clarified by referencing a (new)
separate draft on dynamic peer discovery (which doesn't exist yet, but
will be submitted soon).

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Wed, 11 Feb 2009 09:13:46 +0000
Date: Wed, 11 Feb 2009 10:12:53 +0100
From: Stefan Winter <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: [email-masked]
Subject: Issue 282: shared secret for TCP

Hi,

> 4.  The document should state that the fixed string "radsec" shared
> secret MUST NOT be used when TLS is not available.
>   

I propose to add text to tcp-transport and volunteer for writing it.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Wed, 11 Feb 2009 09:13:38 +0000
Date: Wed, 11 Feb 2009 10:12:40 +0100
From: Stefan Winter <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: [email-masked]
Subject: Issue 282: backward compatibility, proposed text

Hi,

> 1.  How is backward compatibility/forward migration of RADSEC handled?
> Operational recommendations in this area should be discussed.   The
> potential for rollback attacks should also be covered in the security
> considerations section.  
>   

Section 4 of the new -03 revision reads:

4.  Compatibility with other RADIUS transports

   Ongoing work in the IETF defines multiple alternative transports to
   the classic UDP transport model as defined in [RFC2865], namely
   RADIUS over TCP [I-D.dekok-radext-tcp-transport], RADIUS over DTLS
   [I-D.dekok-radext-dtls] and the present document on RadSec.

   RadSec does not specify any inherent backwards compatibility to
   classic RADIUS or cross compatibility to the other transports, i.e.
   an implementation which implements RadSec only will not be able to
   receive or send RADIUS packet payloads over other transports.  An
   implementation wishing to be backward or cross compatible (i.e.
   wishes to serve clients using other transports than RadSec) will need
   to implement the other transports and RadSec transport and be
   prepared to send and receive on all implemented transports, which is
   called a multi-stack implementation.

   If a given IP device is able to receive RADIUS payloads on multiple
   transports, this may or may not be the same instance of software, and
   it may or may not serve the same purposes.  It is not safe to assume
   that both ports are interchangeable.  In particular, it can not be
   assumed that state is maintained for the packet payloads between the
   transports.  Two such instances MUST be considered separate RADIUS
   server entities.

   As a consequence, the selection of transports to communicate from a
   client to a server is a manual administrative action.  An automatic
   fallback to classic RADIUS is NOT RECOMMENDED, as it may lead to
   down-bidding attacks on the peer communication.

And the Security Consideration contains:

   If peer communication between two devices is configured for both
   RadSec and classic RADIUS, a failover from RadSec to classic RADIUS
   opens the way for a down-bidding attack if an adversary can
   maliciously close the TCP connection, or prevent it from being
   established.  In this case, security of the packet payload is reduced
   from the selected TLS cipher suite packet encryption to the classic
   MD5 per-attribute encryption.

Please comment if this text can satisfactorily close this sub-issue.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Wed, 11 Feb 2009 09:13:31 +0000
Date: Wed, 11 Feb 2009 10:13:01 +0100
From: Stefan Winter <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
CC: [email-masked]
Subject: Issue 282: PSK / cert fingerprint operation

Hi,

> 6. Would RADSEC benefit from a mechanism that did not require a PKI?
> This could be achieved by specifying a certificate fingerprint or PSK
> mode of operation.  
>   

The text in 2.2 has been clarified that a TLS PSK operation mode is
allowed. Cert fingerprint as a means of validating a connection attempt
has been added as a SHOULD.

Please comment if this text can satisfactorily close this sub-issue.

Greetings,

Stefan Winter

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

Tel: +352 424409 1
Fax: +352 422473

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

Delivery-date: Sun, 08 Feb 2009 16:15:43 +0000
From: Bernard Aboba <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: IPR Claim on RFC 2865
Date: Sun, 8 Feb 2009 08:14:32 -0800

The IETF Secretariat has received an IPR claim relating to RF 2865=2C submi=
tted by
Juniper Networks:

http://www.ietf.org/ietf/IPR/juniper-ipr-rfc-2865.txt

At this time=2C the IPR entry=2C available below=2C indicates that the clai=
m has been withdrawn:
https://datatracker.ietf.org/ipr/1049/

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

Delivery-date: Mon, 02 Feb 2009 10:01:21 +0000
Date: Mon, 02 Feb 2009 11:00:29 +0100
From: Alan DeKok <[email-masked]>
To: Dave Nelson <[email-masked]>
CC: [email-masked]
Subject: Re: Issue:  Data Type Advice

Dave Nelson wrote:
> Bernard Aboba writes...
> 
>>  Right now, this section seems to suggest that SDO specifications utilizing
>> existing RADIUS standard data types can avail themselves of IETF review.
> 
> Yes, but what does that mean?  Designated Expert?  AAA Doctors?  Certainly
> not IETF Last Call.

  The document suggests requesting a review from AAA-doctors.

  Alan DeKok.

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