Re: Reminder for review of Design Guidelines document

[Alan DeKok <[e-mail]>]

David B. Nelson wrote:
> Section 1.3, Applicability, reads in part:
> 
>    It is RECOMMENDED that SDOs and vendors seek review of RADIUS
>    attribute specifications from the IETF.  However, when specifications
>    are SDO specific, re-use existing data types, and follow these
>    guidelines, they do not require IETF review.
> 
> I assume that the phrase "they do not require IETF review" is not
> intended to Update RFC 3575, or to modify the RADIUS IANA considerations
> provisions thereof.

  Yes.  I'll see if I can clarify that.  I have some text suggesting
more clearly that vendors own their own VSA space.  The above text could
say:

    a) anything they do in their own VSA space does not require review
    b) referencing existing RFCs does not require review

  That should be compatible with 3575, I think.

> Section ZZZ
> 
> Placeholder that requires resolution?

  To 3.1, I think.

> Section 2.1, Data Types, reads in part:
> 
>    Nested groups or attributes do not qualify as "basic data types", and
>    SHOULD NOT be used.
> 
> Should that read "groups *of* attributes"?

  Hmm... maybe "groups of attributes or nested attributes".

>    All other data formats are defined to be "complex data types", and
>    are NOT RECOMMENDED.  However, there may be situations where complex
>    attributes are beneficial because they reduce complexity in the non-
>    RADIUS systems.  Unfortunately, there are no "hard and fast" rules
>    for where the complexity would best be located.  Each situation has
>    to be decided on a case-by-case basis.
> 
> Should the first sentence read ""are *generally* NOT RECOMMENDED"?  It seems to me that the qualification of the remainder of this paragraph substantially qualifies the traditional RFC 2119 keyword NOT RECOMMENDED.

  Possibly, yes.

> Section 3.1, RADIUS Operational Model, reads in part:
> 
>       * The protocol provices for authentication and integrity
>         protection of packets;
> 
> s/provices/provides/

  Fixed, thanks.

  Alan DeKok.

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

Envelope-to: [e-mail]
Delivery-date: Wed, 31 Mar 2010 19:34:58 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 2010 21:34:02 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "David B. Nelson" <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Reminder for review of Design Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David B. Nelson wrote:
> Section 1.3, Applicability, reads in part:
> 
>    It is RECOMMENDED that SDOs and vendors seek review of RADIUS
>    attribute specifications from the IETF.  However, when specifications
>    are SDO specific, re-use existing data types, and follow these
>    guidelines, they do not require IETF review.
> 
> I assume that the phrase "they do not require IETF review" is not
> intended to Update RFC 3575, or to modify the RADIUS IANA considerations
> provisions thereof.

  Yes.  I'll see if I can clarify that.  I have some text suggesting
more clearly that vendors own their own VSA space.  The above text could
say:

    a) anything they do in their own VSA space does not require review
    b) referencing existing RFCs does not require review

  That should be compatible with 3575, I think.

> Section ZZZ
> 
> Placeholder that requires resolution?

  To 3.1, I think.

> Section 2.1, Data Types, reads in part:
> 
>    Nested groups or attributes do not qualify as "basic data types", and
>    SHOULD NOT be used.
> 
> Should that read "groups *of* attributes"?

  Hmm... maybe "groups of attributes or nested attributes".

>    All other data formats are defined to be "complex data types", and
>    are NOT RECOMMENDED.  However, there may be situations where complex
>    attributes are beneficial because they reduce complexity in the non-
>    RADIUS systems.  Unfortunately, there are no "hard and fast" rules
>    for where the complexity would best be located.  Each situation has
>    to be decided on a case-by-case basis.
> 
> Should the first sentence read ""are *generally* NOT RECOMMENDED"?  It seems to me that the qualification of the remainder of this paragraph substantially qualifies the traditional RFC 2119 keyword NOT RECOMMENDED.

  Possibly, yes.

> Section 3.1, RADIUS Operational Model, reads in part:
> 
>       * The protocol provices for authentication and integrity
>         protection of packets;
> 
> s/provices/provides/

  Fixed, thanks.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Wed, 31 Mar 2010 15:07:15 +0000
Message-ID: <[e-mail]>
Date: Wed, 31 Mar 2010 17:06:03 +0200
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: Reminder for review of Design Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  The guidelines document was updated significantly to address the open
concerns.  The latest revision is available at:

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

  The high-level differences are an update as per the review from
Hannes.  The outline is now:

introduction	(2 pages)
guidelines	(3 pages)
rationale	(11 pages)

  The "guidelines" section gives the guidelines with no supporting
arguments.  All of the arguments are in the "rationale" section.  We
hope that this organization makes the guidelines easier to understand.

  The document still needs some minor editing, and also should integrate
comments from Issue #327.  However, these changes are expected to be
minor, and we are looking for feedback on the current draft.

  A diff is at:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-design-12.txt

  The diff isn't that useful, as too much has changed.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 28 Mar 2010 22:35:00 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_44fd2e38-f555-4362-9b23-a4c57f89bbb1_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Notes from IETF 77
Date: Sun, 28 Mar 2010 15:34:10 -0700
MIME-Version: 1.0

--_44fd2e38-f555-4362-9b23-a4c57f89bbb1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


If you took notes at IETF 77=2C please send them to me.=20



 		 	   		  =

--_44fd2e38-f555-4362-9b23-a4c57f89bbb1_
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'>
If you took notes at IETF 77=2C please send them to me. <br><br><br><table =
style=3D"border-top: 1px solid black=3B font-weight: bold=3B font-family: '=
Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live=
.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: =
9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=
=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B t=
ext-decoration: underline=3B"></span></a><br></td></tr></tbody></table> 		 =
	   		  </body>
</html>=

--_44fd2e38-f555-4362-9b23-a4c57f89bbb1_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 22 Mar 2010 23:45:53 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-design-12.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 22 Mar 2010 16:45:02 -0700 (PDT)

--NextPart

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


	Title           : RADIUS Design Guidelines
	Author(s)       : G. Weber, A. DeKok
	Filename        : draft-ietf-radext-design-12.txt
	Pages           : 39
	Date            : 2010-03-22

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-12.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-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 22 Mar 2010 22:04:04 +0000
Date: Mon, 22 Mar 2010 15:03:39 -0700 (Pacific Daylight Time)
From: Peter Deacon <[e-mail]>
To: 'radext mailing list' <[e-mail]>
Subject: Re: draft-dekok-radext-dtls-02 comments
Message-ID: <alpine.WNT.2.00.1003221446070.9176@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 22 Mar 2010, Alan DeKok wrote:

>> If so how does one implement new packet codes in the future or co-exist
>> with systems that do not support all currently allocated packet codes?

>  RADIUS has traditionally had a strong relationship between destination
> port and packet codes.  The list of packets allowed to be sent to port
> 1812 hasn't really changed in 15 years.  When new codes are defined
> (e.g. CoA), new ports are defined, too.  RDTLS follows this practice.

Well I have already said everything I wanted to.  WRT port allocations 
don't say that too loud the IANA might hear you :-)

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Mon, 22 Mar 2010 21:41:29 +0000
Message-ID: <[e-mail]>
Date: Mon, 22 Mar 2010 14:40:44 -0700
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: draft-dekok-radext-dtls-02 comments
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> On Mon, 22 Mar 2010, Alan DeKok wrote:
>>  In DTLS, the crypto layer ensures that packets have not been modified.
>> Therefore, the only time that packets are malformed is when the sender
>> has sent bad data.  When that happens, they should no longer be trusted
>> to do *anything*.
> 
> I understand DTLS provides encryption and integrity protection.  I don't
> understand why the peer should no longer be trusted?

  If the peer manifestly fails to implement RADIUS, then it can no
longer be trusted to implement RADIUS.

>  When this occurs
> is the client trusted to reestablish a DTLS session?  If so why?  Where
> is this trust defined? Administratively?

  So long as the client implements RADIUS, it can be trusted.  Since
more than one implementation may live at a particular IP address, *new*
connections from that IP cannot be forbidden if one misbehaves.

>>  Yes.  Too bad.  If someone can't be bothered to implement RADIUS
>> properly, their software won't work that well.
> 
> There are valid reasons to ignore a request.  See RFC2138 Sec 3.
> "Unrecognized packet codes are silently discarded"  If a server does not
> recognize a packet code sent by its peer does that mean the DTLS session
> needs to be dropped?

  Why is the client sending non-RADIUS packets to a RADIUS server?

> If so how does one implement new packet codes in the future or co-exist
> with systems that do not support all currently allocated packet codes?

  RADIUS has traditionally had a strong relationship between destination
port and packet codes.  The list of packets allowed to be sent to port
1812 hasn't really changed in 15 years.  When new codes are defined
(e.g. CoA), new ports are defined, too.  RDTLS follows this practice.

  This practice also means that servers *not* implementing a packet code
simply ignore *all* packets sent to a port... including DTLS connection
requests.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 22 Mar 2010 21:26:07 +0000
Date: Mon, 22 Mar 2010 14:25:43 -0700 (Pacific Daylight Time)
From: Peter Deacon <[e-mail]>
To: 'radext mailing list' <[e-mail]>
Subject: Re: draft-dekok-radext-dtls-02 comments
Message-ID: <alpine.WNT.2.00.1003221403210.9176@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Mon, 22 Mar 2010, Alan DeKok wrote:

>  Also, an *explicit* note that secrets should not be re-used is
> required, in my opinion.  This forbids one "obvious" class of
> implementations, where there's only one secret for RADIUS && RDTLS.

>> Sec 4.1.1 -
>>
>> "Where the RADIUS specifications require that a
>>    RADIUS packet received via the DTLS session is to be "silently
>>    discarded", the entry in the tracking table corresponding to that
>>    DTLS session MUST also be deleted, the DTLS session MUST be closed,
>>    and any TLS session resumption parameters for that session MUST be
>>    discarded."

>> Why is this still done when DTLS is used for a transport?  IIRC in the
>> TCP mapped drafts this was done to mitigate possibility of loss of
>> protocol synchronization - not possible WRT DTLS.

>  In DTLS, the crypto layer ensures that packets have not been modified.
> Therefore, the only time that packets are malformed is when the sender
> has sent bad data.  When that happens, they should no longer be trusted
> to do *anything*.

I understand DTLS provides encryption and integrity protection.  I don't 
understand why the peer should no longer be trusted?  When this occurs is 
the client trusted to reestablish a DTLS session?  If so why?  Where is 
this trust defined? Administratively?

>> There is an additional concern in that DTLS closure messages have no
>> retransmission timers and are not guaranteed to be delivered.  When this
>> occurs future messages will be discarded by the peers DTLS stack until
>> the clients "lifetime" timer expires and the DTLS session is reestablished.

>  Yes.  Too bad.  If someone can't be bothered to implement RADIUS 
> properly, their software won't work that well.

There are valid reasons to ignore a request.  See RFC2138 Sec 3. 
"Unrecognized packet codes are silently discarded"  If a server does not 
recognize a packet code sent by its peer does that mean the DTLS session 
needs to be dropped?

If so how does one implement new packet codes in the future or co-exist 
with systems that do not support all currently allocated packet codes?

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Mon, 22 Mar 2010 21:00:39 +0000
Message-ID: <[e-mail]>
Date: Mon, 22 Mar 2010 14:00:14 -0700
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: draft-dekok-radext-dtls-02 comments
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Peter Deacon wrote:
> Sec 8.1 -
> 
> "The previous RADIUS practice of using shared secrets that are minor
>    variations of words is NOT RECOMMENDED, as it would negate nearly all
>    of the security of DTLS."
> 
> I think any statements WRT secret key strength should to be generalized
> and take into account the properties of the underlying PSK suite as some
> systems may or may not be subject to offline attack.

  Do you have suggested text?

> "Any shared
>    secret used for RADIUS MUST NOT be used for DTLS.  Reusing a shared
>    secret between RADIUS and DTLS would negate all of the benefits found
>    by using DTLS."
> 
> I wonder if a more general warning about the possibility of
> down-negotiation would be a better fit.  I can see the same concept
> applying to administrative selection of cipher-suites.

  Do you have suggested text?

  Also, an *explicit* note that secrets should not be re-used is
required, in my opinion.  This forbids one "obvious" class of
implementations, where there's only one secret for RADIUS && RDTLS.

> Sec 4.1.1 -
> 
> "Where the RADIUS specifications require that a
>    RADIUS packet received via the DTLS session is to be "silently
>    discarded", the entry in the tracking table corresponding to that
>    DTLS session MUST also be deleted, the DTLS session MUST be closed,
>    and any TLS session resumption parameters for that session MUST be
>    discarded."
> 
> Why is this still done when DTLS is used for a transport?  IIRC in the
> TCP mapped drafts this was done to mitigate possibility of loss of
> protocol synchronization - not possible WRT DTLS.

  In DTLS, the crypto layer ensures that packets have not been modified.
 Therefore, the only time that packets are malformed is when the sender
has sent bad data.  When that happens, they should no longer be trusted
to do *anything*.

> My concern as with the TCP map is silently discarded messages can take
> down other unrelated exchanges.  The inner RADIUS should speak up while
> the transport is being established if there is no intention on honoring
> the established channel.

  A counter point is that systems not implementing RADIUS should not
talk to RADIUS servers.  It's not really appropriate to add negotiation
to RADIUS where implementations indicate whether or not they support RADIUS.

> There is an additional concern in that DTLS closure messages have no
> retransmission timers and are not guaranteed to be delivered.  When this
> occurs future messages will be discarded by the peers DTLS stack until
> the clients "lifetime" timer expires and the DTLS session is reestablished.

  Yes.  Too bad.  If someone can't be bothered to implement RADIUS
properly, their software won't work that well.

> Sec 4.2 -
> 
> "RDTLS clients SHOULD NOT send both normal RADIUS and RDTLS packets
>    from the same source socket."
> 
> " and increases the potential for
>    security breaches due to implementation issues."
> 
> WRT security only it seems to me servers must know better if not
> explicitly forbidden whether this is done or not.  Encouraging (change
> SHOULD NOT to MAY) can only shine light on the issue and force
> implementors to address appropriately.

  Hmm... allowing potentially bad behavior to highlight the fact that
bad behavior needs fixing.  I'm not sure I agree with that.

  Another argument is that allowing this increases the server processing
requirements for *every* packet.  Instead of doing RADIUS / DTLS
detection on the first packet from a new socket, it has to be done for
*every* packet.  This increases the number of cases that have to be
examined for potential RADIUS / DTLS overlap.

  Alan DeKok.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 22 Mar 2010 20:29:18 +0000
Date: Mon, 22 Mar 2010 13:28:28 -0700 (Pacific Daylight Time)
From: Peter Deacon <[e-mail]>
To: 'radext mailing list' <[e-mail]>
Subject: draft-dekok-radext-dtls-02 comments
Message-ID: <alpine.WNT.2.00.1003220936010.9176@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

Sec 8.1 -

"The previous RADIUS practice of using shared secrets that are minor
    variations of words is NOT RECOMMENDED, as it would negate nearly all
    of the security of DTLS."

I think any statements WRT secret key strength should to be generalized 
and take into account the properties of the underlying PSK suite as some 
systems may or may not be subject to offline attack.

"Any shared
    secret used for RADIUS MUST NOT be used for DTLS.  Reusing a shared
    secret between RADIUS and DTLS would negate all of the benefits found
    by using DTLS."

I wonder if a more general warning about the possibility of 
down-negotiation would be a better fit.  I can see the same concept 
applying to administrative selection of cipher-suites.

Sec 4.1.1 -

"Where the RADIUS specifications require that a
    RADIUS packet received via the DTLS session is to be "silently
    discarded", the entry in the tracking table corresponding to that
    DTLS session MUST also be deleted, the DTLS session MUST be closed,
    and any TLS session resumption parameters for that session MUST be
    discarded."

Why is this still done when DTLS is used for a transport?  IIRC in the TCP 
mapped drafts this was done to mitigate possibility of loss of protocol 
synchronization - not possible WRT DTLS.

My concern as with the TCP map is silently discarded messages can take 
down other unrelated exchanges.  The inner RADIUS should speak up while 
the transport is being established if there is no intention on honoring 
the established channel.

There is an additional concern in that DTLS closure messages have no 
retransmission timers and are not guaranteed to be delivered.  When this 
occurs future messages will be discarded by the peers DTLS stack until the 
clients "lifetime" timer expires and the DTLS session is reestablished.

Sec 4.2 -

"RDTLS clients SHOULD NOT send both normal RADIUS and RDTLS packets
    from the same source socket."

" and increases the potential for
    security breaches due to implementation issues."

WRT security only it seems to me servers must know better if not 
explicitly forbidden whether this is done or not.  Encouraging (change 
SHOULD NOT to MAY) can only shine light on the issue and force 
implementors to address appropriately.

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Mon, 22 Mar 2010 16:24:44 +0000
Message-ID: <[e-mail]>
Date: Mon, 22 Mar 2010 09:24:03 -0700
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: [Fwd: New Version Notification for draft-dekok-radext-dtls-02]
Content-Type: multipart/mixed; boundary="------------080203020903010908080102"

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


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

X-Account-Key: account3
X-Mozilla-Keys:                                                                                 
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32])
	by liberty.deployingradius.com (Postfix) with ESMTP id EAFD61234566
	for <[e-mail]>; Mon, 22 Mar 2010 17:00:15 +0100 (CET)
Received: by core3.amsl.com (Postfix, from userid 30)
	id 9718C3A696C; Mon, 22 Mar 2010 08:59:57 -0700 (PDT)
From: IETF I-D Submission Tool <[e-mail]>
To: [e-mail]
Subject: New Version Notification for draft-dekok-radext-dtls-02 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon, 22 Mar 2010 08:59:57 -0700 (PDT)


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

Filename:	 draft-dekok-radext-dtls
Revision:	 02
Title:		 DTLS as a Transport Layer for RADIUS
Creation_date:	 2010-03-22
WG ID:		 Independent Submission
Number_of_pages: 17

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


The IETF Secretariat.





--------------080203020903010908080102--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 21 Mar 2010 17:48:14 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_2597be0f-1806-43cb-bfdd-3c87d2f461a9_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Slide Reminder
Date: Sun, 21 Mar 2010 10:47:23 -0700
MIME-Version: 1.0

--_2597be0f-1806-43cb-bfdd-3c87d2f461a9_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


The RADEXT WG meeting is scheduled for Monday March 22=2C 2010 in the 5:40 =
-7:40 PM slot.=20

If you are on the agenda and haven't already submitted your slides=2C pleas=
e do so ASAP.=20

 		 	   		  =

--_2597be0f-1806-43cb-bfdd-3c87d2f461a9_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
--></style>
</head>
<body class=3D'hmmessage'>
The RADEXT WG meeting is scheduled for Monday March 22=2C 2010 in the 5:40 =
-7:40 PM slot. <br><br>If you are on the agenda and haven't already submitt=
ed your slides=2C please do so ASAP. <br><table style=3D"border-top: 1px so=
lid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-se=
rif=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?sou=
rce=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=
=2C 203)=3B text-decoration: none=3B"><span style=3D"padding: 0px 24px=3B f=
ont-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: underline=
=3B"></span></a><br></td></tr></tbody></table> 		 	   		  </body>
</html>=

--_2597be0f-1806-43cb-bfdd-3c87d2f461a9_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2010 20:00:56 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_c09ae083-e6af-4bd1-a7a6-3acb22b02489_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: RADEXT WG Last Call on "TLS Encryption for RADIUS" (Experimental)
Date: Fri, 19 Mar 2010 12:59:40 -0700
MIME-Version: 1.0

--_c09ae083-e6af-4bd1-a7a6-3acb22b02489_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is an announcement of RADEXT WG last call on "TLS Encryption for RADIU=
S"=2C prior to sending the document to the IESG for publication as an Exper=
imental RFC.=20

The document is available for inspection here:
http://tools.ietf.org/html/draft-ietf-radext-radsec

The RADEXT WG last call will last until April 19=2C 2010.   If you have com=
ments on the document=2C please send them to the RADEXT WG mailing list (ra=
[e-mail]) in the format described on the RADEXT Issues list (ht=
tp://www.drizzle.com/~aboba/RADEXT/ ). =20


 		 	   		  =

--_c09ae083-e6af-4bd1-a7a6-3acb22b02489_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
--></style>
</head>
<body class=3D'hmmessage'>
This is an announcement of RADEXT WG last call on "TLS Encryption for RADIU=
S"=2C prior to sending the document to the IESG for publication as an Exper=
imental RFC. <br><br>The document is available for inspection here:<br>http=
://tools.ietf.org/html/draft-ietf-radext-radsec<br><br>The RADEXT WG last c=
all will last until April 19=2C 2010.&nbsp=3B&nbsp=3B If you have comments =
on the document=2C please send them to the RADEXT WG mailing list (radiusex=
[e-mail]) in the format described on the RADEXT Issues list (http://w=
ww.drizzle.com/~aboba/RADEXT/ ).&nbsp=3B <br><br><table style=3D"border-top=
: 1px solid black=3B font-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=
=2Csan-serif=3B"><tbody><tr><td><a href=3D"http://im.live.com/Messenger/IM/=
Home/?source=3DEML_WLHM_GreaterGood" style=3D"font-size: 9pt=3B color: rgb(=
1=2C 132=2C 203)=3B text-decoration: none=3B"><span style=3D"padding: 0px 2=
4px=3B font-size: 8pt=3B color: rgb(63=2C 181=2C 85)=3B text-decoration: un=
derline=3B"></span></a><br></td></tr></tbody></table> 		 	   		  </body>
</html>=

--_c09ae083-e6af-4bd1-a7a6-3acb22b02489_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 19 Mar 2010 13:46:35 +0000
Message-ID: <[e-mail]>
Date: Fri, 19 Mar 2010 14:44:54 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-02.txt
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7F20B62321868E56D87A55C0"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7F20B62321868E56D87A55C0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

> Can you summarize which issues were closed and which are open?
>  =20

Sure: That's my current list of open questions for this draft.

1) Scope of Document: AAA in general or RADIUS transports only? Discuss
in dime.
2) mention of 4282: better leave it out? Need to re-define usage of @ as
delimiter then.
3) S-NAPTR: is this the right thing to do? Please review current draft.
4) IPv6: shall we give guidance about which stack to prefer, or how to
resolve names to IPs? Not a RADIUS issue after all; up to IPv6 wgs to
make such suggestions.

Greetings,

Stefan Winter


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]=
] On
> Behalf Of Stefan Winter
> Sent: Friday, March 05, 2010 6:52 AM
> To: [e-mail]
> Cc: TF-Mobility
> Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-02.txt
>
> Hi,
>
>  =20
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>    =20
> directories.
>  =20
>> This draft is a work item of the RADIUS EXTensions Working Group of th=
e
>>    =20
> IETF.
>  =20
>>
>> 	Title           : NAI-based Dynamic Peer Discovery for RADIUS over
>>    =20
> TLS and DTLS
>  =20
>> 	Author(s)       : S. Winter, M. McCauley
>> 	Filename        : draft-ietf-radext-dynamic-discovery-02.txt
>> 	Pages           : 9
>> 	Date            : 2010-03-05
>>
>> This document specifies a means to find authoritative AAA servers for =

>> a given NAI realm.  It can be used in conjunction with RADIUS over TLS=
=20
>> and RADIUS over DTLS.
>>  =20
>>    =20
> This draft contains new text for the issues discussed previously on the=

> list. It doesn't update any text on the remaining items which are still=

> unresolved.
>
> Greetings,
>
> Stefan
>
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nation=
ale et de
> la Recherche 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
>
> Tel: [phone]
> Fax: [phone]
>
>
>
>  =20



--------------enig7F20B62321868E56D87A55C0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkujf90ACgkQ+jm90f8eFWZ2GgCeNcf+TaFWK0/gJ7+WApfc7m0b
HvYAn0yM25eXylS35AENnDJgB08KILu/
=b/qu
-----END PGP SIGNATURE-----

--------------enig7F20B62321868E56D87A55C0--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 18 Mar 2010 15:33:10 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_c185708e-f2dc-49c1-85cc-2f121ee2e64a_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Slide Request
Date: Thu, 18 Mar 2010 08:32:21 -0700
MIME-Version: 1.0

--_c185708e-f2dc-49c1-85cc-2f121ee2e64a_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



The RADEXT WG meeting at IETF 77 will be held on Monday=2C March=20
22=2C 2010 in the 5:40 - 7:40 PM slot.



That is only 4 days from now!



So if you are on the agenda=2C please send your slides to Dave and=20
myself ASAP.=20



 		 	   		  =

--_c185708e-f2dc-49c1-85cc-2f121ee2e64a_
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>The RADEXT WG meeting at IETF 77 will be held on Monday=2C March=20
22=2C 2010 in the 5:40 - 7:40 PM slot.<br>
<br>
That is only 4 days from now!<br>
<br>
So if you are on the agenda=2C please send your slides to Dave and=20
myself ASAP. <br><br><br><table style=3D"border-top: 1px solid black=3B fon=
t-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><=
tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_G=
reaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-=
decoration: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B =
color: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><b=
r></td></tr></tbody></table> 		 	   		  </body>
</html>=

--_c185708e-f2dc-49c1-85cc-2f121ee2e64a_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 16 Mar 2010 01:14:12 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_b857c37d-a77c-42ee-a748-36db7f90be31_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>, <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: Last Call: draft-ietf-radext-status-server (Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol) to Informational RFC
Date: Mon, 15 Mar 2010 18:13:24 -0700
MIME-Version: 1.0

--_b857c37d-a77c-42ee-a748-36db7f90be31_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


An editorial comment on Section 2.=20

Section 2

   Status-Server packets are sent by a RADIUS client to a RADIUS server
   in order to test the status of that server.  A Message-Authenticator
   attribute MUST be included so as to provide per-packet authentication
   and integrity protection.  A single Status-Server packet MUST be
   included within a UDP datagram.  RADIUS proxies MUST NOT forward
   Status-Server packets.

   Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy
   or server=2C the destination of a Status-Server packet is set to the IP
   address of the server which is being tested.  As a result=2C the client
   is provided with an indication of the status of that server only=2C
   since no RADIUS proxies are on the path between the RADIUS client and
   server.  Since servers respond to a Status-Server packet without
   examining the User-Name attribute=2C the response to a Status-Server
   packet cannot be used to infer any information about the reachability
   of specific realms.

   A RADIUS server or proxy implementing this specification SHOULD
   respond to a Status-Server packet with an Access-Accept
   (authentication port) or Accounting-Message (accounting port).  An
   Access-Challenge response is NOT RECOMMENDED.  An Access-Reject
   response MAY be used.  The list of attributes that are permitted in
   Status-Server and Access-Accept packets responding to Status-Server
   packets are provided in the Section 6.

[BA] These three paragraphs are a bit disjoint.  Recommend changing it
to the following:

   Status-Server packets are sent by a RADIUS client to a RADIUS server
   in order to test the status of that server.   The destination of
   a Status-Server packet is set to the IP address of the server that
   is being tested.  A single Status-Server packet MUST be included=20
   within a UDP datagram.  A Message-Authenticator attribute MUST be=20
   included so as to provide per-packet authentication and integrity=20
   protection.=20

   RADIUS proxies or servers MUST NOT forward Status-Server packets.
   A RADIUS server or proxy implementing this specification SHOULD
   respond to a Status-Server packet with an Access-Accept
   (authentication port) or Accounting-Response (accounting port).  An
   Access-Challenge response is NOT RECOMMENDED.  An Access-Reject
   response MAY be used.  The list of attributes that are permitted in
   Status-Server and Access-Accept packets responding to Status-Server
   packets are provided in the Section 6.

   Since a Status-Server packet MUST NOT be forwarded=20
   by a RADIUS proxy or server=2C the client is provided with an indication=
=20
   of the status of that server only=2C since no RADIUS proxies are on the=
=20
   path between the RADIUS client and server.  Since servers respond=20
   to a Status-Server packet without examining the User-Name attribute=2C=20
   the response to a Status-Server packet cannot be used to infer any=20
   information about the reachability of specific realms.=20





> To: [e-mail]
> From: [e-mail]
> CC: [e-mail]
> Subject: Last Call: draft-ietf-radext-status-server (Use of Status-Server=
 Packets in the Remote Authentication Dial In User Service (RADIUS) Protoco=
l) to Informational RFC
> Date: Mon=2C 15 Mar 2010 12:42:32 -0700
>=20
> The IESG has received a request from the RADIUS EXTensions WG (radext) to=
=20
> consider the following document:
>=20
> - 'Use of Status-Server Packets in the Remote Authentication Dial In User=
=20
>    Service (RADIUS) Protocol '
>    <draft-ietf-radext-status-server-06.txt> as an Informational RFC
>=20
> The IESG plans to make a decision in the next few weeks=2C and solicits
> final comments on this action.  Please send substantive comments to the
> [e-mail] mailing lists by 2010-03-29. Exceptionally=2C=20
> comments may be sent to [e-mail] instead. In either case=2C please=20
> retain the beginning of the Subject line to allow automated sorting.
>=20
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-06.tx=
t
>=20
>=20
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=
=3D17334&rfc_flag=3D0
>=20
>=20
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
 		 	   		  =

--_b857c37d-a77c-42ee-a748-36db7f90be31_
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'>
An editorial comment on Section 2. <br><br>Section 2<br><br>&nbsp=3B&nbsp=
=3B Status-Server packets are sent by a RADIUS client to a RADIUS server<br=
>&nbsp=3B&nbsp=3B in order to test the status of that server.&nbsp=3B A Mes=
sage-Authenticator<br>&nbsp=3B&nbsp=3B attribute MUST be included so as to =
provide per-packet authentication<br>&nbsp=3B&nbsp=3B and integrity protect=
ion.&nbsp=3B A single Status-Server packet MUST be<br>&nbsp=3B&nbsp=3B incl=
uded within a UDP datagram.&nbsp=3B RADIUS proxies MUST NOT forward<br>&nbs=
p=3B&nbsp=3B Status-Server packets.<br><br>&nbsp=3B&nbsp=3B Since a Status-=
Server packet MUST NOT be forwarded by a RADIUS proxy<br>&nbsp=3B&nbsp=3B o=
r server=2C the destination of a Status-Server packet is set to the IP<br>&=
nbsp=3B&nbsp=3B address of the server which is being tested.&nbsp=3B As a r=
esult=2C the client<br>&nbsp=3B&nbsp=3B is provided with an indication of t=
he status of that server only=2C<br>&nbsp=3B&nbsp=3B since no RADIUS proxie=
s are on the path between the RADIUS client and<br>&nbsp=3B&nbsp=3B server.=
&nbsp=3B Since servers respond to a Status-Server packet without<br>&nbsp=
=3B&nbsp=3B examining the User-Name attribute=2C the response to a Status-S=
erver<br>&nbsp=3B&nbsp=3B packet cannot be used to infer any information ab=
out the reachability<br>&nbsp=3B&nbsp=3B of specific realms.<br><br>&nbsp=
=3B&nbsp=3B A RADIUS server or proxy implementing this specification SHOULD=
<br>&nbsp=3B&nbsp=3B respond to a Status-Server packet with an Access-Accep=
t<br>&nbsp=3B&nbsp=3B (authentication port) or Accounting-Message (accounti=
ng port).&nbsp=3B An<br>&nbsp=3B&nbsp=3B Access-Challenge response is NOT R=
ECOMMENDED.&nbsp=3B An Access-Reject<br>&nbsp=3B&nbsp=3B response MAY be us=
ed.&nbsp=3B The list of attributes that are permitted in<br>&nbsp=3B&nbsp=
=3B Status-Server and Access-Accept packets responding to Status-Server<br>=
&nbsp=3B&nbsp=3B packets are provided in the Section 6.<br><br>[BA] These t=
hree paragraphs are a bit disjoint.&nbsp=3B Recommend changing it<br>to the=
 following:<br><br>&nbsp=3B&nbsp=3B Status-Server packets are sent by a RAD=
IUS client to a RADIUS server<br>&nbsp=3B&nbsp=3B in order to test the stat=
us of that server.&nbsp=3B&nbsp=3B The destination of<br>&nbsp=3B&nbsp=3B a=
 Status-Server packet is set to the IP address of the server that<br>&nbsp=
=3B&nbsp=3B is being tested.&nbsp=3B A single Status-Server packet MUST be =
included <br>&nbsp=3B&nbsp=3B within a UDP datagram.&nbsp=3B A Message-Auth=
enticator attribute MUST be <br>&nbsp=3B&nbsp=3B included so as to provide =
per-packet authentication and integrity <br>&nbsp=3B&nbsp=3B protection. <b=
r><br>&nbsp=3B&nbsp=3B RADIUS proxies or servers MUST NOT forward Status-Se=
rver packets.<br>&nbsp=3B&nbsp=3B A RADIUS server or proxy implementing thi=
s specification SHOULD<br>&nbsp=3B&nbsp=3B respond to a Status-Server packe=
t with an Access-Accept<br>&nbsp=3B&nbsp=3B (authentication port) or Accoun=
ting-Response (accounting port).&nbsp=3B An<br>&nbsp=3B&nbsp=3B Access-Chal=
lenge response is NOT RECOMMENDED.&nbsp=3B An Access-Reject<br>&nbsp=3B&nbs=
p=3B response MAY be used.&nbsp=3B The list of attributes that are permitte=
d in<br>&nbsp=3B&nbsp=3B Status-Server and Access-Accept packets responding=
 to Status-Server<br>&nbsp=3B&nbsp=3B packets are provided in the Section 6=
.<br><br>&nbsp=3B&nbsp=3B Since a Status-Server packet MUST NOT be forwarde=
d <br>&nbsp=3B&nbsp=3B by a RADIUS proxy or server=2C the client is provide=
d with an indication <br>&nbsp=3B&nbsp=3B of the status of that server only=
=2C since no RADIUS proxies are on the <br>&nbsp=3B&nbsp=3B path between th=
e RADIUS client and server.&nbsp=3B Since servers respond <br>&nbsp=3B&nbsp=
=3B to a Status-Server packet without examining the User-Name attribute=2C =
<br>&nbsp=3B&nbsp=3B the response to a Status-Server packet cannot be used =
to infer any <br>&nbsp=3B&nbsp=3B information about the reachability of spe=
cific realms. <br><br><br><table style=3D"border-top: 1px solid black=3B fo=
nt-weight: bold=3B font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody>=
<tr><td><a href=3D"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_=
GreaterGood" style=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text=
-decoration: none=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B=
 color: rgb(63=2C 181=2C 85)=3B text-decoration: underline=3B"></span></a><=
br></td></tr></tbody></table><br><br>&gt=3B To: [e-mail]<br>&=
gt=3B From: [e-mail]<br>&gt=3B CC: [e-mail]<br=
>&gt=3B Subject: Last Call: draft-ietf-radext-status-server (Use of Status-=
Server Packets in the Remote Authentication Dial In User Service (RADIUS) P=
rotocol) to Informational RFC<br>&gt=3B Date: Mon=2C 15 Mar 2010 12:42:32 -=
0700<br>&gt=3B <br>&gt=3B The IESG has received a request from the RADIUS E=
XTensions WG (radext) to <br>&gt=3B consider the following document:<br>&gt=
=3B <br>&gt=3B - 'Use of Status-Server Packets in the Remote Authentication=
 Dial In User <br>&gt=3B    Service (RADIUS) Protocol '<br>&gt=3B    &lt=3B=
draft-ietf-radext-status-server-06.txt&gt=3B as an Informational RFC<br>&gt=
=3B <br>&gt=3B The IESG plans to make a decision in the next few weeks=2C a=
nd solicits<br>&gt=3B final comments on this action.  Please send substanti=
ve comments to the<br>&gt=3B [e-mail] mailing lists by 2010-03-29. Exc=
eptionally=2C <br>&gt=3B comments may be sent to [e-mail] instead. In =
either case=2C please <br>&gt=3B retain the beginning of the Subject line t=
o allow automated sorting.<br>&gt=3B <br>&gt=3B The file can be obtained vi=
a<br>&gt=3B http://www.ietf.org/internet-drafts/draft-ietf-radext-status-se=
rver-06.txt<br>&gt=3B <br>&gt=3B <br>&gt=3B IESG discussion can be tracked =
via<br>&gt=3B https://datatracker.ietf.org/public/pidtracker.cgi?command=3D=
view_id&amp=3BdTag=3D17334&amp=3Brfc_flag=3D0<br>&gt=3B <br>&gt=3B <br>&gt=
=3B --<br>&gt=3B to unsubscribe send a message to [e-mail]=
f.org with<br>&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>=

--_b857c37d-a77c-42ee-a748-36db7f90be31_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 15 Mar 2010 19:43:39 +0000
To: IETF-Announce <[e-mail]> 
From: The IESG <[e-mail]>
Reply-to: [e-mail]
CC: <[e-mail]>
Subject: Last Call: draft-ietf-radext-status-server (Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol) to Informational RFC
Message-Id: <[e-mail]>
Date: Mon, 15 Mar 2010 12:42:32 -0700 (PDT)

The IESG has received a request from the RADIUS EXTensions WG (radext) to 
consider the following document:

- 'Use of Status-Server Packets in the Remote Authentication Dial In User 
   Service (RADIUS) Protocol '
   <draft-ietf-radext-status-server-06.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[e-mail] mailing lists by 2010-03-29. Exceptionally, 
comments may be sent to [e-mail] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-06.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17334&rfc_flag=0


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


Envelope-to: [e-mail]
Delivery-date: Wed, 10 Mar 2010 07:49:34 +0000
From: Maglione Roberta <[e-mail]>
To: Glen Zorn <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Wed, 10 Mar 2010 08:48:46 +0100
Subject: RE: comments on draft-maglione-radext-ipv6-acct-extensions-01
Thread-Topic: comments on draft-maglione-radext-ipv6-acct-extensions-01
Thread-Index: Acq/R0ohergv+PqsRSGlHd89lrAkpQA3VGig
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Thanks for your comments.
Please see answers inline.
Regards,
Robert

-----Original Message-----
From: Glen Zorn [mailto:[e-mail]]
Sent: Tuesday, March 09, 2010 6:14 AM
To: Maglione Roberta; [e-mail]; alan.kavanagh@ericsson.=
com; [e-mail]; [e-mail]
Cc: 'Glen Zorn'; [e-mail]
Subject: comments on draft-maglione-radext-ipv6-acct-extensions-01

Not sure why this is Standards Track since both RFC 2866 & RFC 2869 are
Informational.
[RM] ok we can change to Informational.

It would be more in-line w/RADIUS tradition to name the Attributes
Acct-IPv6-* rather than IPv6-Acct-*.

[RM] ok fine.

References are pointers to objects, not the objects themselves.  Suggest
changing all instances of constructs like "[RFC2866]and [RFC2869] specify"
to "RFC 2866 [RFC2866] and RFC 2869 [RFC2869] specify" or simply rewriting
the sentences so that the use of pointers makes sense, in this case perhaps
to "Existing documents (RFC2866], [RFC2869]) specify".

[RM] ok we will re-phrase it.

TYPO: s/the IPv6 in broadband environment/IPv6 in broadband environments/ i=
n
the Introduction.
TYPO: s/new RADIUS attribute have to be defined/new RADIUS attributes have
to be defined/ in the Introduction
[RM] ok we will correct these typos

The second paragraph of the Introduction says "This document describes
additional RADIUS attributes for collecting IPv6 specific statistics in
RADIUS Accounting messages"; suggest changing to "This document describes
additional RADIUS attributes for transporting IPv6-specific statistics in
RADIUS Accounting messages".

[RM] ok thanks for the suggestions we will re-phrase this sentence

Section 3, second paragraph says:
   Existing RADIUS attributes like Acct-Input-Octets, Acct-Output-
   Octets, Acct-Input-Packets, Acct-Output-Packets, Acct-Input-Gigawords
   and Acct-Output-Gigawords, could be used to collect statistics for
   all traffic(including IPv4, IPv6 and other protocols), while the
   availability of IPv6 specific RADIUS attributes would allow the
   collection of IPv6 statistics.
Suggest changing to:
   Existing RADIUS attributes like Acct-Input-Octets, Acct-Output-
   Octets, Acct-Input-Packets, Acct-Output-Packets, Acct-Input-Gigawords
   and Acct-Output-Gigawords, could be used to collect statistics for
   all traffic (including IPv4, IPv6 and other protocols), while the
   availability of IPv6-specific RADIUS attributes would allow the
   collection of IPv6 statistics.

[RM] ok

It's not at all clear to me why the first paragraph of section 4.1 exists.

The second paragraph of Section 4.1 says:
   If the Accounting-Request packet includes a Framed-IPv6-Prefix, that
   attribute MUST contain the IPv6 prefix allocated to the user.  In
   deployment scenarios where DHCPv6 prefix delegation is used, the
   Accounting-Request packet will contain a Delegated-IPv6-Prefix
   attribute that contains the IPv6 prefix delegated to the user.
The first sentence just repeats what RFC 3162 says about the
Framed-IPv6-Prefix Attribute.  This seems unnecessary.  The second sentence
says that "the Accounting-Request packet will contain a
Delegated-IPv6-Prefix attribute" but RFC 4818 doesn't say this.  As one may
have guessed, I would prefer that section 4 be deleted altogether, but if
the authors feel it necessary for it to be included, I suggest modifying it
to at least be accurate and to include references to RFC 3962 and RFC 4818.

[RM] I may need to re-discuss this point with the other co-authors, we will=
 get back to you on this

In sections 5.*, a blank line should be added before "Length" in the
Attribute summaries.
[RM] ok

In Section 7, an allocation policy must be specified; suggest just adding a
reference to RFC 3575.

[RM] ok.



Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per=
sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall=
a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb=
iate ricevuto questo documento per errore siete cortesemente pregati di dar=
ne immediata comunicazione al mittente e di provvedere alla sua distruzione=
, Grazie.

This e-mail and any attachments is confidential and may contain privileged =
information intended for the addressee(s) only. Dissemination, copying, pri=
nting or use by anybody else is unauthorised. If you are not the intended r=
ecipient, please delete this message and any attachments and advise the sen=
der by return e-mail, Thanks.


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


Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2010 20:10:09 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_58a2a7eb-2536-4948-8f4a-b8b2eac4f905_"
From: Bernard Aboba <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: comments on draft-maglione-radext-ipv6-acct-extensions-01
Date: Tue, 9 Mar 2010 12:09:36 -0800
MIME-Version: 1.0

--_58a2a7eb-2536-4948-8f4a-b8b2eac4f905_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Date: Tue=2C 9 Mar 2010 12:13:45 +0700
From: "Glen Zorn" <[e-mail]>
Subject: comments on draft-maglione-radext-ipv6-acct-extensions-01
To: <[e-mail]>=2C
	<[e-mail]>=2C	<[e-mail]>=2C
	<[e-mail]>=2C	<[e-mail]>

Not sure why this is Standards Track since both RFC 2866 & RFC 2869 are
Informational.
=20
It would be more in-line w/RADIUS tradition to name the Attributes
Acct-IPv6-* rather than IPv6-Acct-*.
=20
References are pointers to objects=2C not the objects themselves.  Suggest
changing all instances of constructs like "[RFC2866]and [RFC2869] specify"
to "RFC 2866 [RFC2866] and RFC 2869 [RFC2869] specify" or simply rewriting
the sentences so that the use of pointers makes sense=2C in this case perha=
ps
to "Existing documents (RFC2866]=2C [RFC2869]) specify".
=20
TYPO: s/the IPv6 in broadband environment/IPv6 in broadband environments/ i=
n
the Introduction.
=20
TYPO: s/new RADIUS attribute have to be defined/new RADIUS attributes have
to be defined/ in the Introduction
=20
The second paragraph of the Introduction says "This document describes
additional RADIUS attributes for collecting IPv6 specific statistics in
RADIUS Accounting messages"=3B suggest changing to "This document describes
additional RADIUS attributes for transporting IPv6-specific statistics in
RADIUS Accounting messages".
=20
Section 3=2C second paragraph says:
   Existing RADIUS attributes like Acct-Input-Octets=2C Acct-Output-
   Octets=2C Acct-Input-Packets=2C Acct-Output-Packets=2C Acct-Input-Gigawo=
rds
   and Acct-Output-Gigawords=2C could be used to collect statistics for
   all traffic(including IPv4=2C IPv6 and other protocols)=2C while the
   availability of IPv6 specific RADIUS attributes would allow the
   collection of IPv6 statistics.
Suggest changing to:
   Existing RADIUS attributes like Acct-Input-Octets=2C Acct-Output-
   Octets=2C Acct-Input-Packets=2C Acct-Output-Packets=2C Acct-Input-Gigawo=
rds
   and Acct-Output-Gigawords=2C could be used to collect statistics for
   all traffic (including IPv4=2C IPv6 and other protocols)=2C while the
   availability of IPv6-specific RADIUS attributes would allow the
   collection of IPv6 statistics.
=20
It's not at all clear to me why the first paragraph of section 4.1 exists.
=20
The second paragraph of Section 4.1 says:
   If the Accounting-Request packet includes a Framed-IPv6-Prefix=2C that
   attribute MUST contain the IPv6 prefix allocated to the user.  In
   deployment scenarios where DHCPv6 prefix delegation is used=2C the
   Accounting-Request packet will contain a Delegated-IPv6-Prefix
   attribute that contains the IPv6 prefix delegated to the user.
The first sentence just repeats what RFC 3162 says about the
Framed-IPv6-Prefix Attribute.  This seems unnecessary.  The second sentence
says that "the Accounting-Request packet will contain a
Delegated-IPv6-Prefix attribute" but RFC 4818 doesn't say this.  As one may
have guessed=2C I would prefer that section 4 be deleted altogether=2C but =
if
the authors feel it necessary for it to be included=2C I suggest modifying =
it
to at least be accurate and to include references to RFC 3962 and RFC 4818.
=20
In sections 5.*=2C a blank line should be added before "Length" in the
Attribute summaries.
=20
In Section 7=2C an allocation policy must be specified=3B suggest just addi=
ng a
reference to RFC 3575.
 		 	   		  =

--_58a2a7eb-2536-4948-8f4a-b8b2eac4f905_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
--></style>
</head>
<body class=3D'hmmessage'>
<pre><br>Date: Tue=2C 9 Mar 2010 12:13:45 +0700<br>From: "Glen Zorn" &lt=3B=
[e-mail]&gt=3B<br>Subject: comments on draft-maglione-radext-ipv6-ac=
ct-extensions-01<br>To: &lt=[e-mail]&gt=3B=2C<br=
>	&lt=[e-mail]&gt=3B=2C	&lt=3Balan.kavanagh@ericsson.=
com&gt=3B=2C<br>	&lt=[e-mail]&gt=3B=2C	&lt=3Bjkaippal@huaw=
ei.com&gt=3B<br><br>Not sure why this is Standards Track since both RFC 286=
6 &amp=3B RFC 2869 are<br>Informational.<br> <br>It would be more in-line w=
/RADIUS tradition to name the Attributes<br>Acct-IPv6-* rather than IPv6-Ac=
ct-*.<br> <br>References are pointers to objects=2C not the objects themsel=
ves.  Suggest<br>changing all instances of constructs like "[RFC2866]and [R=
FC2869] specify"<br>to "RFC 2866 [RFC2866] and RFC 2869 [RFC2869] specify" =
or simply rewriting<br>the sentences so that the use of pointers makes sens=
e=2C in this case perhaps<br>to "Existing documents (RFC2866]=2C [RFC2869])=
 specify".<br> <br>TYPO: s/the IPv6 in broadband environment/IPv6 in broadb=
and environments/ in<br>the Introduction.<br> <br>TYPO: s/new RADIUS attrib=
ute have to be defined/new RADIUS attributes have<br>to be defined/ in the =
Introduction<br> <br>The second paragraph of the Introduction says "This do=
cument describes<br>additional RADIUS attributes for collecting IPv6 specif=
ic statistics in<br>RADIUS Accounting messages"=3B suggest changing to "Thi=
s document describes<br>additional RADIUS attributes for transporting IPv6-=
specific statistics in<br>RADIUS Accounting messages".<br> <br>Section 3=2C=
 second paragraph says:<br>   Existing RADIUS attributes like Acct-Input-Oc=
tets=2C Acct-Output-<br>   Octets=2C Acct-Input-Packets=2C Acct-Output-Pack=
ets=2C Acct-Input-Gigawords<br>   and Acct-Output-Gigawords=2C could be use=
d to collect statistics for<br>   all traffic(including IPv4=2C IPv6 and ot=
her protocols)=2C while the<br>   availability of IPv6 specific RADIUS attr=
ibutes would allow the<br>   collection of IPv6 statistics.<br>Suggest chan=
ging to:<br>   Existing RADIUS attributes like Acct-Input-Octets=2C Acct-Ou=
tput-<br>   Octets=2C Acct-Input-Packets=2C Acct-Output-Packets=2C Acct-Inp=
ut-Gigawords<br>   and Acct-Output-Gigawords=2C could be used to collect st=
atistics for<br>   all traffic (including IPv4=2C IPv6 and other protocols)=
=2C while the<br>   availability of IPv6-specific RADIUS attributes would a=
llow the<br>   collection of IPv6 statistics.<br> <br>It's not at all clear=
 to me why the first paragraph of section 4.1 exists.<br> <br>The second pa=
ragraph of Section 4.1 says:<br>   If the Accounting-Request packet include=
s a Framed-IPv6-Prefix=2C that<br>   attribute MUST contain the IPv6 prefix=
 allocated to the user.  In<br>   deployment scenarios where DHCPv6 prefix =
delegation is used=2C the<br>   Accounting-Request packet will contain a De=
legated-IPv6-Prefix<br>   attribute that contains the IPv6 prefix delegated=
 to the user.<br>The first sentence just repeats what RFC 3162 says about t=
he<br>Framed-IPv6-Prefix Attribute.  This seems unnecessary.  The second se=
ntence<br>says that "the Accounting-Request packet will contain a<br>Delega=
ted-IPv6-Prefix attribute" but RFC 4818 doesn't say this.  As one may<br>ha=
ve guessed=2C I would prefer that section 4 be deleted altogether=2C but if=
<br>the authors feel it necessary for it to be included=2C I suggest modify=
ing it<br>to at least be accurate and to include references to RFC 3962 and=
 RFC 4818.<br> <br>In sections 5.*=2C a blank line should be added before "=
Length" in the<br>Attribute summaries.<br> <br>In Section 7=2C an allocatio=
n policy must be specified=3B suggest just adding a<br>reference to RFC 357=
5.</pre><table style=3D"border-top: 1px solid black=3B font-weight: bold=3B=
 font-family: 'Segoe UI'=2CTahoma=2Csan-serif=3B"><tbody><tr><td><a href=3D=
"http://im.live.com/Messenger/IM/Home/?source=3DEML_WLHM_GreaterGood" style=
=3D"font-size: 9pt=3B color: rgb(1=2C 132=2C 203)=3B text-decoration: none=
=3B"><span style=3D"padding: 0px 24px=3B font-size: 8pt=3B color: rgb(63=2C=
 181=2C 85)=3B text-decoration: underline=3B"></span></a><br></td></tr></tb=
ody></table> 		 	   		  </body>
</html>=

--_58a2a7eb-2536-4948-8f4a-b8b2eac4f905_--

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


Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2010 19:01:24 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: AD review of draft-ietf-radext-status-server-06.txt
Date: Tue, 9 Mar 2010 20:00:11 +0100
Message-ID: <[e-mail]>
Thread-Topic: AD review of draft-ietf-radext-status-server-06.txt
Thread-Index: Acq/ur52dL8YmGwYRyGW/2lbLqA5AA==
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: <[e-mail]>

I have reviewed the I-D draft-ietf-radext-status-server-06.txt. The
document is in good shape and ready to be sent to IETF Last Call. The
comments below can be considered together with the other comments
received during the IETF Last Call.=20

The comments are divided into Technical and Editorial.=20

T1. The document is using the Status-Server Code (12) which is
experimental. Why is not the intended status of the document
experimental?=20

T2. The following requirements seem to conflict:=20

- section 4.1: 'The client MAY increment packet counters as a result of
sending a
   Status-Server request, or receiving a Response packet. '

- section 4.6.2: ' Clients implementing Status-Server MUST NOT increment
[RFC4668] or
   [RFC4670] counters upon reception of Response packets to Status-
   Server queries. '

I think that the later is better.=20

T3. The following requirements seem to conflict:=20

- section 4.2: 'The server MAY increment packet counters as a result of
receiving a
   Status-Server, or sending a Response packet. '

- section 4.6.1: '...when a server fully implements
   Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST
   be unaffected by the transmission or reception of packets relating to
   Status-Server.'

I think that the later is better.=20


E1. I could not understand the logic of the different alignments of
paragraphs in Section 3.=20

E2. In section 4.1 I do not like the word 'Robust' in ' Robust
implementations SHOULD accept any Response packet ...'

E3. In the same section I think that 'should' in the following phrase
needs to be capitalized:=20

> That is, prior to accepting the response as valid, the client should
   check that the Response packet Code field is either Access-Accept (2)
   or Accounting-Response (5). =20

E4. In the same section I think that the MUST in the following phrase
needs not be capitalized:=20

> If the Response Authenticator is valid,
   then the packet MUST be deemed to be a valid response from the
   server.

E5. In Section 4.5 s/Each RADIUS Proxyhas/Each RADIUS Proxy has/


Thanks and Regards,

Dan


=20

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


Envelope-to: [e-mail]
Delivery-date: Tue, 09 Mar 2010 17:16:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: AD review of draft-ietf-radext-tcp-transport-05
Date: Tue, 9 Mar 2010 18:14:45 +0100
Message-ID: <[e-mail]>
Thread-Topic: AD review of draft-ietf-radext-tcp-transport-05
Thread-Index: Acq/rAP0GuWJ8F1RRmWfbki3HIknWw==
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: <[e-mail]>

Please find below the AD review of AD review of
draft-ietf-radext-tcp-transport-05. I believe that the document will be
ready for IETF Last Call only after the issues raised in this review are
addressed.=20

The issues are divided into Technical (T) and Editorial (E).=20

T1. The document is marked as EXPERIMENTAL. It would be useful if it
mentions in one of the introductory sections what are the goals and
limitations (if any) of the experimental deployment and what would be
the success criteria of the experiment that would allow for taking the
document to the standards track later.=20

T2. Section 2.2:=20

>  Since these ports are unused by existing RADIUS implementations, the
   assigned values SHOULD be used as the default ports for RADIUS over
   TCP.

Why is this a SHOULD and not a MUST?=20

T3. Section 2.3 needs a complete re-writing:=20

> The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670],
   [RFC4671], [RFC4672], and [RFC4673] each contain only one reference
   to UDP.  These references are in the DESCRIPTION field of the MIB
   Module definition, and are in the form of "The UDP port" or "the UDP
   destination port".

Actually the count is not accurate. 4688 and 4670 have each two MIB
objects that refer to UDP ports, 4669 and 4671 have none, 4672 and 4673
have one each, but only in 4672 the port is referred to as UDP port
(although it is clear from the context that UDP is assumed).=20

> Implementations of RADIUS over TCP SHOULD re-use these MIB Modules to
   perform statistics counting for RADIUS over TCP connections.
   However, implementors are warned that there is no way for these MIB
   Modules to distinguish between packets sent over UDP or over TCP
   transport. =20

This does not work. One cannot know what current implementations do.
Some may behave as described here, but other may not and could count
statistics strictly over UDP as defined in the DESCRIPTION of the MIB
objects. You cannot count on that the agent implementations will do, so
there is no interoperability. =20

>   Implementations of RADIUS over TCP SHOULD include the protocol (UDP)
   or (TCP) in the radiusAuthServIdent, radiusAuthClientID,
   radiusAuthClientIdentifier, radiusAccServIdent, radiusAccClientID, or
   radiusAccClientIdentifier fields of the MIB Module.  This information
   can help the administrator distinguish capabilities of systems in the
   network.

This is also broken. First it is a change in the semantics of the
respective objects. This cannot be done even in a MIB document that
updates the respective RFCs because of the SMIv2 rules. Then these
objects are of a syntax of SnmpAdminString - so including the protocol
is based on non-interoperable heuristics. Last, describing the
capabilities (UDP, TCP or both) does not indicate what runs and is
activated at a certain moment, not to speak cannot indicate anything
about specific sessions between clients and servers.=20

The correct solution is for the MIB documents to be updated in the
future with new MIB objects of appropriate syntax. For the time being
the only thing that this section should say is that the MIB modules do
not support RADIUS over TCP and that they will need to be updated in the
future.=20

T4. The following section in 2.6.1 is confusing:=20

>  Much of the discussion in this section can be summarized by the
   following requirement.  RADIUS requests MAY be re-transmitted
   verbatim only if the following 5-tuple (Client IP address, Client
   port, Transport Protocol, Server IP address, Server port) remains the
   same.=20

Actually this is not a retransmission on the same connection, so I do
not know why it needs to be mentioned at all. This aparently contradicts
the first paragraph of 2.6.1 which says 'As TCP is a reliable transport,
implementations MUST NOT retransmit RADIUS request packets over a given
TCP connection.'.=20

T5. The last paragraph in 2.6.1:=20

>   The above requirement is necessary, but not sufficient in all cases.
   Other specifications give additional situations where the packet is
   to be considered as a new request.  Those recommendations MUST also
   be followed.

Having a MUST requirement over undefined 'other specification' is not
implementable. I would suggest to either clarify what are these 'other
specifications' or take this out.=20


E1. Please expand TLS at first occurrence.=20

E2. The Introduction section speaks about 'the default Internet MTU
(576). Strictly speaking this value is not standardized in any place,
and later in section 1.1 reference is made to RADIUS packets being
restricted to 1500 octets in size. Looks like an unnecessary
inconsistency.=20

E3. Section 1.2 - the syntax in the RADIUS server definition is
inconsistent with the syntax of the rest of the definitions

E4. Section 2.6.7:=20

>  We RECOMMEND that implementors of this specification
   familiarize themselves with TCP application programming concepts.  We
   RECOMMEND also that existing TCP applications be examined with an eye
   to robustness, performance, scalability, etc.

The use of capitalized (a la 2119) keywords in a personalized phrase
does not make much sense. RECOMMEND is not a keyword actually. I suggest
rephrasing.=20

Regards,

Dan



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


Envelope-to: [e-mail]
Delivery-date: Mon, 08 Mar 2010 15:22:54 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG Agenda for IETF 77 -- Take Two
Date: Mon, 8 Mar 2010 07:22:49 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CABE90.2871B8B0"
Thread-Index: Acq9pnG8jvTU5Gw1Rt29XUSxBvrDGABLB40A
Content-Language: en-us

------=_NextPart_000_005E_01CABE90.2871B8B0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

IETF 77 RADEXT WG Meeting

Monday, March 22, 2010

1740 - 1940 Pacific Time

Redondo room

Anaheim, CA

 

Chairs:  Bernard Aboba  <mailto:[e-mail]>
[e-mail]

David Nelson  <mailto:d.b.nelson%40comcast.net> [e-mail]

 

Jabber room: radext at jabber.ietf.org (please join)

 

Agenda

 

17:40 - 17:50 PT: Preliminaries 

 

     Bluesheets

     Attendance

     Note takers

     Agenda bash

     Document Status

 

SECURE RADIUS TRANSPORT (30 minutes)

 

1750 - 1800 AM PT  RTLS, Stefan Winter (10 minutes)

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

 

1800 AM - 1810 PT NAI-Based Peer Discovery, Stefan Winter (10 minutes)

 <http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery>
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

 

1810 - 1820 PT RADIUS over DTLS, Alan DeKok (10 minutes)

 <http://tools.ietf.org/html/draft-dekok-radext-dtls>
http://tools.ietf.org/html/draft-dekok-radext-dtls

 

IPv6 (20 minutes)

 

1820 - 1830  RADIUS Attributes for IPv6 Networks, W. Dec (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

 

1830 - 1840  Accounting Extensions for IPv6, R. Maglione (10 minutes)

http://tools.ietf.org/html/draft-maglione-radext-ipv6-acct-extensions

 

Design Guidelines (50 minutes)

 

1840  - 1930  Design Guidelines, Alan DeKok (50 minutes)

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

 

Wrap-up (10 minutes)

 

1930 - 1940  Discussion and Next Steps:  WG Chairs & ADs (10 minutes)


------=_NextPart_000_005E_01CABE90.2871B8B0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

<div class=3DSection1>

<p class=3DMsoNormal>IETF 77 RADEXT WG Meeting<o:p></o:p></p>

<p class=3DMsoNormal>Monday, March 22, 2010<o:p></o:p></p>

<p class=3DMsoNormal>1740 - 1940 Pacific Time<o:p></o:p></p>

<p class=3DMsoNormal>Redondo room<o:p></o:p></p>

<p class=3DMsoNormal>Anaheim, CA<o:p></o:p></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>Chairs:&nbsp; Bernard =
Aboba <a
href=3D"mailto:[e-mail]"><span =
style=3D'color:black'>[e-mail]</span></a><o:p></o:p></sp=
an></p>

<p class=3DMsoNormal><span style=3D'color:black'>David Nelson <a
href=3D"mailto:d.b.nelson%40comcast.net"><span =
style=3D'color:black'>[e-mail]</span></a><o:p></o:p></span>=
</p>

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

<p class=3DMsoNormal><span style=3D'color:black'>Jabber room: radext at
jabber.ietf.org (please join)<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'color:black'>Agenda<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>17:40 &#8211; 17:50 PT: =
Preliminaries <o:p></o:p></span></p>

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

<p class=3DMsoNormal><span =
style=3D'color:black'>&nbsp;&nbsp;&nbsp;&nbsp;
Bluesheets<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:black'>&nbsp;&nbsp;&nbsp;&nbsp;
Attendance<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:black'>&nbsp;&nbsp;&nbsp;&nbsp; Note
takers<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:black'>&nbsp;&nbsp;&nbsp;&nbsp; Agenda
bash<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:black'>&nbsp;&nbsp;&nbsp;&nbsp; Document
Status<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>SECURE RADIUS TRANSPORT =
(30
minutes)<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>1750 &#8211; 1800 AM =
PT&nbsp; RTLS,
Stefan Winter (10 minutes)<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:black'>http://tools.ietf.org/html/draft-ietf-radext-radsec=
<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>1800 AM - 1810 PT =
NAI-Based Peer
Discovery, Stefan Winter (10 minutes)<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'color:black'><a
href=3D"http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery"><=
span
style=3D'color:black'>http://tools.ietf.org/html/draft-ietf-radext-dynami=
c-discovery</span></a><o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>1810 &#8211; 1820 PT =
RADIUS over DTLS,
Alan DeKok (10 minutes)<o:p></o:p></span></p>

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

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

<p class=3DMsoNormal><span style=3D'color:black'>IPv6 (20 =
minutes)<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>1820 &#8211; 1830 =
&nbsp;RADIUS
Attributes for IPv6 Networks, W. Dec (10 minutes)<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:black'>http://tools.ietf.org/html/draft-ietf-radext-ipv6-a=
ccess<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>1830 - 1840 =
&nbsp;Accounting
Extensions for IPv6, R. Maglione (10 minutes)<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:black'>http://tools.ietf.org/html/draft-maglione-radext-ip=
v6-acct-extensions<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>Design Guidelines (50 =
minutes)<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>1840 &nbsp;&#8211; 1930 =
&nbsp;Design
Guidelines, Alan DeKok (50 minutes)<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'color:black'>http://tools.ietf.org/html/draft-ietf-radext-design=
-guidelines<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>Wrap-up (10 =
minutes)<o:p></o:p></span></p>

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

<p class=3DMsoNormal><span style=3D'color:black'>1930 - 1940 =
&nbsp;Discussion and
Next Steps:&nbsp; WG Chairs &amp; ADs (10 minutes)<o:p></o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_005E_01CABE90.2871B8B0--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2010 03:30:23 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG Agenda for IETF 77 -- Take One
Date: Sat, 6 Mar 2010 19:29:50 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01CABD63.63D7CEE0"
Thread-Index: Acq9pnG8jvTU5Gw1Rt29XUSxBvrDGA==
Content-Language: en-us

------=_NextPart_000_0007_01CABD63.63D7CEE0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

IETF 77 RADEXT WG Meeting

Monday, March 22, 2010

1740 - 1940 Pacific Time

Redondo room

Anaheim, CA

 

Chairs:  Bernard Aboba [e-mail]

David Nelson [e-mail] <mailto:d.b.nelson%40comcast.net> 

 

Jabber room: radext at jabber.ietf.org (please join)

 

Agenda

 

17:40 - 17:50 PT: Preliminaries 

 

     Bluesheets

     Attendance

     Note takers

     Agenda bash

     Document Status

 

RADSEC (30 minutes)

 

1750 - 1805 AM PT  RADSEC, Stefan Winter (15 minutes)

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

 

1805 AM - 1820 PT NAI-Based Peer Discovery, Stefan Winter (15 minutes)

http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

 

IPv6 (20 minutes)

 

1820 - 1830  RADIUS Attributes for IPv6 Networks, W. Dec (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

 

1830 - 1840  Accounting Extensions for IPv6, R. Maglione (10 minutes)

http://tools.ietf.org/html/draft-maglione-radext-ipv6-acct-extensions

 

Design Guidelines (50 minutes)

 

1840  - 1930  Design Guidelines, Alan DeKok (50 minutes)

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

 

Wrap-up (10 minutes)

 

1930 - 1940  Discussion and Next Steps:  WG Chairs & ADs (10 minutes)


------=_NextPart_000_0007_01CABD63.63D7CEE0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

<div class=3DSection1>

<p class=3DMsoNormal>IETF 77 RADEXT WG Meeting<o:p></o:p></p>

<p class=3DMsoNormal>Monday, March 22, 2010<o:p></o:p></p>

<p class=3DMsoNormal>1740 - 1940 Pacific Time<o:p></o:p></p>

<p class=3DMsoNormal>Redondo room<o:p></o:p></p>

<p class=3DMsoNormal>Anaheim, CA<o:p></o:p></p>

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

<p class=3DMsoNormal>Chairs:&nbsp; Bernard Aboba <a
href=3D"mailto:[e-mail]">[e-mail]</a><o=
:p></o:p></p>

<p class=3DMsoNormal>David Nelson <a =
href=3D"mailto:d.b.nelson%40comcast.net">[e-mail]</a><o:p><=
/o:p></p>

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

<p class=3DMsoNormal>Jabber room: radext at jabber.ietf.org (please =
join)<o:p></o:p></p>

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

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

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

<p class=3DMsoNormal>17:40 &#8211; 17:50 PT: Preliminaries =
<o:p></o:p></p>

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

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

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

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

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

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

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

<p class=3DMsoNormal>RADSEC (30 minutes)<o:p></o:p></p>

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

<p class=3DMsoNormal>1750 &#8211; 1805 AM PT&nbsp; RADSEC, Stefan Winter =
(15
minutes)<o:p></o:p></p>

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

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

<p class=3DMsoNormal>1805 AM - 1820 PT NAI-Based Peer Discovery, Stefan =
Winter
(15 minutes)<o:p></o:p></p>

<p =
class=3DMsoNormal>http://tools.ietf.org/html/draft-ietf-radext-dynamic-di=
scovery<o:p></o:p></p>

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

<p class=3DMsoNormal>IPv6 (20 minutes)<o:p></o:p></p>

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

<p class=3DMsoNormal>1820 &#8211; 1830 &nbsp;RADIUS Attributes for IPv6 =
Networks,
W. Dec (10 minutes)<o:p></o:p></p>

<p =
class=3DMsoNormal>http://tools.ietf.org/html/draft-ietf-radext-ipv6-acces=
s<o:p></o:p></p>

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

<p class=3DMsoNormal>1830 - 1840 &nbsp;Accounting Extensions for IPv6, =
R.
Maglione (10 minutes)<o:p></o:p></p>

<p =
class=3DMsoNormal>http://tools.ietf.org/html/draft-maglione-radext-ipv6-a=
cct-extensions<o:p></o:p></p>

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

<p class=3DMsoNormal>Design Guidelines (50 minutes)<o:p></o:p></p>

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

<p class=3DMsoNormal>1840 &nbsp;&#8211; 1930 &nbsp;Design Guidelines, =
Alan DeKok
(50 minutes)<o:p></o:p></p>

<p =
class=3DMsoNormal>http://tools.ietf.org/html/draft-ietf-radext-design-gui=
delines<o:p></o:p></p>

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

<p class=3DMsoNormal>Wrap-up (10 minutes)<o:p></o:p></p>

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

<p class=3DMsoNormal>1930 - 1940 &nbsp;Discussion and Next Steps:&nbsp; =
WG Chairs
&amp; ADs (10 minutes)<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0007_01CABD63.63D7CEE0--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 07 Mar 2010 03:09:18 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: <[e-mail]>
Subject: Request for Minutes
Date: Sat, 6 Mar 2010 19:07:08 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01CABD60.3B483B20"
Thread-Index: Acq9o0R1jq/PRvlvQyOjaEbA0ED1Bg==
Content-Language: en-us

------=_NextPart_000_0002_01CABD60.3B483B20
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

If you took minutes at the Virtual Interim, please send them to Dave Nelson
and myself. 


------=_NextPart_000_0002_01CABD60.3B483B20
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

<div class=3DSection1>

<p class=3DMsoNormal>If you took minutes at the Virtual Interim, please =
send them
to Dave Nelson and myself. <o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0002_01CABD60.3B483B20--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Mar 2010 15:54:19 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Stefan Winter'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D Action:draft-ietf-radext-dynamic-discovery-02.txt
Date: Fri, 5 Mar 2010 07:53:25 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Acq8dAnKFGsOUjLGRtqgXqHvLoUdvQAB+ZOQ
Content-Language: en-us

Can you summarize which issues were closed and which are open?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Stefan Winter
Sent: Friday, March 05, 2010 6:52 AM
To: [e-mail]
Cc: TF-Mobility
Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-02.txt

Hi,

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the RADIUS EXTensions Working Group of =
the
IETF.
>
>
> 	Title           : NAI-based Dynamic Peer Discovery for RADIUS over
TLS and DTLS
> 	Author(s)       : S. Winter, M. McCauley
> 	Filename        : draft-ietf-radext-dynamic-discovery-02.txt
> 	Pages           : 9
> 	Date            : 2010-03-05
>
> This document specifies a means to find authoritative AAA servers for=20
> a given NAI realm.  It can be used in conjunction with RADIUS over TLS =

> and RADIUS over DTLS.
>  =20

This draft contains new text for the issues discussed previously on the
list. It doesn't update any text on the remaining items which are still
unresolved.

Greetings,

Stefan

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




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


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Mar 2010 14:52:17 +0000
Message-ID: <[e-mail]>
Date: Fri, 05 Mar 2010 15:51:41 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0
MIME-Version: 1.0
To: [e-mail]
CC: TF-Mobility <[e-mail]>
Subject: Re: I-D Action:draft-ietf-radext-dynamic-discovery-02.txt
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig159DA82E79CE5FC3BEAE2065"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig159DA82E79CE5FC3BEAE2065
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi,

> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
> This draft is a work item of the RADIUS EXTensions Working Group of the=
 IETF.
>
>
> 	Title           : NAI-based Dynamic Peer Discovery for RADIUS over TLS=
 and DTLS
> 	Author(s)       : S. Winter, M. McCauley
> 	Filename        : draft-ietf-radext-dynamic-discovery-02.txt
> 	Pages           : 9
> 	Date            : 2010-03-05
>
> This document specifies a means to find authoritative AAA servers for
> a given NAI realm.  It can be used in conjunction with RADIUS over
> TLS and RADIUS over DTLS.
>  =20

This draft contains new text for the issues discussed previously on the
list. It doesn't update any text on the remaining items which are still
unresolved.

Greetings,

Stefan

--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]



--------------enig159DA82E79CE5FC3BEAE2065
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuRGoEACgkQ+jm90f8eFWYTxQCfWfVHzG90TZjng2No01ZMvvxH
iOIAnil2YQKk+PMd8w19gsZ08b8meDCh
=ecX8
-----END PGP SIGNATURE-----

--------------enig159DA82E79CE5FC3BEAE2065--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Mar 2010 14:45:56 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-dynamic-discovery-02.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri,  5 Mar 2010 06:45: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           : NAI-based Dynamic Peer Discovery for RADIUS over TLS and DTLS
	Author(s)       : S. Winter, M. McCauley
	Filename        : draft-ietf-radext-dynamic-discovery-02.txt
	Pages           : 9
	Date            : 2010-03-05

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

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

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

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

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

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

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Mar 2010 12:36:39 +0000
Message-ID: <[e-mail]>
Date: Fri, 05 Mar 2010 13:36:12 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Issue 324: Proposed new name resolution with S-NAPTR
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

Hi,

after issue 324's reminder about NAPTR, the following text might address
the issue:

"2.2.  DNS RR definition

   DNS definitions of RADIUS/TLS servers can be either S-NAPTR records
   (see [RFC3958]) or SRV records.  When both are defined, the
   resolution algorithm prefers S-NAPTR results (see section Section 2.3
   below).

   This specification defines two S-NAPTR service tag: a general-purpose
   tag "nai-roaming" and a special-purpose tag "eduroam" for the eduroam
   roaming consortium.  This specification defines two S-NAPTR protocol
   tags: "radius.tls" for RADIUS over TLS [I-D.ietf-radext-radsec] and
   "radius.dtls" for RADIUS over DTLS [I-D.dekok-radext-dtls].

   This specification defines the SRV prefix "_radiustls._tcp" for
   RADIUS over TLS [I-D.ietf-radext-radsec] and "_radiustls._udp" for
   RADIUS over DTLS [I-D.dekok-radext-dtls].  It is expected that in
   most cases, the label used for the records is the DNS representation
   (punycode) of the literal realm name for which the server is the AAA
   server."

Accompanied by an IANA Consideration section:

"4.  IANA Considerations

   This document requests IANA registration of the following S-NAPTR
   parameters:

   o  Application Service Tags

      *  nai-roaming

      *  eduroam

   o  Application Protocol Tags

      *  radius.tls

      *  radius.dtls"


This is one of three ways how I could see the resolution happen. They are

1) a single "nai-roaming" service tag, and if some consortium needs its
own, use x-<identifier>
2) a generic "nai-roaming" service tag, and further labels allocated per
their own RFC - I define my own one inline in this document
3) a tag+subtag mechanism (see also my mail to Leslie Daigle, forwarded
by Bernard) to allow e.g.:
   nai-roaming_eduroam.org
   nai-roaming_3gppnetworks.org
   nai-roaming_wimaxforum.com

Number 1 is always possible, but a bailout to unregulated space, with
possible clashes due to the freeform x-...
Number 2 is cumbersome for roaming consortia, because they need their
own RFC to describe themselves.
Number 3 would be cool, but would require allocation of a wildcard
"subspace" within the S-NAPTR service tag space. I'm unsure whether this
is foreseen.

I've put number 2 in the draft to have a starting point, but would
prefer 3 if we can sort it out.

Greetings,

Stefan Winter

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

Tel: [phone]
Fax: [phone]


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


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Mar 2010 12:26:33 +0000
Message-ID: <[e-mail]>
Date: Fri, 05 Mar 2010 13:25:32 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Review of draft-ietf-radext-dynamic-discovery-01
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

> [BA] References aren't allowed in the abstract.  Also, this is only abo=
ut RADIUS, not AAA in general, no?
>  =20

I've purged the reference in the upcoming revision. As for AAA vs.
RADIUS, there is still no conclusion about the dime vs. this approach,
and whether they can be united. Discussion continues; probably at the
dime meeting in Anaheim.

> 1.2
>
>    RadSec node: a RadSec client or server
>
>    RadSec Client: a RadSec instance which initiates a new connection.
>
>    RadSec Server: a RadSec instance which listens on a RadSec port and
>    accepts new connections
>
> [BA] As we discussed at IETF 75, RadSec is a product name.  Can we use =
"RADIUS over TLS" and "RADIUS over DTLS"=20
> (or maybe RAD-TLS and RAD-DTLS) instead?
>  =20

I've purged the references to "RadSec" in the upcoming revision. It is
now RADIUS over TLS, as in the corresponding draft.

> Section 2.1
>
>    Dynamic server discovery as defined in this document is only
>    applicable for AAA transactions where a AAA server receives a reques=
t
>    with a NAI realm for which no home AAA server is known.  I.e. where
>    static server configuration does not contain a known home
>    authentication server, or where the server configuration explicitly
>    states that the realm destination is to be looked up dynamically.
>    Furthermore, it is only applicable for new user sessions, i.e. for
>    the initial Access-Request. =20
>
> [BA] Is this about AAA in general (including Diameter) or just about RA=
DIUS?
>  =20

Again, subject to further discussion.

>
>       2.2. DNS RR definition
>
>
>
>    DNS definitions of RadSec servers can be either NAPTR records or SRV=

>    records.  When both are defined, the resolution algorithm prefers
>    NAPTR results (see section Section 2.3 <http://tools.ietf.org/html/d=
raft-ietf-radext-dynamic-discovery-01#section-2.3> below).  The NAPTR ser=
vice
>    field used is "AAAS+RADSECT".  The SRV prefix used is "_radsec._tcp"=
=2E
>    It is expected that in most cases, the label used for the records is=

>    the DNS representation (punycode) of the literal realm name for whic=
h
>    the server is the AAA server.
>
> [BA] Given that RadSec is a product name, what should the SRV prefixes =
be?=20
> _radtls._tcp?  _raddtls._udp?=20
>  =20

The _raddtls indicates datagram transport, so the _udp looks halfways
redundant and thus not clean.

I have preliminarily used _radiustls._tcp and _radiustls._udp in the draf=
t.

>    bank-rupt.com
>
> [BA] Suggest use of an example.com domain instead (e.g. bank.example.co=
m).=20
>  =20

I switched to the TLD "example" and a consortium member "bad" in the
upcoming revision.

>
>       2.3. Realm to AAA server resolution algorithm
>
>
>
>    Input I to the algorithm is a User-Name in the form of a NAI as
>    defined in [RFC4282 <http://tools.ietf.org/html/rfc4282>] as extract=
ed from the User-Name attribute in an
>    Access-Request.  Output O of the algorithm is a set of hostname:port=

>    and an assoiciated order/preference; the set can be empty.
>
>    Note well: The attribute User-Name does not necessarily contain well=
-
>    formed NAIs and may not even contain well-formed UTF-8 strings.  Thi=
s
>    document describes server discovery only for well-formed NAIs in
>    UTF-8 encoding.  The result of all other possible contents of User-
>    Name is unspecified; this includes, but is not limited to:
>
> [BA] Given the problems with RFC 4282 described by Alan at IETF 73, I'd=
 suggest not referencing RFC 4282
> if possible, just focusing on the User-Name attribute, which is defined=
 as UTF-8 by RFC 2865.=20
>  =20

There is still a need to talk about the local vs. realm separator
character. 4282's primary merit for the purposes of the NAI discovery
draft lies in defining the @ character to find the realm. I can drop the
literal reference to 4282, but would then need to write (duplicate) text
from 4282 about the @ character. Is that acceptable?

> As far as I can tell here, the issue here is whether it is possible to =
utilize the realm-name in UTF-8
> to resolve the address of the RADTLS/DTLS server.  As noted in the IAB =
document, there are several possible
> ways that this resolution could take place:
>
> a. An A/AAAA query could be sent via mDNS and/or LLMNR, using the realm=
 encoded in UTF-8.=20
> b. An A/AAAA query could be sent, by converting the realm in UTF-8 to p=
unycode, using ToASCII().=20
> c. An A/AAAA query could be sent, using the realm encoded in UTF-8.=20
>
> When attempting resolution via b), it is possible that the conversion w=
ill fail.  If none of the other=20
> resolution mechanisms are attempted, or if they fail too, then resoluti=
on of the server will not be=20
> possible.
>  =20

The input to the algorithm is a UTF-8 string. The draft then merely
mentions the "host's name resolution library". IMHO, it is then that
library's business to try several mechanism in some host-defined order
and for those, either convert the UTF-8 input into a form of its liking,
or use it directly. Especially after reading the IAB document, it seems
to me that going into more detail or prescribing a particular behaviour
will not work.

The case of the name resolution failing is mentioned in the sentence "If
name resolution returns with error, O =3D { }. Terminate."

Do you think more text is needed in this area?

> Now that the IDNAbis documents are headed toward WG last call, my recom=
mendation is to reference these,
> rather than IDNA.=20
>  =20

Hm, I don't think I managed IDNA explicitly at all. It only came to play
in the example where tu-m=FCnchen was resolved to punycode. Related to my=

argument above, whether or not a host name resultion library uses IDNA
(or -bis) is depending on the local host configuration for name
resolution. I'd rather not touch IDNA specialities at all, if that's
possible.

>
>       2.3. Realm to AAA server resolution algorithm
>
>
>
> In addition to the material here, I recommend providing advice on IPv4/=
IPv6 usage.  One issue that
> has been encountered in IPv6 implementations is that attempting to conn=
ect via IPv6 preferentially
> is problematic.  Even though a AAAA RR might be available, and IPv6 mig=
ht be supported and available
> on a link, this doesn't mean that IPv6 connectivity exists, due to rout=
ing table issues.  As a result,
> attempting bring up an IPv6 connection before failing over to IPv4 will=
 often result in a performance
> problem.  A better approach (implemented in MacOS X) is to attempt to b=
ring up both IPv4 and IPv6
> connections and then use the connection that comes up first.=20
>
> Section 3
>
>    [Note:
>    assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT
>    deliver the shared secret in the DNS response!]
>
> [BA] I certainly hope not. This somewhat begs the question of when serv=
er resolution is useful.  Presumably,
> this is primarily for use with certificate-based authentication, no?  I=
'd assume that if TLS PSK is being
> used then you'd have static configuration, correct?
>  =20

Mostly so, I guess. You could construct wild ideas about a consortium
having one PSK (or RADIUS shared secret) for all its realms, so using
some dynamic discovery might work across the consortium. But that's
really ugly. I suppose it's best to delete the UDP+SRV, and PSK+SRV text
completely.
=20
> Section 4
>
>    This document contains no actions for IANA.  Maybe.  Not sure about
>    the labels "AAAS+RADSECT" and "_radsec._tcp.".
>
> [BA] What about RADIUS over DTLS?  Does this document apply to that as =
well?=20
>  =20

This section was completely re-written to consider the S-NAPTR "stuff".
More on that in a separate mail.

Greetings,

Stefan Winter

--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]



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


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Mar 2010 09:59:24 +0000
Message-ID: <[e-mail]>
Date: Fri, 05 Mar 2010 10:57:59 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0
MIME-Version: 1.0
To: [e-mail]
CC: TF-Mobility <[e-mail]>
Subject: Re: I-D Action:draft-ietf-radext-radsec-06.txt
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig03B1854301C40493E76461E5"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig03B1854301C40493E76461E5
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Hi,


> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
> This draft is a work item of the RADIUS EXTensions Working Group of the=
 IETF.
>
>
> 	Title           : TLS encryption for RADIUS
> 	Author(s)       : S. Winter, et al.
> 	Filename        : draft-ietf-radext-radsec-06.txt
> 	Pages           : 17
> 	Date            : 2010-03-05
>
> This document specifies security on the transport layer (TLS) for the
> RADIUS protocol when transmitted over TCP.  This enables dynamic
> trust relationships between RADIUS servers.
>  =20

This version fixes the issues 306, 308 and 323 with text as recently
proposed on the list.

Since issue 307 was discussed in the Virtual Interim and dismissed as no
viable alternative, the text does not contain any changes to address this=
=2E

This should close all the filed issues against the draft. This revision
was created outside of my sponsor project's time.

Comments as always welcome,

Stefan Winter

--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]



--------------enig03B1854301C40493E76461E5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuQ1awACgkQ+jm90f8eFWZJSQCdH8yXDSN+0cyTannEfJCUzc9l
734An0+zYRgiGbf16qQCMsMCqCxZB+LA
=sTtm
-----END PGP SIGNATURE-----

--------------enig03B1854301C40493E76461E5--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 05 Mar 2010 08:31:04 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D Action:draft-ietf-radext-radsec-06.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Fri,  5 Mar 2010 00:30: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
	Author(s)       : S. Winter, et al.
	Filename        : draft-ietf-radext-radsec-06.txt
	Pages           : 17
	Date            : 2010-03-05

This document specifies security on the transport layer (TLS) for the
RADIUS protocol when transmitted over TCP.  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-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-radsec-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 03 Mar 2010 20:19:25 +0000
Date: Wed, 3 Mar 2010 12:18:47 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: "Wojciech Dec (wdec)" <[e-mail]>
cc: [e-mail]
Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Message-ID: <alpine.WNT.2.00.1003031205030.2788@littlesmurf>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 3 Mar 2010, Wojciech Dec (wdec) wrote:

>> My suggestion WRT an accounting restriction is based on a scenario:
>> Accounting system relies on RFC 3162 to report client IP.

>> NAS decides to send IPv6-Framed-Address rather than RFC 3162 method.
>> Accounting system requires modification to continue to
>> understand the same information.

> Yes, I see your point. Don't you think however that this could be 
> handled by a client knob/implementation? I.E. If in an access-accept a 
> server sends the IPv6-Framed-Address, then the NAS client can interpret 
> it to mean that its ok to use this attribute in accounting messages. If

> an IPv6-Framed-Address does not come down in an access-accept, then the
> NAS would use by default "whatever it uses today", unless it has been
> explicitly configured to send accounting info with using
> IPv6-Framed-Address.

> This would seem to cover your concerns. What do you think?

Yes, sounds reasonable.

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Wed, 03 Mar 2010 16:05:54 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: <[e-mail]>
Subject: Request for help in developing a tool that may be helpful to WG chairs (fwd)
Date: Wed, 3 Mar 2010 08:05:37 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0185_01CABAA8.4F02DC20"
Thread-Index: Acq661zeFaBGvwHiSxebS69aBTqz3A==
Content-Language: en-us

------=_NextPart_000_0185_01CABAA8.4F02DC20
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

 

-----Original Message-----
From: Scott O. Bradner
Sent: Wednesday, March 03, 2010 7:36 AM
To: [e-mail]
Subject: Request for help in developing a tool that may be helpful to WG
chairs

 

IETF working group chairs;

 

We are developing an open-source tool for monitoring the status and

progress of conflicts in on-line working groups (WG).  The tool works by

analyzing the WG mailing list.  When developed, this tool should be

helpful to WG chairs trying to understand the status of WG discussions

(how close to consensus is the WG, what is the distribution of

participation, etc).

 

As part of the development process we have been using a prototype tool

to analyze IETF WG mailing list archives to determine the amount of

conflict and how effective this conflict is being (has been) resolved.

As the first step, we need to understand the relationship between the

conflicts in a working group and the structure of the communication

network in that group. While having conflicts is not necessarily a bad

thing for a working group effort, some conflicts can escalate into

disasters. We are interested in finding the communication patterns

related to the evolution of group conflicts. Results from this study

will provide the base for the development of the tool that helps working

group chairs to decide when to intervene with an internal conflict

before it becomes irreversibly negative as well as being a tool that may

help determine where there is consensus on a particular topic.

 

We would like your help in understanding the level of conflicts within

your working groups and how the conflicts affect productivity and group

members' perception on the working group. It will be greatly appreciated

if you could ask your WG members to anonymously fill a short survey at 

 

https://spreadsheets.google.com/viewform?hl=en&formkey=dExTbEU5QmRncnhFbjhQU
VR4bzBGMEE6MA

 

Thank you!

 

Best Regards, 

 

Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun Qin

 

 


------=_NextPart_000_0185_01CABAA8.4F02DC20
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

<div class=3DSection1>

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

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

<p class=3DMsoPlainText>-----Original Message-----<br>
From: Scott O. Bradner<br>
Sent: Wednesday, March 03, 2010 7:36 AM<br>
To: [e-mail]<br>
Subject: Request for help in developing a tool that may be helpful to WG =
chairs<o:p></o:p></p>

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

<p class=3DMsoPlainText>IETF working group chairs;<o:p></o:p></p>

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

<p class=3DMsoPlainText>We are developing an open-source tool for =
monitoring the
status and<o:p></o:p></p>

<p class=3DMsoPlainText>progress of conflicts in on-line working groups =
(WG).&nbsp;
The tool works by<o:p></o:p></p>

<p class=3DMsoPlainText>analyzing the WG mailing list.&nbsp; When =
developed, this tool
should be<o:p></o:p></p>

<p class=3DMsoPlainText>helpful to WG chairs trying to understand the =
status of
WG discussions<o:p></o:p></p>

<p class=3DMsoPlainText>(how close to consensus is the WG, what is the
distribution of<o:p></o:p></p>

<p class=3DMsoPlainText>participation, etc).<o:p></o:p></p>

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

<p class=3DMsoPlainText>As part of the development process we have been =
using a
prototype tool<o:p></o:p></p>

<p class=3DMsoPlainText>to analyze IETF WG mailing list archives to =
determine the
amount of<o:p></o:p></p>

<p class=3DMsoPlainText>conflict and how effective this conflict is =
being (has
been) resolved.<o:p></o:p></p>

<p class=3DMsoPlainText>As the first step, we need to understand the =
relationship
between the<o:p></o:p></p>

<p class=3DMsoPlainText>conflicts in a working group and the structure =
of the
communication<o:p></o:p></p>

<p class=3DMsoPlainText>network in that group. While having conflicts is =
not
necessarily a bad<o:p></o:p></p>

<p class=3DMsoPlainText>thing for a working group effort, some conflicts =
can
escalate into<o:p></o:p></p>

<p class=3DMsoPlainText>disasters. We are interested in finding the =
communication
patterns<o:p></o:p></p>

<p class=3DMsoPlainText>related to the evolution of group conflicts. =
Results from
this study<o:p></o:p></p>

<p class=3DMsoPlainText>will provide the base for the development of the =
tool
that helps working<o:p></o:p></p>

<p class=3DMsoPlainText>group chairs to decide when to intervene with an =
internal
conflict<o:p></o:p></p>

<p class=3DMsoPlainText>before it becomes irreversibly negative as well =
as being
a tool that may<o:p></o:p></p>

<p class=3DMsoPlainText>help determine where there is consensus on a =
particular
topic.<o:p></o:p></p>

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

<p class=3DMsoPlainText>We would like your help in understanding the =
level of
conflicts within<o:p></o:p></p>

<p class=3DMsoPlainText>your working groups and how the conflicts affect
productivity and group<o:p></o:p></p>

<p class=3DMsoPlainText>members&#8217; perception on the working group. =
It will
be greatly appreciated<o:p></o:p></p>

<p class=3DMsoPlainText>if you could ask your WG members to anonymously =
fill a
short survey at <o:p></o:p></p>

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

<p =
class=3DMsoPlainText>https://spreadsheets.google.com/viewform?hl=3Den&amp=
;formkey=3DdExTbEU5QmRncnhFbjhQUVR4bzBGMEE6MA<o:p></o:p></p>

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

<p class=3DMsoPlainText>Thank you!<o:p></o:p></p>

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

<p class=3DMsoPlainText>Best Regards, <o:p></o:p></p>

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

<p class=3DMsoPlainText>Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun =
Qin<o:p></o:p></p>

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

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

</div>

</body>

</html>

------=_NextPart_000_0185_01CABAA8.4F02DC20--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 03 Mar 2010 09:21:28 +0000
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Date: Wed, 3 Mar 2010 10:19:14 +0100
Message-ID: <[e-mail]>
Thread-Topic: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Thread-Index: Acq6TKjqHVRfGaseRw6WJ1YaPaLHxQAZTd9g
From: "Wojciech Dec (wdec)" <[e-mail]>
To: "Peter Deacon" <[e-mail]>
Cc: <[e-mail]>

>=20
> > Given the above examples/reasons, would you still see a need to=20
> > restrict the use/naming of the attribute as suggested. What is your=20
> > concern with the proposed use?
>=20
> None WRT assignment/auth, thank you.
>=20
> My suggestion WRT an accounting restriction is based on a scenario:
>=20
> Accounting system relies on RFC 3162 to report client IP.
>=20
> NAS decides to send IPv6-Framed-Address rather than RFC 3162 method.
> Accounting system requires modification to continue to=20
> understand the same information.

Yes, I see your point. Don't you think however that this could be
handled by a client knob/implementation? I.E. If in an access-accept a
server sends the IPv6-Framed-Address, then the NAS client can interpret
it to mean that its ok to use this attribute in accounting messages. If
an IPv6-Framed-Address does not come down in an access-accept, then the
NAS would use by default "whatever it uses today", unless it has been
explicitly configured to send accounting info with using
IPv6-Framed-Address.
This would seem to cover your concerns. What do you think?

-Woj.

>=20
>=20
> From an accounting perspective specific to any one NAS with a known=20
> behavior use of IPv6-Framed-Address can certainly simplify matters.
>=20
> Globally it can have the opposite effect as an additional=20
> attribute/RFC=20
> possibly needs to be consulted to figure out the users=20
> IP..especially in=20
> instances where NAS are not under direct administrative control.
>=20
>=20
> Perhaps another way to resolve is to make a SHOULD/MAY=20
> recommendation to=20
> also send Framed-IPv6-Prefix/128 for accounting. =20
> Realistically IMHO its=20
> still early WRT IPv6 deployment and not likely to be a big=20
> deal either=20
> way.
>=20
> regards,
> Peter
>=20

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


Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2010 21:10:25 +0000
Date: Tue, 2 Mar 2010 13:09:25 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: "Wojciech Dec (wdec)" <[e-mail]>
cc: [e-mail]
Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Message-ID: <alpine.WNT.2.00.1003021143010.2316@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Tue, 2 Mar 2010, Wojciech Dec (wdec) wrote:

> Well, so rfc3162 was perhaps a bit too generous with the options here.
> It pretty much allows any combination of Framed-IPv6-Prefix,
> Framed-Interface-Id and Framed-IPv6-Pool to be used. A couple of
> examples:
> Things get interesting for a server given that we have the possibility
> of the NAS picking a prefix/address from a pool, and then sending an
> accounting record which may contain that address encoded as
> a) nothing (ie for the pool option the accounting record does not
> include the address, but only the pool name)
> b) a combination of a /64 ipv6-prefix and 64 bit interface-id
> c) a /128 in the ipv6-prefix (possibly coming also with a 64 interface
> id)
> D) Various vendor VSAs (which have been devised to work around the
> ambiguities of the above)

> A non trivial story applies for the client when the "to be assigned"
> numeral address can come down by any of the latter combinations, which
> the client needs to interpret for their sanity (eg how should a /120
> ipv6-prefix with a /64 interface id be handled). This is further
> compounded by the issue of having to potentially assign multiple
> addresses to a client (say a GUA and a ULA), using different methods
> (SLAAC and DHCP).

> With hindsight it may have been better to simply call out for a fixed
> length /128 address attribute to simplify some of these situations,
> especially when the intent is really that of communicating the exact
> /128 address. That's the role I see for the framed-ipv6-address
> attribute. It's role is to:
> 1) Be semantically very clear that this address doesn't need to be
> combined with some other attribute to form an address (it's a fixed
> length 128 field)
> 2) Allow for a distinction between multiple address assignment
> mechanisms on the interface and their source info (pretty much why
> rfc4818 could not have used the framed-ipv6-prefix attribute, even
> though all it does is communicate a prefix)
> 3) Allow for the /128 address to be un-ambiguously communicated in
> accounting messages (as opposed to having to guess between the
> combinations)

>> Paradoxically I like the idea of the new attribute...
>> Ideas:
>> Make IPv6-Framed-Address valid for authentication only.
>> Relabel the attribute (ie IPv6-Framed-DHCP-Address)

> Given the above examples/reasons, would you still see a need to restrict 
> the use/naming of the attribute as suggested. What is your concern with 
> the proposed use?

None WRT assignment/auth, thank you.

My suggestion WRT an accounting restriction is based on a scenario:

Accounting system relies on RFC 3162 to report client IP.

NAS decides to send IPv6-Framed-Address rather than RFC 3162 method.
Accounting system requires modification to continue to understand the same 
information.


>From an accounting perspective specific to any one NAS with a known 
behavior use of IPv6-Framed-Address can certainly simplify matters.

Globally it can have the opposite effect as an additional attribute/RFC 
possibly needs to be consulted to figure out the users IP..especially in 
instances where NAS are not under direct administrative control.


Perhaps another way to resolve is to make a SHOULD/MAY recommendation to 
also send Framed-IPv6-Prefix/128 for accounting.  Realistically IMHO its 
still early WRT IPv6 deployment and not likely to be a big deal either 
way.

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2010 19:17:27 +0000
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Date: Tue, 2 Mar 2010 20:16:50 +0100
Message-ID: <[e-mail]>
Thread-Topic: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Thread-Index: Acq6HP1Oqr1jPsKxRKWfutMXEdMTLAACYpAA
From: "Wojciech Dec (wdec)" <[e-mail]>
To: "Peter Deacon" <[e-mail]>
Cc: <[e-mail]>

=20

> -----Original Message-----
> From: Peter Deacon [mailto:[e-mail]]=20
> Sent: 02 March 2010 16:28
> To: Wojciech Dec (wdec)
> Cc: [e-mail]
> Subject: RE: RADEXT WG last call on RADIUS attributes for=20
> IPv6 Access Networks
>=20
> On Tue, 2 Mar 2010, Wojciech Dec (wdec) wrote:
>=20
> >> If the /128 prefix approach is used should I expect that=20
> an IP would=20
> >> be assigned to the end user?
> >> Just don't want existing stuff to become broken :(
>=20
> > Precisely that's the reason for having the new attribute as=20
> opposed to=20
> > overloading the previous one for the case when the full=20
> /128 is to be=20
> > passed down instead of a /64 (or less) for use in SLAAC. Having the=20
> > two separated ensures that existing stuff doesn't get broken.
>=20
> Up until the point where the draft is accepted, how would=20
> someone have assigned or accounted for a single IPv6 address?

Well, so rfc3162 was perhaps a bit too generous with the options here.
It pretty much allows any combination of Framed-IPv6-Prefix,
Framed-Interface-Id and Framed-IPv6-Pool to be used. A couple of
examples:
Things get interesting for a server given that we have the possibility
of the NAS picking a prefix/address from a pool, and then sending an
accounting record which may contain that address encoded as=20
a) nothing (ie for the pool option the accounting record does not
include the address, but only the pool name)=20
b) a combination of a /64 ipv6-prefix and 64 bit interface-id=20
c) a /128 in the ipv6-prefix (possibly coming also with a 64 interface
id)
D) Various vendor VSAs (which have been devised to work around the
ambiguities of the above)

A non trivial story applies for the client when the "to be assigned"
numeral address can come down by any of the latter combinations, which
the client needs to interpret for their sanity (eg how should a /120
ipv6-prefix with a /64 interface id be handled). This is further
compounded by the issue of having to potentially assign multiple
addresses to a client (say a GUA and a ULA), using different methods
(SLAAC and DHCP).
With hindsight it may have been better to simply call out for a fixed
length /128 address attribute to simplify some of these situations,
especially when the intent is really that of communicating the exact
/128 address. That's the role I see for the framed-ipv6-address
attribute. It's role is to:
1) Be semantically very clear that this address doesn't need to be
combined with some other attribute to form an address (it's a fixed
length 128 field)
2) Allow for a distinction between multiple address assignment
mechanisms on the interface and their source info (pretty much why
rfc4818 could not have used the framed-ipv6-prefix attribute, even
though all it does is communicate a prefix)
3) Allow for the /128 address to be un-ambiguously communicated in
accounting messages (as opposed to having to guess between the
combinations)

>=20
> From my read of RFC 3162 there is no mention of an underlying=20
> technology association with Framed-IPv6-Prefix - be it=20
> SLAAC/ND, DHCPv6 or a future technology yet to exist.

Well, the Framed-Interface-Id is quite specific to its use with PPP and
IPCPv6, so one could say that the underlying technology is being
reflected in Radius...
>=20
> Given the design of IPv6 is a shift to assignment and=20
> identification via prefix it seems reasonable /128 prefixes=20
> would already be used in this way at the very least in=20
> accounting messages for sessions or sub-sessions involving=20
> individual hosts.
>=20
> Paradoxically I like the idea of the new attribute...
>=20
> Ideas:
>=20
> Make IPv6-Framed-Address valid for authentication only.
>=20
> Relabel the attribute (ie IPv6-Framed-DHCP-Address)

Given the above examples/reasons, would you still see a need to restrict
the use/naming of the attribute as suggested. What is your concern with
the proposed use?

Thanks,
Woj.
>=20
> regards,
> Peter
>=20

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


Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2010 15:28:54 +0000
Date: Tue, 2 Mar 2010 07:27:55 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: "Wojciech Dec (wdec)" <[e-mail]>
cc: [e-mail]
Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Message-ID: <alpine.WNT.2.00.1003020450400.2316@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Tue, 2 Mar 2010, Wojciech Dec (wdec) wrote:

>> If the /128 prefix approach is used should I expect that an
>> IP would be assigned to the end user?
>> Just don't want existing stuff to become broken :(

> Precisely that's the reason for having the new attribute as opposed to 
> overloading the previous one for the case when the full /128 is to be
> passed down instead of a /64 (or less) for use in SLAAC. Having the two 
> separated ensures that existing stuff doesn't get broken.

Up until the point where the draft is accepted, how would someone have 
assigned or accounted for a single IPv6 address?

>From my read of RFC 3162 there is no mention of an underlying technology 
association with Framed-IPv6-Prefix - be it SLAAC/ND, DHCPv6 or a future 
technology yet to exist.

Given the design of IPv6 is a shift to assignment and identification via 
prefix it seems reasonable /128 prefixes would already be used in this way 
at the very least in accounting messages for sessions or sub-sessions 
involving individual hosts.

Paradoxically I like the idea of the new attribute...

Ideas:

Make IPv6-Framed-Address valid for authentication only.

Relabel the attribute (ie IPv6-Framed-DHCP-Address)

regards,
Peter

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


Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2010 11:31:31 +0000
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Date: Tue, 2 Mar 2010 12:29:55 +0100
Message-ID: <[e-mail]>
Thread-Topic: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Thread-Index: Acq5lRI4QPEo2MDlSLeyKnpRCWkZygAZlZkQ
From: "Wojciech Dec (wdec)" <[e-mail]>
To: "Peter Deacon" <[e-mail]>, "Bernard Aboba" <[e-mail]>
Cc: <[e-mail]>

=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Peter Deacon
> Sent: 02 March 2010 00:15
> To: Bernard Aboba
> Cc: [e-mail]
> Subject: RE: RADEXT WG last call on RADIUS attributes for=20
> IPv6 Access Networks
>=20
> On Mon, 1 Mar 2010, Bernard Aboba wrote:
>=20
> > Yes, there is a difference.  Framed-IPv6-Prefix is specifically for=20
> > use within a Router Advertisement. So if the RADIUS server were to=20
> > send a Framed-IPv6-Prefix of /128 to the NAS, this would be=20
> inserted=20
> > in the RA by the NAS (which is probably not what you want).
>=20
> RFC3162 does not mention which underlying technology is used=20
> for assignment.
>=20
> > An IPv6-Framed-Address on the other hand, is for use within=20
> the NAS's=20
> > embedded DHCPv6 server.
>=20
> DHCPv6 is capable of assignment of both single addresses and prefixes.
>=20
> > Note that it is possible for a NAS to support *both* stateless=20
> > autoconfig and DHCPv6, so that both attributes could be=20
> present in the=20
> > same Access-Accept.  This is yet another reason why distinct=20
> > attributes are required -- how else could the NAS figure out which=20
> > attribute is to be used for what purpose?
>=20
> The way I see consistancy is leaving "how" up to the NAS and=20
> authorization attributes "what" (Prefixes, Ipv6 or both) up=20
> to the draft.
>=20
> A more to the point and salient question - what is the=20
> expected difference in behavior for an access server should=20
> Framed-IPv6-Prefix /128 be used in lieu of IPv6-Framed-Address?
>=20
> If the /128 prefix approach is used should I expect that an=20
> IP would be assigned to the end user?
>=20
> Just don't want existing stuff to become broken :(

Precisely that's the reason for having the new attribute as opposed to
overloading the previous one for the case when the full /128 is to be
passed down instead of a /64 (or less) for use in SLAAC. Having the two
separated ensures that existing stuff doesn't get broken.

Regards,
Woj.

>=20
> regards,
> Peter
>=20
> > -----Original Message-----
> > From: [e-mail]=20
> > [mailto:[e-mail]] On Behalf Of Peter Deacon
> > Sent: Monday, March 01, 2010 12:12 PM
> > To: [e-mail]
> > Subject: Re: RADEXT WG last call on RADIUS attributes for=20
> IPv6 Access=20
> > Networks
> >
> > On Mon, 1 Mar 2010, Bernard Aboba wrote:
> >
> >> This is an announcement of RADEXT WG last call on "RADIUS=20
> attributes=20
> >> for IPv6 Access Networks" before sending the document off=20
> to the IESG=20
> >> for consideration as a Proposed Standard.  A copy of the=20
> document is=20
> >> available for inspection here:
> >
> >> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access
> >
> > 3.1.
> >
> > I'm confused on IPv6-Framed-Address and Framed-IPv6-Prefix=20
> from RFC 3162.
> > It looks as if both attributes accomplish the same goal. =20
> Is there a=20
> > difference between IPv6-Framed-Address and=20
> Framed-IPv6-Prefix of /128?
> >
> > regards,
> > Peter
> >
> >
>=20

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


Envelope-to: [e-mail]
Delivery-date: Tue, 02 Mar 2010 10:45:14 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_6bf603e7-78de-41bc-9ba0-4c3bc5bce7f6_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Date: Tue, 2 Mar 2010 02:44:27 -0800
MIME-Version: 1.0

--_6bf603e7-78de-41bc-9ba0-4c3bc5bce7f6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> DHCPv6 is capable of assignment of both single addresses and prefixes.

Delegation is addressed in RFC 4818.
=20
> If the /128 prefix approach is used should I expect that an IP would be a=
ssigned to the end user?

You should not expect a DHCPv6 address to be assigned.  On some NASes I wou=
ldn't expect *any* address to be assigned.
 		 	   		  =

--_6bf603e7-78de-41bc-9ba0-4c3bc5bce7f6_
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 DHCPv6 is capable of assignment of both single addresses and prefixe=
s.<br><br>Delegation is addressed in RFC 4818.<br>&nbsp=3B<br>&gt=3B If the=
 /128 prefix approach is used should I expect that an IP would be assigned =
to the end user?<br><br>You should not expect a DHCPv6 address to be assign=
ed.&nbsp=3B On some NASes I wouldn't expect *any* address to be assigned.<b=
r> 		 	   		  </body>
</html>=

--_6bf603e7-78de-41bc-9ba0-4c3bc5bce7f6_--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2010 23:15:10 +0000
Date: Mon, 1 Mar 2010 15:14:43 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: Bernard Aboba <[e-mail]>
cc: [e-mail]
Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Message-ID: <alpine.WNT.2.00.1003011339340.2788@littlesmurf>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="263493264-16920-1267485283=:2788"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--263493264-16920-1267485283=:2788
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 1 Mar 2010, Bernard Aboba wrote:

> Yes, there is a difference.  Framed-IPv6-Prefix is specifically for use 
> within a Router Advertisement. So if the RADIUS server were to send a 
> Framed-IPv6-Prefix of /128 to the NAS, this would be inserted in the RA 
> by the NAS (which is probably not what you want).

RFC3162 does not mention which underlying technology is used for 
assignment.

> An IPv6-Framed-Address on the other hand, is for use within the NAS's 
> embedded DHCPv6 server.

DHCPv6 is capable of assignment of both single addresses and prefixes.

> Note that it is possible for a NAS to support *both* stateless 
> autoconfig and DHCPv6, so that both attributes could be present in the 
> same Access-Accept.  This is yet another reason why distinct attributes 
> are required -- how else could the NAS figure out which attribute is to 
> be used for what purpose?

The way I see consistancy is leaving "how" up to the NAS and authorization 
attributes "what" (Prefixes, Ipv6 or both) up to the draft.

A more to the point and salient question - what is the expected difference 
in behavior for an access server should Framed-IPv6-Prefix /128 be used in 
lieu of IPv6-Framed-Address?

If the /128 prefix approach is used should I expect that an IP would be 
assigned to the end user?

Just don't want existing stuff to become broken :(

regards,
Peter

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Peter Deacon
> Sent: Monday, March 01, 2010 12:12 PM
> To: [e-mail]
> Subject: Re: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
>
> On Mon, 1 Mar 2010, Bernard Aboba wrote:
>
>> This is an announcement of RADEXT WG last call on “RADIUS attributes for IPv6
>> Access Networks” before sending the document off to the IESG for
>> consideration as a Proposed Standard.  A copy of the document is available
>> for inspection here:
>
>> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access
>
> 3.1.
>
> I'm confused on IPv6-Framed-Address and Framed-IPv6-Prefix from RFC 3162.
> It looks as if both attributes accomplish the same goal.  Is there a
> difference between IPv6-Framed-Address and Framed-IPv6-Prefix of /128?
>
> regards,
> Peter
>
>
--263493264-16920-1267485283=:2788--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2010 20:49:14 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "'Peter Deacon'" <[e-mail]>, <[e-mail]>
Subject: RE: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Date: Mon, 1 Mar 2010 12:48:56 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Acq5fB+Obds5AhCTR6if6IjJVBKJiwAA/9rw
Content-Language: en-us

Yes, there is a difference.  Framed-IPv6-Prefix is specifically for use =
within a Router Advertisement.=20
So if the RADIUS server were to send a Framed-IPv6-Prefix of /128 to the =
NAS, this would be inserted
in the RA by the NAS (which is probably not what you want).=20

An IPv6-Framed-Address on the other hand, is for use within the NAS's =
embedded DHCPv6 server. =20

Note that it is possible for a NAS to support *both* stateless =
autoconfig and DHCPv6, so that both
attributes could be present in the same Access-Accept.    This is yet =
another reason why distinct
attributes are required -- how else could the NAS figure out which =
attribute is to be used for what
purpose?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] =
On Behalf Of Peter Deacon
Sent: Monday, March 01, 2010 12:12 PM
To: [e-mail]
Subject: Re: RADEXT WG last call on RADIUS attributes for IPv6 Access =
Networks

On Mon, 1 Mar 2010, Bernard Aboba wrote:

> This is an announcement of RADEXT WG last call on =E2=80=9CRADIUS =
attributes for IPv6
> Access Networks=E2=80=9D before sending the document off to the IESG =
for
> consideration as a Proposed Standard.  A copy of the document is =
available
> for inspection here:

> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

3.1.

I'm confused on IPv6-Framed-Address and Framed-IPv6-Prefix from RFC =
3162.=20
It looks as if both attributes accomplish the same goal.  Is there a=20
difference between IPv6-Framed-Address and Framed-IPv6-Prefix of /128?

regards,
Peter


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


Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2010 20:24:05 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1267475025; bh=Rhfxe8QTEvbneAj98ctdkrAxE7Ck9+ekzMsuv536afU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=h/4zyTDYdHi1G8Ulwmnc61k0/LL5Gbt5waPxEuG3j4LrO0pfEIu9wqoguFGTyq+NJMV+gr5ipuMrYelwIGwu6spq2FB+thOo0tKZA9TsWP3SBsO+yZB1dBFDFWL8JlhKLV1c3Di+fFaf7pPaXGBB0bd4tEqgPJjfD8/9tUxCtbI=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=I+ZmD1mbGMSFSsnkXzPvd661+YwqYksEqmVXtnNZhawFCMcEFnqo6zbK5XxZQoJ51uafuhKB1WVxL4vcC5oELTpQzGRlXaz/DD7bmRr6hxLksIUSGlTmm3o6Y/gEOiacE7Q/3VMH7VISh0TvGcX2cpYp9UQkWKNF/tHXLX2qCeE=;
Message-ID: <[e-mail]>
Date: Mon, 1 Mar 2010 12:23:45 -0800 (PST)
From: Behcet Sarikaya <[e-mail]>
Reply-To: Behcet Sarikaya <[e-mail]>
Subject: Re: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
To: Peter Deacon <[e-mail]>, [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Peter,=0A=0A=0A=0A----- Original Message ----=0A> From: Peter Deacon <pe=
[e-mail]>=0A> To: [e-mail]=0A> Sent: Mon, March =
1, 2010 2:12:20 PM=0A> Subject: Re: RADEXT WG last call on RADIUS attribute=
s for IPv6 Access Networks=0A> =0A> On Mon, 1 Mar 2010, Bernard Aboba wrote=
:=0A=0A> This is an announcement of =0A> RADEXT WG last call on =E2=80=9CRA=
DIUS attributes for IPv6=0A> Access Networks=E2=80=9D =0A> before sending t=
he document off to the IESG for=0A> consideration as a =0A> Proposed Standa=
rd. =C2=A0A copy of the document is available=0A> for inspection =0A> here:=
=0A=0A> =0A> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access=0A=0A=
3.1.=0A=0AI'm =0A> confused on IPv6-Framed-Address and Framed-IPv6-Prefix f=
rom RFC 3162. It looks =0A> as if both attributes accomplish the same goal.=
=C2=A0 Is there a difference =0A> between IPv6-Framed-Address and Framed-IP=
v6-Prefix of =0A> /128?=0A=0AI don't think Framed-IPv6-Prefix was intended =
to be an attribute for an address. Yes Framed-IPv6-Prefix=C2=A0could become=
 like an address but /128 is the only case, data point.=0A=0ARegards,=0A=0A=
Behcet=0A=0A=0A      

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


Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2010 20:12:59 +0000
Date: Mon, 1 Mar 2010 12:12:20 -0800 (Pacific Standard Time)
From: Peter Deacon <[e-mail]>
To: [e-mail]
Subject: Re: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Message-ID: <alpine.WNT.2.00.1003011200180.2316@SMURF>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="322033740-21444-1267474340=:2316"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--322033740-21444-1267474340=:2316
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 1 Mar 2010, Bernard Aboba wrote:

> This is an announcement of RADEXT WG last call on “RADIUS attributes for IPv6
> Access Networks” before sending the document off to the IESG for
> consideration as a Proposed Standard.  A copy of the document is available
> for inspection here:

> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

3.1.

I'm confused on IPv6-Framed-Address and Framed-IPv6-Prefix from RFC 3162. 
It looks as if both attributes accomplish the same goal.  Is there a 
difference between IPv6-Framed-Address and Framed-IPv6-Prefix of /128?

regards,
Peter
--322033740-21444-1267474340=:2316--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2010 19:43:27 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG last call on RADIUS attributes for IPv6 Access Networks
Date: Mon, 1 Mar 2010 11:43:05 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0141_01CAB934.5B6F28D0"
Thread-Index: Acq5d2k0OLvRL0J3QCy/3nifmQFDmQ==
Content-Language: en-us

------=_NextPart_000_0141_01CAB934.5B6F28D0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

This is an announcement of RADEXT WG last call on "RADIUS attributes for
IPv6 Access Networks" before sending the document off to the IESG for
consideration as a Proposed Standard.  A copy of the document is available
for inspection here:

http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

 

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


------=_NextPart_000_0141_01CAB934.5B6F28D0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

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

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

<div class=3DSection1>

<p class=3DMsoNormal>This is an announcement of RADEXT WG last call on =
&#8220;RADIUS
attributes for IPv6 Access Networks&#8221; before sending the document =
off to
the IESG for consideration as a Proposed Standard. &nbsp;A copy of the =
document
is available for inspection here:<o:p></o:p></p>

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

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

<p class=3DMsoNormal>The RADEXT WG last call will last until March 21,
2010.&nbsp;&nbsp;&nbsp; Please send comments to the RADEXT WG mailing =
list
using the format described in the RADEXT Issues list (<a
href=3D"http://www.drizzle.com/~aboba/RADEXT">http://www.drizzle.com/~abo=
ba/RADEXT</a>
)<o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0141_01CAB934.5B6F28D0--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2010 19:01:14 +0000
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-radext-ipv6-access-00.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <[e-mail]>
Date: Mon,  1 Mar 2010 11:00: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 attributes for IPv6 Access Networks
	Author(s)	: B. Lourdelet, W. Dec, B. Sarikaya, G. Zorn, D. Miles
	Filename	: draft-ietf-radext-ipv6-access-00.txt
	Pages		: 12
	Date		: 2010-3-1
	
   IPv6 nodes can have configuration information provided to them using
   DHCPv6 and/or Router Advertisements.  This document specifies RADIUS
   attributes that complement RFC3162 for use with DHCPv6 and/or Router
   Advertisements (SLAAC) for use in broadband network access.

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

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

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

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

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

--NextPart--


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


Envelope-to: [e-mail]
Delivery-date: Mon, 01 Mar 2010 14:29:15 +0000
Message-ID: <[e-mail]>
Date: Mon, 01 Mar 2010 15:27:58 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <[e-mail]>
CC: [e-mail]
Subject: Re: Issue RADSEC certificate handling
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4520108A54041EBBC2CAC18F"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4520108A54041EBBC2CAC18F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

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

Looking at the current text, the following is said in normative (2.2):

"       *  The client MUST NOT negotiate cipher suites which only provide=

          integrity protection.

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

       *  Negotiation of compression for the TLS session is OPTIONAL.

       *  RADIUS over TLS implementations MUST support the mandatory to
          implement cipher suites specified in TLS (i.e.
          TLS_RSA_WITH_3DES_EDE_CBC_SHA).  For purposes of compatibility
          with some current deployments implementations SHOULD support
          TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_AES_128_CBC_SHA as
          well (see Section 3.2 (1) )."

The following is said in informative (3.2):

"3.2.  Ciphersuites and Compression Negotiation Considerations

   Not all TLS ciphersuites in [RFC5246] are supported by available TLS
   tool kits, and licenses may be required in some cases.  The existing
   implementations of RADIUS over TLS use OpenSSL as cryptographic
   backend, which supports all of the ciphersuites listed in the rules
   in the normative section.

   The TLS ciphersuite TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory-to-
   implement according to [RFC5246] and thus has to be supported by
   RADIUS over TLS nodes.

   The two other ciphersuites in the normative section are widely
   implemented in TLS toolkits and are considered good practice to
   implement."

This text doesn't contain any additional requirements to be mentioned in
normative text IMO (note that the one named ciphersuite here is also
already mentioned in the normative part).

The security considerations section has some additional text:

"   Some TLS ciphersuites only provide integrity validation of their
   payload, and provide no encryption.  This specification forbids the
   use of such ciphersuites.  Since the RADIUS payload's shared secret
   is fixed and well-known, failure to comply with this requirement will
   expose the entire datagram payload in plain text, including User-
   Password, to intermediate IP nodes."

and the constraint mentioned in that section is reflected in the MUST in
the first bullet of the normative section already.

I am unsure what specifically should be changed here, and suggest to
leave the text as-is.

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

To formulate it positively: it *only* makes sense when DNS SRV
resolution was used to arrive at this TLS peer. In all other cases, the
a subjectAltName:SRV can be ignored. The current text doesn't contain
this latter sentence. I suggest to add that sentence.

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

I have extended the sentence in that section:

Certificate validation MUST include the verification rules as per <xref
target=3D"RFC5280" />, using information from trusted sources only (e.g.
locally configured names).

I hope that addresses the issue.

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

I don't think there is any RADIUS-global answer to this question. A
roaming consortium decides which X.509 certificate holders to trust. It
will determine the eligibility via *some* handle in the certificate. A
plausible candidate for subjectAltName:URI is a URL pointing to some
kind of consortium policy.

It is also thinkable that a consortium defines a specific certificate
policy statement for its CA(s), and uses the Policy OID field to point
to these policies. A peer would then check for the presence of this
policy OID.

It just seems prudent for an implementation to expose as many fields
from the incoming certificate as possible to the application layer, so
that an Administrator has a handle to check the incoming connection for
eligibility according to whatever policy is defined for the consortium.
The same text as earlier in the document should be applicable here:

 In X.509 certificate operation, at least the following parameters of
the TLS connection should be exposed:

   o  Originating IP address

   o  Certificate Fingerprint

   o  Issuer

   o  Subject

   o  all X509v3 Extended Key Usage

   o  all X509v3 Subject Alternative Name

   o  all X509v3 Certificate Policies

   In TLS-PSK operation, at least the following parameters of the TLS
   connection should be exposed:

   o  Originating IP address

   o  TLS Identifier

(this is from my proposed text for NAS Identity Issue)

Would the proposed changes address your concerns?

Greetings,

Stefan Winter

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


--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]



--------------enig4520108A54041EBBC2CAC18F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuLzvQACgkQ+jm90f8eFWbsVQCdG77I94KK3E+BCQ5sUWHMaBHj
71sAnR5u31mzONQc6K03s+1iDGaT6BN5
=YoZ2
-----END PGP SIGNATURE-----

--------------enig4520108A54041EBBC2CAC18F--

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