Subject: RE: Revisions to RFC 4005
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Date: Fri, 31 Aug 2007 15:42:46 -0400

Glen Zorn writes...

> Right, so what I'm suggesting is that whatever Diameter-related 
> issues there might be w/the extended attributes should be addressed
> in the extended attributes document...

Yes.

> ...while another small document ... should address the general
> problem w/VSA translation...

That sounds reasonable.  That work might be undertaken in the DIME WG as an
update to RFC 4005, for example.  Or not.  :-)

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

Delivery-date: Fri, 31 Aug 2007 18:28:56 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Revisions to RFC 4005
Date: Fri, 31 Aug 2007 11:13:14 -0700

> Just for the sake of findability (don't think that that's actually
> a word, but hopefully you know what I mean), I would think that 
> that kind of update would be better addressed in a document that
> had "Diameter" in the title.

Well, this is a cross-protocol issue, but I agree that the preferable
vehicle would be an rfc4005bis (update or revision) document.  I've
previously sent an e-mail to the DIME WG chairs (and copied this list) to
see if there is any document in that WG which could take on this issue.
I've not seen any reply.

OTOH, when RADEXT is extending RADIUS we have a pro-active obligation to
address Diameter interoperability in our documents
[gwz] 
[gwz] 
Right, so what I'm suggesting is that whatever Diameter-related issues there
might be w/the extended attributes should be addressed in the extended
attributes document, while another small document (_not_ an entire rewrite
of RFC 4005 unless there are other problems) should address the general
problem w/VSA translation (though as you know I believe that the best
approach is no translation at all, esp. given the impossibility of
translating Diameter AVPs to RADIUS attributes in the general case).

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

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

Delivery-date: Fri, 31 Aug 2007 17:21:53 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Revisions to RFC 4005
Date: Fri, 31 Aug 2007 13:15:03 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> Just for the sake of findability (don't think that that's actually
> a word, but hopefully you know what I mean), I would think that 
> that kind of update would be better addressed in a document that
> had "Diameter" in the title.

Well, this is a cross-protocol issue, but I agree that the preferable
vehicle would be an rfc4005bis (update or revision) document.  I've
previously sent an e-mail to the DIME WG chairs (and copied this list) to
see if there is any document in that WG which could take on this issue.
I've not seen any reply.

OTOH, when RADEXT is extending RADIUS we have a pro-active obligation to
address Diameter interoperability in our documents.

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

Delivery-date: Fri, 31 Aug 2007 17:01:35 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Revisions to RFC 4005
Date: Fri, 31 Aug 2007 10:00:58 -0700

Alan DeKok writes...

>   However it is done, it looks like we have to update 4005 to 
> obtain Diameter compatibility for the extended attributes.

That part of the problem will need to be addressed by the extended
attributes draft, because our charter requires a Diameter compatibility
section in any of our work products, to address interoperability with
Diameter.  It's not so clear that we need to address the issue of "legacy"
(RADIUS Classic) VSAs in Diameter at the same time, or at least in the same
document.  Of course, if one mechanism serves both purposes, so much the
better.
[gwz] 
[gwz] 
Just for the sake of findability (don't think that that's actually a word,
but hopefully you know what I mean), I wiuld think that that kind of update
would be better addressed in a document that had "Diameter" in the title.

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

Delivery-date: Fri, 31 Aug 2007 16:58:24 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Fri, 31 Aug 2007 09:57:21 -0700

Glen Zorn wrote:
> Maybe.  What do you have in mind?  I don't think so, because standard
> Diameter AVPs don't have the 'V' bit set & AFAIK, no existing VSAs of any
> variety have a Vendor code of 0.

  That would be backwards compatible, and wouldn't require changes to
existing implementations.

>  We may have a problem translating the new
> RADIUS "grouped attributes" to Diameter, though, because don't Diameter
> grouped AVPs have a fixed syntax?

  Yes.  We could say that the extended attributes are encapsulated in a
Diameter attribute 26 as-is... except that attribute 26 isn't allowed in
Diameter packets.

  However it is done, it looks like we have to update 4005 to obtain
Diameter compatibility for the extended attributes.
[gwz] 
[gwz] I really think that that is going a bit overboard.  Is there some
reason that these things could not be handled (at worst) in a document
updating 4005 instead of obsoleting it?

  Alan DeKok.

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

Delivery-date: Fri, 31 Aug 2007 12:35:06 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Revisions to RFC 4005
Date: Fri, 31 Aug 2007 08:35:01 -0400

Alan DeKok writes...

>   However it is done, it looks like we have to update 4005 to 
> obtain Diameter compatibility for the extended attributes.

That part of the problem will need to be addressed by the extended
attributes draft, because our charter requires a Diameter compatibility
section in any of our work products, to address interoperability with
Diameter.  It's not so clear that we need to address the issue of "legacy"
(RADIUS Classic) VSAs in Diameter at the same time, or at least in the same
document.  Of course, if one mechanism serves both purposes, so much the
better.

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

Delivery-date: Fri, 31 Aug 2007 12:19:57 +0000
Date: Fri, 31 Aug 2007 14:19:08 +0200
From: Alan DeKok <[email-masked]>
To: Lars Eggert <[email-masked]>
CC: IESG IESG <[email-masked]>,  'radext mailing list' <[email-masked]>
Subject: Re: DISCUSS: draft-ietf-radext-fixes

Lars Eggert wrote:
>>   If a duplicate response is received by the client, it is no different
>> than an *unsolicited* response.  Neither one matches a pending request,
>> so the responses are discarded.
> 
> Ah - that makes total sense now. I'll leave it up to you to decide if
> you'd like to stick this explanation into the draft.

  We can add a sentence or two to clarify that:

 ...later responses MUST be silently discarded, as they do not match a
pending request.  That is, later responses are treated exactly the
same as unsolicited responses, and are silently discarded.

> Thanks for pointing me at that - it had slipped my mind that you had
> explained this already. As above, I think sticking a bit of the
> explanation from your email into the document would be good, but this is
> up to you.

  "After about 30 seconds, most RADIUS clients and end users will have
given up on the authentication request.  Therefore, there is little
value in having a larger cache timeout."

  I'll make the changes.  Unless anyone else has comments, I'll submit a
revised version next week.

  Alan DeKok.

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

Delivery-date: Fri, 31 Aug 2007 09:22:08 +0000
Date: Fri, 31 Aug 2007 11:21:25 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>,  [email-masked],  [email-masked]
Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)

Glen Zorn wrote:
> Maybe.  What do you have in mind?  I don't think so, because standard
> Diameter AVPs don't have the 'V' bit set & AFAIK, no existing VSAs of any
> variety have a Vendor code of 0.

  That would be backwards compatible, and wouldn't require changes to
existing implementations.

>  We may have a problem translating the new
> RADIUS "grouped attributes" to Diameter, though, because don't Diameter
> grouped AVPs have a fixed syntax?

  Yes.  We could say that the extended attributes are encapsulated in a
Diameter attribute 26 as-is... except that attribute 26 isn't allowed in
Diameter packets.

  However it is done, it looks like we have to update 4005 to obtain
Diameter compatibility for the extended attributes.

  Alan DeKok.

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

Delivery-date: Fri, 31 Aug 2007 08:12:27 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Fri, 31 Aug 2007 01:08:46 -0700

>9.6.2.  Forwarding a RADIUS VSA as a Diameter Vendor Specific AVP
>
>    The Diameter AVP will consist of the following fields:
>
>       Diameter Flags: V=1, M=0, P=0
>       Diameter Vendor code = RADIUS VSA Vendor code
>       Diameter AVP code = RADIUS VSA Vendor type code
>       Diameter AVP length = length of AVP (header + data)
>       Diameter Data = RADIUS VSA vendor data

Won't using a RADIUS VSA Vendor code of 0 result in a conflict between the 
RADIUS
"extended" attributes and already allocated Diameter AVPs?
[gwz] 
Maybe.  What do you have in mind?  I don't think so, because standard
Diameter AVPs don't have the 'V' bit set & AFAIK, no existing VSAs of any
variety have a Vendor code of 0.  We may have a problem translating the new
RADIUS "grouped attributes" to Diameter, though, because don't Diameter
grouped AVPs have a fixed syntax?  The RADIUS groupings could be created in
an ad hoc fashion, though...in addition, 4005 says that "Nested Multiple
vendor data fields MUST be expanded into multiple Diameter AVPs.".  I'm not
really sure that that really works even with current v-s subattributes,
since it seems to assume that there is no important relation between the
subattributes that could be lost by breaking them apart.

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

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

Delivery-date: Fri, 31 Aug 2007 08:12:20 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Fri, 31 Aug 2007 00:56:15 -0700

David B. Nelson wrote:
> The RADIUS Design Guidelines document is targeted to be a BCP, and to
> describe current usages and recommend attribute design practices based on
> RADIUS as it is defined today.  That's the WG's consensus.  As such, it's
> probably the wrong vehicle to use for introducing new usages, such as
> suggesting Diameter AVPs with type 26.

  Current uses already involve getting RADIUS VSA's in non-RFC formats
into Diameter packets.  Whether we like to admit it or not, the practice
already seems to be following David Mitton's draft:
[gwz] 
Why do you think that?

http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt

  So it is a BCP.  Sort of.
[gwz] 
Except that the (grossly misnamed) Best Current Practice documents turn out
to be neither current nor practices (and rather rarely best ;-).  In fact,
they are statements of what the IETF (or IESG, IAB, whatever) _wishes_ the
current practices would be, whether those wishes have any relation to
reality or not.

> If RFC 2005 needs to be updated, I think that ought to be done in a
separate
> document, either in RADEXT or in DIME.

  That's more work.  Do we have an editor for that document, or someone
willing to shepherd it?  Is the WG against the idea of having suggested
practices updating holes in previous specs?

  Alan DeKok.

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

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

Delivery-date: Fri, 31 Aug 2007 05:43:11 +0000
Date: Fri, 31 Aug 2007 07:12:19 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>,  [email-masked],  [email-masked]
Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)

Glen Zorn wrote:
> It seems as if all we'd really have to do in the extended attributes draft
> is to specify that the'M' bit has to be set in the Diameter AVP.

  Also:

 - map extended attributes somewhere into the Diameter space
 - i.e. allocate 256 Diameter attributes for RADIUS translation
 - note that Diameter attributes of LONGER than 253 characters are
allowed for those attributes
 - D<->R gateways MUST use a new method to map both attributes and
lengths for extended attributes.

  All of that means updating the suggested mapping in RFC 4005, for both
normal (now extended) RADIUS attributes, and for normal (now extended)
VSA's.

  Alan DeKok.

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

Delivery-date: Fri, 31 Aug 2007 05:13:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Thu, 30 Aug 2007 22:12:24 -0700

>9.6.2.  Forwarding a RADIUS VSA as a Diameter Vendor Specific AVP
>
>    The Diameter AVP will consist of the following fields:
>
>       Diameter Flags: V=1, M=0, P=0
>       Diameter Vendor code = RADIUS VSA Vendor code
>       Diameter AVP code = RADIUS VSA Vendor type code
>       Diameter AVP length = length of AVP (header + data)
>       Diameter Data = RADIUS VSA vendor data

Won't using a RADIUS VSA Vendor code of 0 result in a conflict between the 
RADIUS
"extended" attributes and already allocated Diameter AVPs?

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

Delivery-date: Fri, 31 Aug 2007 04:55:06 +0000
Date: Fri, 31 Aug 2007 06:53:45 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)

Bernard Aboba wrote:
> Because the extended attribute draft uses Attribute 26, but with a
> vendor code of 0, which currently isn't supported by RFC 4005?

  Also, the suggested format for RADIUS VSA's mirrors normal RADIUS
attributes.  With an extended attribute format, SDO's will say "Me,
too", and use the same format for their attributes.  Those attributes
then have to be translated to Diameter.

  Alan DeKok.

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

Delivery-date: Thu, 30 Aug 2007 23:47:49 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Thu, 30 Aug 2007 16:46:34 -0700

>Since the "extended attributes" document will need to deal with VSA formats
>(and Diameter translation of same),
>
>[gwz] I'm not sure why?

Because the extended attribute draft uses Attribute 26, but with a vendor 
code of 0, which currently isn't supported by RFC 4005?
[gwz] 
Wel, it's true that 4005 doesn't explicitly support a vendor code of zero,
but I don't think that it explicitly _doesn't_ support it, either.  Here's
the section on translating RADIUS VSAs to Diameter:

9.6.2.  Forwarding a RADIUS VSA as a Diameter Vendor Specific AVP

   The Diameter AVP will consist of the following fields:

      Diameter Flags: V=1, M=0, P=0
      Diameter Vendor code = RADIUS VSA Vendor code
      Diameter AVP code = RADIUS VSA Vendor type code
      Diameter AVP length = length of AVP (header + data)
      Diameter Data = RADIUS VSA vendor data

   Note that the VSAs are considered optional by RADIUS rules, and this
   specification does not set the Mandatory flag.  If an implementor
   desires a VSA be made mandatory because it represents a required
   service policy, the RADIUS gateway should have a process to set the
   bit on the Diameter side.

   If the RADIUS receiving code knows of vendor specific field
   interpretations for the specific vendor, it may employ them to parse
   an extended AVP code or data length.  Otherwise the recommended
   standard fields will be used.

   Nested Multiple vendor data fields MUST be expanded into multiple
   Diameter AVPs.
[gwz] 
It seems as if all we'd really have to do in the extended attributes draft
is to specify that the'M' bit has to be set in the Diameter AVP.

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

Delivery-date: Thu, 30 Aug 2007 21:01:54 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Thu, 30 Aug 2007 14:01:01 -0700

>Since the "extended attributes" document will need to deal with VSA formats
>(and Diameter translation of same),
>
>[gwz] I'm not sure why?

Because the extended attribute draft uses Attribute 26, but with a vendor 
code of 0, which currently isn't supported by RFC 4005?

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

Delivery-date: Thu, 30 Aug 2007 17:39:32 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Revisions to RFC 4005
Date: Thu, 30 Aug 2007 13:32:40 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> > Since the "extended attributes" document will need to deal with
> > VSA formats (and Diameter translation of same),...
>
> I'm not sure why?

I agree that the issue of transparency of VSAs in RADIUS and Diameter is not
strictly related to Extended RADIUS Attributes.  Ideally, this would be
addressed in an rfc4005bis draft.  One does not exist, however.  So, the
question is what's the next best fit?

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

Delivery-date: Thu, 30 Aug 2007 16:58:54 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Thu, 30 Aug 2007 09:57:49 -0700

>   Current uses already involve getting RADIUS VSA's in non-RFC formats
>into Diameter packets.  Whether we like to admit it or not, the practice
>already seems to be following David Mitton's draft:
>
>http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt

Since the "extended attributes" document will need to deal with VSA formats 
(and Diameter translation of same), 
[gwz] 
[gwz] 
I'm not sure why?

>perhaps this can be tackled there?

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

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

Delivery-date: Thu, 30 Aug 2007 07:46:23 +0000
Date: Thu, 30 Aug 2007 08:40:33 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)

Bernard Aboba wrote:
> Since the "extended attributes" document will need to deal with VSA
> formats (and Diameter translation of same), perhaps this can be tackled
> there?

  That would be good.

  It *should* be addressed somewhere, and soon.

  Alan DeKok.

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

Delivery-date: Thu, 30 Aug 2007 07:30:17 +0000
Date: Thu, 30 Aug 2007 08:59:02 +0200
From: Alan DeKok <[email-masked]>
To: Lars Eggert <[email-masked]>
CC: IESG IESG <[email-masked]>,  'radext mailing list' <[email-masked]>
Subject: Re: DISCUSS: draft-ietf-radext-fixes

Lars Eggert wrote:
> [ timers ]
> -06 specifies such a mechanism, which was the important part of my
> concern. A minor remaining nit is that the "within the limits of
> [RFC2865] Section 2.4" part should be removed, because that section in
> RFC2865 does not actually discuss any such limits.

  OK.

>>> 2.2.2.  Duplicate detection and orderly delivery.
...
> If clients need not perform duplicate detection, how are they supposed
> to silently discard later responses? No duplicate detection = no state
> about packets received in the past, right?

  Yes.  RADIUS is a request / response protocol.  The client sends a
request, and looks for a matching response.  Once it has a matching
response, it effectively forgets about the request.

  If a duplicate response is received by the client, it is no different
than an *unsolicited* response.  Neither one matches a pending request,
so the responses are discarded.

>> Section 2.2.2., paragraph 8:
>>>    Each cache entry SHOULD be purged after a period of time.  This time
>>>    SHOULD be no less than 5 seconds, and no more than 30 seconds.
>>
>>   DISCUSS: The Internet MSL is 2 minutes - choosing this as a lower
>>   bound will prevent late duplicates from remaining undetected.
> 
> This has remained unchanged in -06 AFAICT.

  As does my response: :)

http://ops.ietf.org/lists/radiusext/2007/msg00449.html

  In short, MSL doesn't matter to a server, as it doesn't see round trip
times.  It sees a request, and responds to that request.

  Alan DeKok.

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

Delivery-date: Thu, 30 Aug 2007 03:08:13 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: FW: DISCUSS: draft-ietf-radext-fixes 
Date: Wed, 29 Aug 2007 23:07:48 -0400

Forwarding to the list...

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]]
> Sent: Wednesday, August 29, 2007 10:06 PM
> To: [email-masked]
> Cc: IESG IESG; [email-masked]
> Subject: Re: DISCUSS: draft-ietf-radext-fixes
> 
> Hi,
> 
> I checked the -06 update against my original DISCUSS, and except for
> the few remaining issues detailed below, all my concerns have been
> addressed - thank you!
> 
> On 2007-7-2, at 20:48, ext Lars Eggert wrote:
> > Section 2.2.1., paragraph 7:
> >> [b]  Congestive backoff.  While it is not necessary for RADIUS client
> >>      implementations to implement complex retransmission algorithms,
> >>      implementations SHOULD support congestive backoff within the
> >> limits
> >>      suggested by [RFC2865] Section 2.4.
> ...
> >   DISCUSS: RFC2865 Section 2.4 does not suggests any timer management
> >   scheme or timer limits, and I couldn't find this anywhere else in
> >   RFC2865, either. Consequently, this document needs to specify the
> >   desired mechanism. See RFC2988 for an example of such a mechanism.
> 
> -06 specifies such a mechanism, which was the important part of my
> concern. A minor remaining nit is that the "within the limits of
> [RFC2865] Section 2.4" part should be removed, because that section
> in RFC2865 does not actually discuss any such limits.
> 
> > Section 2.2.2., paragraph 0:
> >> 2.2.2.  Duplicate detection and orderly delivery.
> >
> >   DISCUSS: This section is all about duplicate detection at the server
> >   due to client retransmissions. But any UDP packet can be
> > duplicated in
> >   the network. This section should hence also discuss detection of
> >   duplicate responses at the client.
> 
> This section has significantly changed in -06. My one remaining
> concern is with the new text that says:
> 
>     RADIUS clients do not have to perform duplicate detection.  When a
>     client sends a request, it processes the first response that has a
>     valid Response Authenticator as defined in [RFC2865] Section 3.  Any
>     later responses MUST be silently discarded.
> 
> If clients need not perform duplicate detection, how are they
> supposed to silently discard later responses? No duplicate detection
> = no state about packets received in the past, right?
> 
> > Section 2.2.2., paragraph 8:
> >>    Each cache entry SHOULD be purged after a period of time.  This
> >> time
> >>    SHOULD be no less than 5 seconds, and no more than 30 seconds.
> >
> >   DISCUSS: The Internet MSL is 2 minutes - choosing this as a lower
> >   bound will prevent late duplicates from remaining undetected.
> 
> This has remained unchanged in -06 AFAICT.
> 
> Lars

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

Delivery-date: Wed, 29 Aug 2007 22:26:33 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-fixes-06.txt 
Date: Wed, 29 Aug 2007 16:15:02 -0400

--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		: Common Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: D. Nelson, A. DeKok
	Filename	: draft-ietf-radext-fixes-06.txt
	Pages		: 28
	Date		: 2007-8-29
	
This document describes common issues seen in RADIUS implementations
   and suggests some fixes.  Where applicable, ambiguities and errors in
   previous RADIUS specifications are clarified.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-fixes-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-fixes-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-fixes-06.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Wed, 29 Aug 2007 17:11:19 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Wed, 29 Aug 2007 09:55:41 -0700

Glen Zorn wrote:
> [gwz] It is -- the problem with "subattributes" as described in RFC 2865
is
> that they must fit in a single VSA.  With this draft, we open up the
> possibility (with the "continuation" bit) of having really huge attributes
> containing subattributes that themselves are larger than a single VSA.  It
> seems like we either need to restrict the usage of subattributes or decide
> on one or the other.

  The *extended* attributes can be larger than 256 octets, due to the
continuation flag.  Inside of the extended attributes, any
sub-attributes do not have a continuation flag, and their "length" field
is still 8 bits.  So they can be a few octets longer than an RFC 2865 VSA.
[gwz] 
[gwz] Good point.  So the two constructs are almost (but not quite the
same)...

(David)
> I see an advantage in directly supporting sub-attributes, in terms of a
> cleaner data model, however, I also see that diverging from the Diameter
> model of grouped AVPs may lead to greater difficulty in translation and
> coexistence.

  I'll submit the edited "guidelines" document today.  It suggests that
RFC 4005 be updated, and allow Diameter attributes of type 26, which
will transport the contents of RADIUS attributes of type 26.

  Since most Diameter servers also talk RADIUS, any translation
difficulties (mostly) go away.  
[gwz] 
[gwz] If you're going to do that, you might just as well just stick the
whole RADIUS message in an AVP (as I've suggested before) & be done w/it: no
translation, period.

The server implements attribute 26
parsing once, and then it's done.

  Alan DeKok.

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

Delivery-date: Wed, 29 Aug 2007 16:43:08 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Wed, 29 Aug 2007 09:42:17 -0700

>   Current uses already involve getting RADIUS VSA's in non-RFC formats
>into Diameter packets.  Whether we like to admit it or not, the practice
>already seems to be following David Mitton's draft:
>
>http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt

Since the "extended attributes" document will need to deal with VSA formats 
(and Diameter translation of same), perhaps this can be tackled there?

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

Delivery-date: Wed, 29 Aug 2007 13:37:40 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>, "'Dave Frascone'" <[email-masked]>
Cc: <[email-masked]>
Subject: Update to RFC 4005?
Date: Wed, 29 Aug 2007 09:22:33 -0400

Hi Hannes and Dave,

If you're following the RADEXT WG mailing list, you may have noticed that we
are trying to figure out what to do about VSAs, in terms of our RADIUS
Attributes Design Guidelines document.

It has been suggested that Diameter allow the direct importation of RADIUS
attribute 26 (VSA) in order to rationalize the treatment of VSAs between
RADIUS and Diameter.  There is an expired draft that describes this issue,
and recommended ways to address it.

http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt

Alan DeKok suggested including this type of recommendation in the RADIUS
Attributes Design Guidelines draft, targeted to become a BCP.  I'm not so
sure that a BCP can "Update" a Proposed Standard (e.g. RFC 4005).

Does the DIME WG have any documents in process that might pick up and
address this issue?

Regards,

Dave Nelson

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

Delivery-date: Wed, 29 Aug 2007 12:58:56 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Revisions to RFC 4005
Date: Wed, 29 Aug 2007 08:58:40 -0400

Alan DeKok writes...

>   That's more work.  Do we have an editor for that document, or
> someone willing to shepherd it?

I don't know.  We should probably talk to the DIME WG chairs to see if this
could be wrapped into a revision document they are already working on.

> Is the WG against the idea of having suggested practices updating 
> holes in previous specs?

It might also meet resistance at the IESG, as a proposed BCP document
attempting to Update a Proposed Standard document, regardless of what the
RADEXT WG feels.  Generally speaking this is not permissible.  That's why we
needed to make the Issues and Fixes draft a Standards Track document.

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

Delivery-date: Wed, 29 Aug 2007 12:13:34 +0000
Date: Wed, 29 Aug 2007 14:12:33 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)

David B. Nelson wrote:
> The RADIUS Design Guidelines document is targeted to be a BCP, and to
> describe current usages and recommend attribute design practices based on
> RADIUS as it is defined today.  That's the WG's consensus.  As such, it's
> probably the wrong vehicle to use for introducing new usages, such as
> suggesting Diameter AVPs with type 26.

  Current uses already involve getting RADIUS VSA's in non-RFC formats
into Diameter packets.  Whether we like to admit it or not, the practice
already seems to be following David Mitton's draft:

http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt

  So it is a BCP.  Sort of.

> If RFC 2005 needs to be updated, I think that ought to be done in a separate
> document, either in RADEXT or in DIME.

  That's more work.  Do we have an editor for that document, or someone
willing to shepherd it?  Is the WG against the idea of having suggested
practices updating holes in previous specs?

  Alan DeKok.

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

Delivery-date: Wed, 29 Aug 2007 11:14:19 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: Revisions to RFC 4005 (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Wed, 29 Aug 2007 07:13:49 -0400

Alan DeKok writes...

>   I'll submit the edited "guidelines" document today.  It suggests that
> RFC 4005 be updated, and allow Diameter attributes of type 26, which
> will transport the contents of RADIUS attributes of type 26.

The RADIUS Design Guidelines document is targeted to be a BCP, and to
describe current usages and recommend attribute design practices based on
RADIUS as it is defined today.  That's the WG's consensus.  As such, it's
probably the wrong vehicle to use for introducing new usages, such as
suggesting Diameter AVPs with type 26.

If RFC 2005 needs to be updated, I think that ought to be done in a separate
document, either in RADEXT or in DIME.

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

Delivery-date: Wed, 29 Aug 2007 06:07:34 +0000
Date: Wed, 29 Aug 2007 08:06:04 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: "'David B. Nelson'" <[email-masked]>,  [email-masked]
Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-02.txt

Glen Zorn wrote:
> [gwz] It is -- the problem with "subattributes" as described in RFC 2865 is
> that they must fit in a single VSA.  With this draft, we open up the
> possibility (with the "continuation" bit) of having really huge attributes
> containing subattributes that themselves are larger than a single VSA.  It
> seems like we either need to restrict the usage of subattributes or decide
> on one or the other.

  The *extended* attributes can be larger than 256 octets, due to the
continuation flag.  Inside of the extended attributes, any
sub-attributes do not have a continuation flag, and their "length" field
is still 8 bits.  So they can be a few octets longer than an RFC 2865 VSA.

(David)
> I see an advantage in directly supporting sub-attributes, in terms of a
> cleaner data model, however, I also see that diverging from the Diameter
> model of grouped AVPs may lead to greater difficulty in translation and
> coexistence.

  I'll submit the edited "guidelines" document today.  It suggests that
RFC 4005 be updated, and allow Diameter attributes of type 26, which
will transport the contents of RADIUS attributes of type 26.

  Since most Diameter servers also talk RADIUS, any translation
difficulties (mostly) go away.  The server implements attribute 26
parsing once, and then it's done.

  Alan DeKok.

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

Delivery-date: Tue, 28 Aug 2007 22:36:42 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Extended attributes support for structured data (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Tue, 28 Aug 2007 13:24:34 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David B. Nelson
Sent: Tuesday, August 28, 2007 12:24 PM
To: [email-masked]
Subject: Extended attributes support for structured data (was RE:
Consideration of draft-lior-radius-attribute-type-extension-02.txt)

Glen Zorn writes...

> Actually, it does (as illustrated in the examples), it's just not
> very explicit about it.

Right.  I certainly missed it.

> ...the problem with "subattributes" as described in RFC 2865 is
> that they must fit in a single VSA.  With this draft, we open up 
> the possibility (with the "continuation" bit) of having really huge
> attributes containing subattributes that themselves are larger than
> a single VSA.  It seems like we either need to restrict the usage
> of subattributes or decide on one or the other.

One or the other what?  Could you please elaborate?
[gwz] 
Sorry, either really big attributes w/really big subattributes or grouped
attributes.  They seem to both serve the same purpose.

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

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

Delivery-date: Tue, 28 Aug 2007 19:23:40 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: Extended attributes support for structured data (was RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt)
Date: Tue, 28 Aug 2007 15:23:36 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> Actually, it does (as illustrated in the examples), it's just not
> very explicit about it.

Right.  I certainly missed it.

> ...the problem with "subattributes" as described in RFC 2865 is
> that they must fit in a single VSA.  With this draft, we open up 
> the possibility (with the "continuation" bit) of having really huge
> attributes containing subattributes that themselves are larger than
> a single VSA.  It seems like we either need to restrict the usage
> of subattributes or decide on one or the other.

One or the other what?  Could you please elaborate?

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

Delivery-date: Tue, 28 Aug 2007 18:54:21 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Tue, 28 Aug 2007 11:53:14 -0700

...

As currently being discussed in this thread, the draft does not permit the
encoding of sub-attributes within an Extended RADIUS attribute format.  
[gwz] 
Actually, it does (as illustrated in the examples), it's just not very
explicit about it.

RFC
2865 permits this practice for VSAs with a non-zero Vendor-ID, i.e. non-IETF
"vendors".  RFC 2865, Section 5.26 reads, in part:

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

Should we include similar language in this draft, perhaps with a prohibition
on nested sub-attribute for the sake of simplicity, in this document?  I
thought that the presentation on this draft at IETF-69 indicated that this
capability would be available.
[gwz] 
[gwz] It is -- the problem with "subattributes" as described in RFC 2865 is
that they must fit in a single VSA.  With this draft, we open up the
possibility (with the "continuation" bit) of having really huge attributes
containing subattributes that themselves are larger than a single VSA.  It
seems like we either need to restrict the usage of subattributes or decide
on one or the other.

As long the recommended structure of sub-attributes is standardized and
limited, so as to limit the variations of format that servers would be
expected to cope with, I think this would be a good feature, in support of
structured, multi-part attributes.

I understand that the tagging feature can also support structured data, in
an indirect fashion, but its design is optimized to support related groups
of individual attributes (grouped AVPs).  That's the way Diameter addresses
the issue of structured data.

I see an advantage in directly supporting sub-attributes, in terms of a
cleaner data model, however, I also see that diverging from the Diameter
model of grouped AVPs may lead to greater difficulty in translation and
coexistence.

Discussion?

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

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

Delivery-date: Tue, 28 Aug 2007 15:30:07 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Tue, 28 Aug 2007 11:29:50 -0400
Organization: Elbrys Networks, Inc.

Further comments on the draft:

Section 2.

   Although according to the specification the allocation of RADIUS
   attribute type codes has been controlled by IANA, this has not been
   the case in reality.  In the real world, certain vendors have grabbed
   attribute type codes that they shouldn't have.  The result is that
   many RADIUS deployments have had to work around these attribute
   collisions.  Therefore, each time a new attribute type is introduced
   it raises the possibility that something will break.  The proposed
   scheme must be impervious to this artifact.

I suggest deleting this paragraph.  It duplicates some content of RFC 3575
and adds nothing to the purpose of this document, going forward.

Section 7.

   This solution requires that the IETF be allocated Vendor-Type of zero
   to the IETF.

RFC 2865, Section 5.26 says, in part:

    Vendor-Id

      The high-order octet is 0 and the low-order 3 octets are the SMI
      Network Management Private Enterprise Code of the Vendor in
      network byte order, as defined in the "Assigned Numbers" RFC [6].

Taken together, these sections of text might be interpreted to mean that the
IETF is assigning a Private Enterprise Code of 0 to itself.  The PEN
Registry at the following URL:
http://www.iana.org/assignments/enterprise-numbers indicates:

0
  Reserved
    Internet Assigned Numbers Authority
      iana&iana.org

that 0 is reserved for IANA.  Is that the same as reserved for IETF use?
Should we add clarifying text to indicate that the Vendor-Id of 0 is not
strictly a PEN?

   It also requires that IANA be set up to manage the RADIUS Extended
   Attributes.

This means that there would be a new section in the existing RADIUS Registry
dealing with IETF VSA Extended-Type field.

   The allocation rules for extended RADIUS attributes align with the
   rules for allocation of the standard RADIUS attributes.

Does this mean to reference RFC 3575?

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

Delivery-date: Tue, 28 Aug 2007 14:49:55 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Tue, 28 Aug 2007 10:49:42 -0400
Organization: Elbrys Networks, Inc.

Specific comments on the draft:

Abstract:   

   In order for the Remote Authentication Dial In User Service protocol
   to continue to support new applications, the RADIUS attribute space
   must be extended beyond the current limit of 255 possible attribute
   types.  This document defines a mechanism to extend the base RADIUS
   attribute types while maintaining backwards compatibility as well as
   compatibility with Diameter.

If this document is to address grouped attributes (AVPs) and structured
(complex or multi-part) attributes, we should so indicate in the abstract.
That description should be included in the Introduction section, as well.

Section 2.

   A need to group RADIUS attributes together has become more prevalent
   in current work.  Therefore, the proposed scheme NUST provide a
   mechanism to group attributes.

s/NUST/MUST/

Section 4.

   Up-to-date values of the RADIUS Extended-Type field
   are specified in the most recent "Assigned Numbers" IANA [RFC3575] .
   Values XXXX-YYYY are reserved.

Actually, RFC 3575 does not contain the RADIUS Registry, that is located at
the following URL: http://www.iana.org/assignments/radius-types.  RFC 3575
documents some RFC-defined and some legacy "bootlegged" assignments, and
defines a process for IANA assignment going forward from its date of
publication.  It is not the registry.  The draft text should clarify the
distinction.

As currently being discussed in this thread, the draft does not permit the
encoding of sub-attributes within an Extended RADIUS attribute format.  RFC
2865 permits this practice for VSAs with a non-zero Vendor-ID, i.e. non-IETF
"vendors".  RFC 2865, Section 5.26 reads, in part:

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

Should we include similar language in this draft, perhaps with a prohibition
on nested sub-attribute for the sake of simplicity, in this document?  I
thought that the presentation on this draft at IETF-69 indicated that this
capability would be available.

As long the recommended structure of sub-attributes is standardized and
limited, so as to limit the variations of format that servers would be
expected to cope with, I think this would be a good feature, in support of
structured, multi-part attributes.

I understand that the tagging feature can also support structured data, in
an indirect fashion, but its design is optimized to support related groups
of individual attributes (grouped AVPs).  That's the way Diameter addresses
the issue of structured data.

I see an advantage in directly supporting sub-attributes, in terms of a
cleaner data model, however, I also see that diverging from the Diameter
model of grouped AVPs may lead to greater difficulty in translation and
coexistence.

Discussion?

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

Delivery-date: Tue, 28 Aug 2007 11:50:51 +0000
Date: Tue, 28 Aug 2007 13:49:51 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Alan DeKok' <[email-masked]>,  "'David B. Nelson'" <[email-masked]>, 'radext mailing list' <[email-masked]>
Subject: Re: Extensibility of draft-ietf-radext-filter-rules

Glen Zorn wrote:
> However, the filter rules document could quickly use many attributes,
> exhausting the standard attribute space.
> [gwz] 
> [gwz] I'm a bit confused by this statement: the attribute extension draft
> basically doubles the size of the existing 
> "standard attribute space.  Are you saying that the filter rules would take
> up that whole extension?

  No, but it defines a lot of attributes that can be interpreted ONLY in
a grouped context.  It's just easier to define a filter rule attribute,
and pack it with sub-attributes that the filter rules need.  It means
that the filter rules are also easily extensible.

>   Given the utility of sub-attributes, and the fact that most vendors
> have implemented them already, or will implement them for WiMAX, I'm
> inclined to add them to the extended attributes draft.
> [gwz] What changes would you make?

  If the current draft doesn't have sub-attributes, just used 8-bit
sub-TLV's, and creating a "tlv" type would be sufficient.

  Alan DeKok.

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

Delivery-date: Tue, 28 Aug 2007 06:43:48 +0000
Date: Tue, 28 Aug 2007 08:42:41 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Consideration of consideration of requirements for consideration

Bernard Aboba wrote:
> So far, only three people have responded to this topic, and two of them
> are the chairs.  Are we sure we even have a quorum to talk about quorum
> requirements ?:)

  Whatever we're talking about, I support the consensus.

  Alan DeKok.

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

Delivery-date: Mon, 27 Aug 2007 22:01:32 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>
Cc: "'radext mailing list'" <[email-masked]>
Subject: RE: Extensibility of draft-ietf-radext-filter-rules
Date: Mon, 27 Aug 2007 18:01:35 -0400
Organization: Elbrys Networks, Inc.

Hannes Tschofenig writes...

> Right. There is, however, a timing issue involved with the work and
> I am not sure when the corresponding work in RADIUS gets done. Do 
> you have an estimate?

Well, we've moved forward today to having accepted the draft as a WG
document and the editor has indicated that a revised -00 draft will be
posted sometime this week.

It would be nice to think that we could be ready for a WGLC within a few
weeks, unless we get bogged down in comment resolution from the initial
formal review.  In an optimistic scenario, one might envision completion of
WGLC prior to IETF-70.  :-)

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

Delivery-date: Mon, 27 Aug 2007 21:35:07 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Extensibility of draft-ietf-radext-filter-rules
Date: Mon, 27 Aug 2007 14:34:50 -0700

>   I didn't see a call on the list to make the extended attributes document 
>a WG item.

Here is a link to the call:
http://ops.ietf.org/lists/radiusext/2007/msg00477.html

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

Delivery-date: Mon, 27 Aug 2007 21:19:20 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'David B. Nelson'" <[email-masked]>
Cc: "'radext mailing list'" <[email-masked]>
Subject: RE: Extensibility of draft-ietf-radext-filter-rules
Date: Mon, 27 Aug 2007 09:41:36 -0700

..[gwz] .
> BTW, I think we have completed the consensus call on that document, but I
> don't remember if I saw the official result announced.

  I didn't see a call on the list to make the extended attributes
document a WG item. 
[gwz] 
[gwz] That happened some time ago -- in fact, I think you even responded
positively ;-)
[gwz]
There wasn't any objections at IETF 69, though.

  Alan DeKok.

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

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

Delivery-date: Mon, 27 Aug 2007 21:16:23 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 13:40:15 -0700

-----Original Message-----
From: David B. Nelson [mailto:[email-masked]] 
Sent: Monday, August 27, 2007 1:28 PM
To: 'Glen Zorn'
Cc: 'Bernard Aboba'; [email-masked]
Subject: RE: Consideration of
draft-lior-radius-attribute-type-extension-02.txt

Glen Zorn writes...
 
> [gwz] OK, so I'll finish cleaning up the examples in the draft & 
> submit the new "draft-ietf-radext" version this week.

Please use file name draft-ietf-radext-extended-attributes-00.txt.
[gwz] ACK

Thanks!

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

Delivery-date: Mon, 27 Aug 2007 21:13:26 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Peter Nixon'" <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 13:38:02 -0700

[gwz] ...
FWIW I also think that RADSEC should be  a WG item also but I am aware that 
some people are vehemently against that for reasons that are less 
apparent...
[gwz] Since I am one of those people, let me try to further clarify my
reasons for opposition.  Very simply, RADSEC is not RADIUS & this is the
RADIUS Extensions WG.  RADSEC changes virtually everything in RADIUS except
the format of the packets & attributes.  This must be considered a new
protocol, IMHO.  If the RADSEC folks want to have a BOF & try to convince
the IETF that we should work on standardizing this arguably good idea (at
least in the context of server<->server communication, I'm not convinced
about client<->server) I wouldn't oppose that at all, since that's the way
we deal with new protocols around here, AFAIK.

...

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

Delivery-date: Mon, 27 Aug 2007 20:27:38 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Glen Zorn'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 16:27:48 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...
 
> [gwz] OK, so I'll finish cleaning up the examples in the draft & 
> submit the new "draft-ietf-radext" version this week.

Please use file name draft-ietf-radext-extended-attributes-00.txt.

Thanks!

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

Delivery-date: Mon, 27 Aug 2007 20:24:55 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 16:24:57 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> The call for adoption of a WG work item is separate from the final
> consensus determination.

Agreed.

> In the call for adoption, the goal is to determine if there are
> enough people interested and whether there is consensus for adoption.

Yup.

> In determining this, both the opinions voiced on the mailing list
> and at IETF 69 need to be taken into account.

Right.

> Given that no dissenting opinions have been voiced and given the 
> size of both audiences put together, I think that the adoption
> requirements have been met.

Good deal.  Will the authors of this draft please prepare a revision with
the file name draft-ietf-radext-extended-attributes-00.txt?  We will then
begin formal review, leading to WGLC.

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

Delivery-date: Mon, 27 Aug 2007 20:19:54 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 13:19:33 -0700

>Please recall, however, that as a rough rule of thumb the IESG likes to see
>a document thoroughly reviewed and commented upon by six or more 
>individuals
>during WGLC, before it can be sent to the IESG as "publication requested".
>That's why we ask for that level of interest before adopting a draft as a 
>WG
>work item.

The call for adoption of a WG work item is separate from the final consensus

determination.  In the call for adoption, the goal is to determine if there 
are enough people interested and whether there is consensus for adoption.  
In determining this, both the opinions voiced on the mailing list and at 
IETF 69 need to be taken into account.  Given that no dissenting opinions 
have been voiced and given the size of both audiences put together, I think 
that the adoption requirements have been met.
[gwz] 
[gwz] OK, so I'll finish cleaning up the examples in the draft & submit the
new "draft-ietf-radext" version this week.
[gwz] 
...

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

Delivery-date: Mon, 27 Aug 2007 20:18:26 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 16:18:30 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> Note that this was a request from a *former* member of the IESG.

Yeah, but I saw something similar from Jari Arkko more recently.

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

Delivery-date: Mon, 27 Aug 2007 20:16:37 +0000
From: Peter Nixon <[email-masked]>
To: [email-masked]
Subject: Re: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 23:16:12 +0300

On Mon 27 Aug 2007, you wrote:
> [gwz] ...
>
> (b) "Is the level of affirmative response sufficient for this draft to
> become a WG work item?"
> [gwz]
> [gwz] Discounting the recent explosion of people (seldom, if ever, heard
> from before) pushing radsec, I suspect that there aren't many more than 4
> people active on this list (even including authors & chairs ;-).

There are many of us who also lurk on the list and prefer to leave the 
arguing up to others :-)

I think this draft should be accepted as a WG item.

FWIW I also think that RADSEC should be  a WG item also but I am aware that 
some people are vehemently against that for reasons that are less 
apparent...

Regards
-- 

Peter Nixon
http://peternixon.net/

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

Delivery-date: Mon, 27 Aug 2007 20:08:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 13:07:56 -0700

>Please recall, however, that as a rough rule of thumb the IESG likes to see
>a document thoroughly reviewed and commented upon by six or more 
>individuals
>during WGLC, before it can be sent to the IESG as "publication requested".
>That's why we ask for that level of interest before adopting a draft as a 
>WG
>work item.

The call for adoption of a WG work item is separate from the final consensus 
determination.  In the call for adoption, the goal is to determine if there 
are enough people interested and whether there is consensus for adoption.  
In determining this, both the opinions voiced on the mailing list and at 
IETF 69 need to be taken into account.  Given that no dissenting opinions 
have been voiced and given the size of both audiences put together, I think 
that the adoption requirements have been met.

In the final consensus determination, there is a need to make sure that the 
document has been thoroughly reviewed, both within the WG and externally (if 
necessary).  As a result, that process is somewhat different.

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

Delivery-date: Mon, 27 Aug 2007 20:01:51 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Consideration of consideration of requirements for consideration
Date: Mon, 27 Aug 2007 13:01:41 -0700

>[gwz] Discounting the recent explosion of people (seldom, if ever, heard
>from before) pushing radsec, I suspect that there aren't many more than 4
>people active on this list (even including authors & chairs ;-).

So far, only three people have responded to this topic, and two of them are 
the chairs.  Are we sure we even have a quorum to talk about quorum 
requirements ?:)

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

Delivery-date: Mon, 27 Aug 2007 19:59:24 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 12:59:10 -0700

>Please recall, however, that as a rough rule of thumb the IESG likes to see
>a document thoroughly reviewed and commented upon by six or more 
>individuals
>during WGLC, before it can be sent to the IESG as "publication requested".
>That's why we ask for that level of interest before adopting a draft as a 
>WG
>work item.

Note that this was a request from a *former* member of the IESG.

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

Delivery-date: Mon, 27 Aug 2007 19:53:46 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 15:53:35 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> ... I suspect that there aren't many more than 4 people active on
> this list (even including authors & chairs ;-).

Winking smiley-face duly noted.

Please recall, however, that as a rough rule of thumb the IESG likes to see
a document thoroughly reviewed and commented upon by six or more individuals
during WGLC, before it can be sent to the IESG as "publication requested".
That's why we ask for that level of interest before adopting a draft as a WG
work item.

Do we have any additional "takers" for this draft?

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

Delivery-date: Mon, 27 Aug 2007 19:30:50 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 12:30:16 -0700

[gwz] ...

(b) "Is the level of affirmative response sufficient for this draft to
become a WG work item?"
[gwz] 
[gwz] Discounting the recent explosion of people (seldom, if ever, heard
from before) pushing radsec, I suspect that there aren't many more than 4
people active on this list (even including authors & chairs ;-).

[gwz] ...

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

Delivery-date: Mon, 27 Aug 2007 18:32:10 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Consideration of draft-lior-radius-attribute-type-extension-02.txt
Date: Mon, 27 Aug 2007 14:31:39 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> Please reply to this message indicating whether you believe the
> document should be adopted as a RADEXT WG work item.
=A0
> This Request for Review will last until July 22, 2007.

In reviewing the archives, I see that six WG members, including two who =
are
authors of the draft, indicated that it ought to be come a WG work item.
FWIW, I think so too.  No WG members objected.  Discounting chairs and
authors, four WG members responded affirmatively.

The consensus of the room at IETF-69 was in favor of adopting this =
document
as s WG work item.

The deadline for review passed about a month ago.  This leads me to ask:

(a) "Are there any other responses pro or con?"

(b) "Is the level of affirmative response sufficient for this draft to
become a WG work item?"

(c) "If not, are there any other suggestions as to how the RADEXT WG =
should
fulfill this charter deliverable?"

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

Delivery-date: Mon, 27 Aug 2007 17:14:47 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'David B. Nelson'" <[email-masked]>
Cc: "'radext mailing list'" <[email-masked]>
Subject: RE: Extensibility of draft-ietf-radext-filter-rules
Date: Mon, 27 Aug 2007 09:38:11 -0700

David B. Nelson wrote:
> Maybe.  Keep in mind that the Extended RADIUS attribute work is
introducing
> a method of accommodating grouped attributes (AVPs) in RADIUS.

  That's nice, but doesn't solve the next problem.  The filter rules
document really describes transporting IP addresses and ports via...
text strings.  The guidelines document says this is not recommended.
However, the filter rules document could quickly use many attributes,
exhausting the standard attribute space.
[gwz] 
[gwz] I'm a bit confused by this statement: the attribute extension draft
basically doubles the size of the existing 
"standard attribute space.  Are you saying that the filter rules would take
up that whole extension?

  Is it time to allow sub-attributes?  I will not that the guidelines
document also has them as not recommended.  But 3GPP is using them, as
is WiMAX.  And WiMAX is using the extended attributes proposal... with
the WiMAX vendor identifier.

  Given the utility of sub-attributes, and the fact that most vendors
have implemented them already, or will implement them for WiMAX, I'm
inclined to add them to the extended attributes draft.
[gwz] What changes would you make?

  That would permit the filter rules document to define sub-attributes
using the normal RADIUS data types, and encapsulate them in a "filter
rules" AVP.  
Given the choice between implementing sub-attributes and
parsing text strings, I strongly prefer sub-attributes.

  Alan DeKok.

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

Delivery-date: Mon, 27 Aug 2007 14:37:11 +0000
Date: Mon, 27 Aug 2007 16:35:46 +0200
From: Hannes Tschofenig <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Extensibility of draft-ietf-radext-filter-rules

Hi David,

David B. Nelson wrote:
> Hannes Tschofenig writes...
>
>   
>> I have sent a few mails regarding the extensibility of
>> draft-ietf-radext-filter-rules
>>
>> I have never received a response on how it should look like.
>>     
>
> This is an open issue against that document and we need to resolve it here
> on the list.  Will the authors please comment?
>
>   
>> As I indicated in a previous mail we have guessed one approach in 
>> http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-01.txt.
>> It uses grouped AVPs and is therefore not great for RADIUS.
>>     
>
> Maybe.  Keep in mind that the Extended RADIUS attribute work is introducing
> a method of accommodating grouped attributes (AVPs) in RADIUS.
>
>   
Right. There is, however, a timing issue involved with the work and I am 
not sure when the corresponding work in RADIUS gets done. Do you have an 
estimate?

Ciao
Hannes

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

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

Delivery-date: Mon, 27 Aug 2007 14:26:40 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Draft Update: draft-ietf-geopriv-radius-lo-16.txt
Date: Mon, 27 Aug 2007 10:25:35 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> -16 of the RADIUS Location Document has been submitted.  This is likely to
> be the last revision.  So if there are any issues, please speak up NOW.

I think that this document is as good as it's going to get, given that the
RADEXT WG has only recently come to a tentative consensus on the format of
an extended RADIUS attribute that would support complex (i.e. multi-part)
attributes via the use of sub-attributes.  That document is not yet
available as a RADEXT WG work item draft (coming soon?).  I think that the
GEOPRIV draft could have been a much cleaner design if it has used
sub-attributes, from the forthcoming RADIUS Extended Attributes draft, but
the timing of this wasn't auspicious.

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

Delivery-date: Mon, 27 Aug 2007 14:16:43 +0000
Date: Mon, 27 Aug 2007 16:14:54 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Extensibility of draft-ietf-radext-filter-rules

David B. Nelson wrote:
>>   Is it time to allow sub-attributes?
> 
> That's exactly what the proposed Extended Attributes work provides.  One
> level of nesting for sub-attributes.

  I thought I had seen it at one point, but that doesn't stand out in a
quick check of the current draft.

>> I will not that the guidelines document also has them as not 
>> recommended.
> 
> For RADIUS "Classic", that's correct.

  The guidelines document should probably say it's OK for RADEXT to do
it. :)

..
> BTW, I think we have completed the consensus call on that document, but I
> don't remember if I saw the official result announced.

  I didn't see a call on the list to make the extended attributes
document a WG item.  There wasn't any objections at IETF 69, though.

  Alan DeKok.

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

Delivery-date: Mon, 27 Aug 2007 14:08:14 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: Extensibility of draft-ietf-radext-filter-rules
Date: Mon, 27 Aug 2007 10:07:03 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

> However, the filter rules document could quickly use many attributes,
> exhausting the standard attribute space.

That's would not be the intent.  Read on.

>   Is it time to allow sub-attributes?

That's exactly what the proposed Extended Attributes work provides.  One
level of nesting for sub-attributes.

> I will not that the guidelines document also has them as not 
> recommended.

For RADIUS "Classic", that's correct.

>   That would permit the filter rules document to define sub-attributes
> using the normal RADIUS data types, and encapsulate them in a "filter
> rules" AVP.  Given the choice between implementing sub-attributes and
> parsing text strings, I strongly prefer sub-attributes.

That's how the filter rules draft would be designed using the extended
attributes draft.

BTW, I think we have completed the consensus call on that document, but I
don't remember if I saw the official result announced.

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

Delivery-date: Mon, 27 Aug 2007 14:00:45 +0000
Date: Mon, 27 Aug 2007 15:59:03 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Extensibility of draft-ietf-radext-filter-rules

David B. Nelson wrote:
> Maybe.  Keep in mind that the Extended RADIUS attribute work is introducing
> a method of accommodating grouped attributes (AVPs) in RADIUS.

  That's nice, but doesn't solve the next problem.  The filter rules
document really describes transporting IP addresses and ports via...
text strings.  The guidelines document says this is not recommended.
However, the filter rules document could quickly use many attributes,
exhausting the standard attribute space.

  Is it time to allow sub-attributes?  I will not that the guidelines
document also has them as not recommended.  But 3GPP is using them, as
is WiMAX.  And WiMAX is using the extended attributes proposal... with
the WiMAX vendor identifier.

  Given the utility of sub-attributes, and the fact that most vendors
have implemented them already, or will implement them for WiMAX, I'm
inclined to add them to the extended attributes draft.

  That would permit the filter rules document to define sub-attributes
using the normal RADIUS data types, and encapsulate them in a "filter
rules" AVP.  Given the choice between implementing sub-attributes and
parsing text strings, I strongly prefer sub-attributes.

  Alan DeKok.

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

Delivery-date: Mon, 27 Aug 2007 13:56:33 +0000
Date: Mon, 27 Aug 2007 15:54:06 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Issues & Fixes document

David B. Nelson wrote:
> I think that's right.  Would you like to reprise the final proposed
> resolution text, i.e. the changes to the current draft?  I think I've lost
> track...

  The I-D tools page will show the "diff" graphically, but here it is
from local version control.  It's a bit long, so it might be an awkward
read as-is.

  Alan DeKok.

-----
@@ -152,30 +152,102 @@ Some RADIUS client implementations do no
 Some RADIUS client implementations do not properly use the State
 attribute in order to distinguish a restarted EAP authentication
 process from the continuation of an ongoing process (by the same user
-on the same NAS and port).
-
-Where an EAP-Message attribute is included in an Access-Challenge or
-Access-Accept attribute, RADIUS servers SHOULD also include a State
-attribute.  See Section 2.1.3 on Request ID supplementation for
-additional benefits to using the State attribute in this fashion.
-
+on the same NAS and port).  Where an EAP-Message attribute is included
+in an Access-Challenge or Access-Accept attribute, RADIUS servers
+SHOULD also include a State attribute.  See Section 2.1.2 on Request
+ID supplementation for additional benefits to using the State
+attribute in this fashion.
+
+As defined in [RFC2865] Table 5.44, Access-Request packets may contain
+a State attribute.  The table does not qualify this statement, while
+the text in Section 5.24 quoted above adds other requirements not
+specified in that table.
+
+We extend the requirements of [RFC2865] to say that Access-Requests
+which are part of an ongoing Access-Request / Access-Challenge
+authentication process SHOULD contain a State attribute.  It is the
+responsibility of the server to send a State attribute in an
+Access-Challenge packet, if that server needs a State attribute in a
+subsequent Access-Request to tie multiple Access-Requests togther into
+one authentication session.  As defined in [RFC2865] Section 5.24, the
+State MUST be sent unmodified from the client to the server in the new
+Access-Request reply to that challenge, if any.
+
+While most server implementations require the presence of a State
+attribute in an Access-Challenge packet, some challenge-response
+systems can distinguish the initial request from the response to the
+challenge without using a State attribute to track an authentication
+session.  The Access-Challenge and subsequent Access-Request packets
+for those systems do not need to contain a State attribute.
+
+Other authentication mechanisms need to tie a sequence of
+Access-Request / Access-Challenge packets together into one ongoing
+authentication session.  Servers implementing those authentication
+mechanisms SHOULD include a State attribute in Access-Challenge
+packets.
+
+In general, if the authentication process involves one or more
+Access-Request / Access-Challenge sequences, the State attribute
+SHOULD be sent by the server in the Access-Challenge packets.  Using
+the State attribute to create a multi-packet session is the simplest
+method available in RADIUS today.  While other methods of creating
+multi-packet sessions are possible (e.g. [RFC3579] Section 2.6.1),
+those methods are NOT RECOMMENDED.
+
+The only permissible values for a State attribute are values provided
+in an Access-Accept, Access-Challenge, CoA-Request or
+Disconnect-Request packet.  A RADIUS client MUST use only those values
+for the State attribute that it has previously received from a server.
 An Access-Request sent as a result of a new or restarted
-authentication run MUST NOT include the State attribute, even if the
+authentication run MUST NOT include the State attribute, even if a
 State attribute has previously been received in an Access-Challenge
 for the same user and port.

-Since a State attribute is always initially provided by the server in
-an Access-Accept, Access-Challenge, CoA-Request or Disconnect-Request,
-a RADIUS client MUST NOT insert a State attribute that it has not
-previously received from the server.
-
-As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
-contain a State attribute.  We extend that definition here, to say
-that Access-Request packets that contain an authentication attribute
-or a Service-Type attribute with the value Call Check (10) MAY contain
-a State attribute.  Access-Request packets not matching the above
-description MUST contain a State attribute.
-
+In contrast, Access-Requests which are intended to perform
+authorization checks MUST contain a State attribute in order to tie
+the authorization check to a previous authentication session.  This
+last requirement often means that an Access-Accept needs to contain a
+State attribute, which is then used in a later Access-Request that
+performs authorization checks.
+
+Access-Request packets that contain a Service-Type attribute with
+value Authorize Only (17) MUST contain a State attribute.
+Access-Request packets that contain a Service-Type attribute with
+value Call Check (10) SHOULD NOT contain a State attribute.  Any other
+Access-Request packet that performs authorization checks MUST contain
+a State attribute.
+
+The standard use case for Call-Check is pre-screening authentication
+based solely on the end-point identifier information, such as phone
+number or MAC address in Calling-Station-ID and optionally
+Called-Station-ID.  In that use case there is no source of the State
+attribute in the NAS.  Other, non-standard, uses of Call-Check may
+require or permit the use of a State Attribute, but are beyond the
+scope of this document.
+
+Implementing Call Check functionality via requests where the User-Name
+and User-Password contain the same information (e.g. MAC address) is
+NOT RECOMMENDED.  This practice gives an attacker both the clear-text
+and cipher-text of the User-Password field, which permits many
+additional attacks on the security of the RADIUS protocol.  For
+example, if the Request Authenticator does not satisfy the [RFC2865]
+requirements on global and temporal uniqueness, the practice described
+above may lead to the compromise of the User-Password attribute in
+other Access-Requests for unrelated users.  Access to the cipher-text
+also greatly simplifies offline dictionary attacks, potentially
+exposing the shared secret, and compromising the entire RADIUS
+protocol.
+
+Any Access-Request packet that performs authorization checks,
+including Call Check, MUST contain a Message-Authenticator attribute.
+Any response to an Access-Request performing an authorization check
+MUST NOT contain confidential information about any user (such as
+Tunnel-Password), unless that Access-Request contains a State
+attribute.  The use of State here permits the authorization check to
+be tied to an earlier user authentication.  In that case, the server
+MAY respond to the NAS with confidential information about that user.
+The server MUST NOT respond to that authorization check with
+confidential information about any other user.
 .in -0.3i
 .NH 3
 .R
@@ -275,13 +347,20 @@ implementations to implement complex ret
 implementations to implement complex retransmission algorithms,
 implementations SHOULD support congestive backoff within the limits
 suggested by [RFC2865] Section 2.4.
-
+.PP
+.in +0.3i
 RADIUS retransmission timers are based on the model used in DHCPv6
 [RFC3315].  Variables used here are also borrowed from this
 specification.  RADIUS is a request/response-based protocol.  The
 message exchange terminates when the requester successfully receives
 the answer or the message exchange is considered to have failed
-according to the retransmission mechanism described below.
+according to the RECOMMENDED retransmission mechanism described below.
+Other retransmission mechanisms are possible, so long as they satisfy
+the requirements on jitter and congestive backoff.
+
+The following algorithms apply to any client that originates RADIUS
+packets, including but not limited to Access-Request,
+Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576].

 The retransmission behavior is controlled and described by the
 following variables:
@@ -341,6 +420,13 @@ message.  If MRC is non-zero, the messag
 message.  If MRC is non-zero, the message exchange fails when the
 either the sender has transmitted the message MRC times, or when MRD
 seconds have elapsed since the client first transmitted the message.
+
+For Accounting-Request packets, the default values for MRC, MRD, and
+MRT SHOULD be zero.  These settings will enable a RADIUS client to
+continue sending accounting requests to a RADIUS server until the
+request is acknowledged.  If any of MRC, MRD, or MRT are non-zero,
+then the accounting information could potentially be discarded without
+being recorded.
 .in -0.3i
 .NH 3
 .R
@@ -732,24 +818,27 @@ 5.26 states:
 .fi

 It is possible for either a standard attribute or VSA to represent a
-request for an unavailable service.  However, where the Type or
-Vendor-ID is unknown, a RADIUS client will not know whether the
-attribute defines a service or not.
-
-In general, it is best for RADIUS clients to err on the side of
+request for an unavailable service.  However, where the Type,
+Vendor-ID, or Vendor-Type is unknown, a RADIUS client will not know
+whether the attribute defines a service or not.
+
+In general, it is best for a RADIUS clients to err on the side of
 caution.  On receiving an Access-Accept including an attribute of
-unknown Type, a RADIUS client SHOULD assume that it is a potential
-service definition, and treat it as an Access-Reject.  Unknown VSAs
-SHOULD be ignored by RADIUS clients.
-
-As there may be interoperability issues with the above suggestion,
-client implementations SHOULD make the suggested behavior
-configurable.  A configuration flag such as "treat unknown attributes
-as reject" can be exposed to the system administrator.  If the flag is
+known Type for an unimplemented service, a RADIUS client MUST treat it
+as an Access-Reject, as directed in [RFC2865] Section 1.1.  On
+receiving an Access-Accept including an attribute of unknown Type, a
+RADIUS client SHOULD assume that it is a potential service definition,
+and treat it as an Access-Reject.  Unknown VSAs SHOULD be ignored by
+RADIUS clients.
+
+In order to avoid introducing changes in default behavior, existing
+implementations that do not obey this recommendation should make the
+behavior configurable, with the legacy behavior being enabled by
+default. A configuration flag such as "treat unknown attributes as
+reject" can be exposed to the system administrator.  If the flag is
 set to true, then Access-Accepts containing unknown attributes are
 treated as Access-Rejects.  If the flag is set to false, then unknown
-attributes in Access-Accepts are be silently ignored. The default
-value for the flag SHOULD be set to true.
+attributes in Access-Accepts are be silently ignored.

 On receiving a packet including an attribute of unknown type, RADIUS
 authentication server implementations SHOULD ignore such attributes.
@@ -1163,7 +1252,8 @@ forged by an attacker.  Cache entries ca
 forged by an attacker.  Cache entries can then be forcibly expired,
 negating the utility of the cache.  This attack can be mitigated by
 following the suggestions in [RFC3579] Section 4, or by requiring the
-presence of Message-Authenticator, as described in Section 2.2.2.
+presence of Message-Authenticator, as described in Sections 2.1.1 and
+2.2.2.

 Since this document describes the use of RADIUS for purposes of
 authentication, authorization, and accounting in a wide variety of
@@ -1211,6 +1301,10 @@ Droms, R., Bound, J., Volz, B., Lemon, T
 Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney,
 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315,
 July 2003.
+.IP [RFC3576]
+Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,
+"Dynamic Authorization Extensions to Remote Authentication
+Dial In User Service (RADIUS)", RFC 3576, July 2003.
 .IP [RFC3579]
 Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication
 Protocol (EAP)", RFC 3579, September 2003.

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

Delivery-date: Mon, 27 Aug 2007 13:31:10 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: Extensibility of draft-ietf-radext-filter-rules
Date: Mon, 27 Aug 2007 09:29:46 -0400
Organization: Elbrys Networks, Inc.

Hannes Tschofenig writes...

> I have sent a few mails regarding the extensibility of
> draft-ietf-radext-filter-rules
> 
> I have never received a response on how it should look like.

This is an open issue against that document and we need to resolve it here
on the list.  Will the authors please comment?

> As I indicated in a previous mail we have guessed one approach in 
> http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-01.txt.
> It uses grouped AVPs and is therefore not great for RADIUS.

Maybe.  Keep in mind that the Extended RADIUS attribute work is introducing
a method of accommodating grouped attributes (AVPs) in RADIUS.

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

Delivery-date: Mon, 27 Aug 2007 13:27:11 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Issues & Fixes document
Date: Mon, 27 Aug 2007 09:25:43 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   Not hearing any more updates, I think we can submit the latest version
> of the document.

I think that's right.  Would you like to reprise the final proposed
resolution text, i.e. the changes to the current draft?  I think I've lost
track...

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

Delivery-date: Mon, 27 Aug 2007 12:49:39 +0000
Date: Mon, 27 Aug 2007 14:47:07 +0200
From: Alan DeKok <[email-masked]>
To:  [email-masked]
Subject: Issues & Fixes document

  Not hearing any more updates, I think we can submit the latest version
of the document.

  Alan DeKok.

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

Delivery-date: Sun, 26 Aug 2007 19:13:08 +0000
Date: Sun, 26 Aug 2007 21:12:29 +0200
From: Hannes Tschofenig <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: Extensibility of draft-ietf-radext-filter-rules

I have sent a few mails regarding the extensibility of 
draft-ietf-radext-filter-rules

I have never received a response on how it should look like. As I 
indicated in a previous mail we have guessed one approach in 
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-01.txt. 
It uses grouped AVPs and is therefore not great for RADIUS.

I would appreciate guidance.

Ciao
Hannes

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

Delivery-date: Sun, 26 Aug 2007 17:29:12 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Draft Update: draft-ietf-geopriv-radius-lo-16.txt
Date: Sun, 26 Aug 2007 10:28:10 -0700

-16 of the RADIUS Location Document has been submitted.  This is likely to 
be the last revision.  So if there are any issues, please speak up NOW.

>From: Hannes Tschofenig <[email-masked]>
>To: Internet-Drafts Administrator <[email-masked]>
>Subject: Draft Update: draft-ietf-geopriv-radius-lo-16.txt
>Date: Sun, 26 Aug 2007 10:00:02 +0200
>
>Dear Editor,
>
>we would like to submit an update of an GEOPRIV working group item. Please 
>find the updated draft here:
>http://www.tschofenig.com/svn/draft-ietf-geopriv-radius-lo/draft-ietf-geopriv-radius-lo-16.txt
>
>Ciao
>Hannes

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

Delivery-date: Fri, 24 Aug 2007 20:05:53 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Formal review of draft-ietf-radext-management-authorization-00.txt
Date: Fri, 24 Aug 2007 08:37:57 -0400

Now that the draft "Remote Authentication Dial-In User Service (RADIUS)
Authorization for Network Access Server (NAS) Management" has been accepted
as a RADEXT WG work item, and has been published in the Internet Drafts
repository at
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati
on-00.txt, please formally review the document to determine if it is ready
for WGLC.  Please send comments to this list using the format described in
the RADEXT Issues tracker: http://www.drizzle.com/~aboba/RADEXT/.
 
This review period will last until September 14, 2007.  At that time issues
raised on the list will be resolved.  Once all issues are addressed we will
start WGLC on the document.

This notice is being copied to the ISMS WG list, as this document is a
normative dependency for the "RADIUS Usage for SNMP Transport Models" draft
being worked on in the ISMS WG.

A summary of changes from
draft-nelson-radius-management-authorization-05.txt is listed below, and
includes resolution of all comments received during the pre-WG work item
review:

"SNMP View Based Access Control Method (VACM)" --> "SNMP View Based Access
Control Model (VACM)"

Spelling corrections.

"UTF-8 encoded 10646 [RFC2279]" --> "UTF-8 encoded 10646 [RFC3629]"

Addition to IANA Considerations Section: 

"Assignment of additional values for attributes defined in this document are
to be processed as described in [RFC3575]."

Break References Section into Normative and Informative.

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

Delivery-date: Fri, 24 Aug 2007 15:11:52 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: Request for formal review of draft-ietf-radext-management-authorization-00.txt
Date: Fri, 24 Aug 2007 11:11:11 -0400
Organization: Elbrys Networks, Inc.

(The first attempt is stuck somewhere, so I'm resending this message.)

Now that the draft "Remote Authentication Dial-In User Service (RADIUS)
Authorization for Network Access Server (NAS) Management" has been accepted
as a RADEXT WG work item, and has been published in the Internet Drafts
repository at
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati
on-00.txt, please formally review the document to determine if it is ready
for WGLC.  Please send comments to this list using the format described in
the RADEXT Issues tracker: http://www.drizzle.com/~aboba/RADEXT/.
 
This review period will last until September 14, 2007.  At that time issues
raised on the list will be resolved.  Once all issues are addressed we will
start WGLC on the document.

This notice is being copied to the ISMS WG list, as this document is a
normative dependency for the "RADIUS Usage for SNMP Transport Models" draft
being worked on in the ISMS WG.

A summary of changes from
draft-nelson-radius-management-authorization-05.txt is listed below, and
includes resolution of all comments received during the pre-WG work item
review:

"SNMP View Based Access Control Method (VACM)" --> "SNMP View Based Access
Control Model (VACM)"

Spelling corrections.

"UTF-8 encoded 10646 [RFC2279]" --> "UTF-8 encoded 10646 [RFC3629]"

Addition to IANA Considerations Section: 

"Assignment of additional values for attributes defined in this document are
to be processed as described in [RFC3575]."

Break References Section into Normative and Informative.

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

Delivery-date: Thu, 23 Aug 2007 21:15:20 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-management-authorization-00.txt 
Date: Thu, 23 Aug 2007 17:15:01 -0400

--NextPart

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

	Title		: Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
	Author(s)	: D. Nelson, G. Weber
	Filename	: draft-ietf-radext-management-authorization-00.txt
	Pages		: 15
	Date		: 2007-8-23
	
   This document describes Remote Authentication Dial-In User Service
   (RADIUS) attributes for the authorization and service provisioning of
   local and remote management of embedded systems and other managed
   entities, generally referred to as Network Access Servers (NASes).
   Specific provisions are made for remote management via framed
   management protocols, and for more granular levels of access rights
   and management privileges.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-management-authorization-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-management-authorization-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-management-authorization-00.txt

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

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

--OtherAccess--

--NextPart--

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

Envelope-to: [email-masked]
Delivery-date: Thu, 23 Aug 2007 20:18:25 +0000
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, radext mailing list <[email-masked]>, radext chair <[email-masked]>
Subject: Protocol Action: 'RADIUS Extension for Digest  Authentication' to Proposed Standard 
Message-Id: <[email-masked]>
Date: Thu, 23 Aug 2007 16:17:36 -0400

The IESG has approved the following document:

- 'RADIUS Extension for Digest Authentication '
   <draft-ietf-radext-rfc4590bis-02.txt> as a Proposed Standard

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

The IESG contact persons are Dan Romascanu and Ron Bonica.

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

Technical Summary
 
   This document defines an extension to the Remote Authentication Dial-
   In User Service (RADIUS) protocol to enable support of Digest
   Authentication, for use with HTTP-style protocols like the Session
   Initiation Protocol (SIP) and HTTP.
 
Working Group Summary
 
   Working Group discussion largely centered on whether the issues
   identified in RFC 4590 could be fixed via an errata or whether
   a new RFC was required.  Due to conflicts between the RFC 4590 text
   and the parameters allocated by IANA, it was decided that a new
   RFC would be needed, so as to avoid potential interoperability
   problems.

Protocol Quality
 
This document is needed to address a problem in the IANA allocations for
Digest Authentication as well as several errata that were found after the
publication of RFC 4590.  This document is believed to address all issues
raised since the publication of RFC 4590. The document was reviewed by Dan
Romascanu on behalf of the IESG. 

Note to RFC Editor
 
 RFC Editor,
 Please replace Appendix A with the text below: 

  This is an example selected from the traffic between a softphone (A),
  a Proxy Server (B), and an example.com RADIUS server (C).  The
  communication between the Proxy Server and a SIP Public Switched
  Telephone Network (PSTN) gateway is omitted for brevity.  The SIP
  messages are not shown completely.

  The password of user '12345678' is 'secret'. The shared secret
  between RADIUS client and server is 'secret'. To ease testing,
  only the last byte of the RADIUS authenticator changes between
  requests. In a real implementation, this would be a serious flaw.

  A->B

     INVITE sip:[email-masked] SIP/2.0
     From: <sip:[email-masked]>
     To: <sip:[email-masked]>

  B->A

     SIP/2.0 100 Trying

  B->C

     Code = Access-Request (1)
     Packet identifier = 0x7c (124)
     Length = 97
     Authenticator = F5E55840E324AA49D216D9DBD069807C
     NAS-IP-Address = 192.0.2.38
     NAS-Port = 5
     User-Name = 12345678
     Digest-Method = INVITE
     Digest-URI = sip:[email-masked]
     Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B

  C->B

     Code = Access-challenge (11)
     Packet identifier = 0x7c (124)
     Length = 72
     Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D
     Digest-Nonce = 3bada1a0
     Digest-Realm = example.com
     Digest-Qop = auth
     Digest-Algorithm = MD5
     Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3

  B->A

     SIP/2.0 407 Proxy Authentication Required
     Proxy-Authenticate: Digest realm="example.com"
          ,nonce="3bada1a0",qop=auth,algorithm=MD5
     Content-Length: 0

  A->B

     ACK sip:[email-masked] SIP/2.0

  A->B

     INVITE sip:[email-masked] SIP/2.0
     Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
          ,realm="example.com"
          ,response="7679b84a560835846ec553174dbabb69"
          ,uri="sip:[email-masked]",username="12345678"
          ,qop=auth,algorithm=MD5
          ,cnonce="56593a80,nc="00000001"

     From: <sip:[email-masked]>
     To: <sip:[email-masked]>

  B->C

     Code = Access-Request (1)
     Packet identifier = 0x7d (125)
     Length = 221
     Authenticator = F5E55840E324AA49D216D9DBD069807D
     NAS-IP-Address = 192.0.2.38
     NAS-Port = 5
     User-Name = 12345678
     Digest-Method = INVITE
     Digest-URI = sip:[email-masked]
     Digest-Realm = example.com
     Digest-Qop = auth
     Digest-Algorithm = MD5
     Digest-CNonce = 56593a80
     Digest-Nonce = 3bada1a0
     Digest-Nonce-Count = 00000001
     Digest-Response = 7679b84a560835846ec553174dbabb69
     Digest-Username = 12345678
     SIP-AOR = sip:[email-masked]
     Message-Authenticator = BD037498E8385878A46ECF4D5F8D2B48

  C->B

     Code = Access-Accept (2)
     Packet identifier = 0x7d (125)
     Length = 72
     Authenticator = 36E1201AD4377664E720184CE7B3D8C6
     Digest-Response-Auth = 3792d3109224eb67213659e2d789f10d
     Message-Authenticator = 9B79B410CEBD335176DAEB24735DCF64

  B->A

     SIP/2.0 180 Ringing

  B->A

     SIP/2.0 200 OK

  A->B

     ACK sip:[email-masked] SIP/2.0

  A second example shows the traffic between a web browser (A), web
  server (B), and a RADIUS server (C).

  A->B

     GET /index.html HTTP/1.1

  B->C
     Code = Access-Request (1)
     Packet identifier = 0x7e (126)
     Length = 68
     Authenticator = F5E55840E324AA49D216D9DBD069807E
     NAS-IP-Address = 192.0.2.38
     NAS-Port = 5
     Digest-Method = GET
     Digest-URI = /index.html
     Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992

  C->B

     Code = Access-challenge (11)
     Packet identifier = 0x7e (126)
     Length = 72
     Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E
     Digest-Nonce = a3086ac8
     Digest-Realm = example.com
     Digest-Qop = auth
     Digest-Algorithm = MD5
     Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A

  B->A

     HTTP/1.1 401 Authentication Required
     WWW-Authenticate: Digest realm="example.com",
         nonce="a3086ac8",qop=auth,algorithm=MD5
     Content-Length: 0

  A->B

     GET /index.html HTTP/1.1
     Authorization: Digest algorithm=MD5,qop=auth,nonce="a3086ac8"
          ,nc="00000001",cnonce="56593a78"
          ,realm="example.com"
          ,response="ba623217b5ec024d30c4aaef9d8494de"
          ,uri="/index.html",username="12345678"

  B->C

     Code = Access-Request (1)
     Packet identifier = 0x7f (127)
     Length = 176
     Authenticator = F5E55840E324AA49D216D9DBD069807F
     NAS-IP-Address = 192.0.2.38
     NAS-Port = 5
     User-Name = 12345678
     Digest-Method = GET
     Digest-URI = /index.html
     Digest-Realm = example.com
     Digest-Qop = auth
     Digest-Algorithm = MD5
     Digest-CNonce = 56593a80
     Digest-Nonce = a3086ac8
     Digest-Nonce-Count = 00000001
     Digest-Response = ba623217b5ec024d30c4aaef9d8494de
     Digest-Username = 12345678
     Message-Authenticator = C360BFCEDFFBCE893469E802013DA5AA

  C->B

     Code = Access-Accept (2)
     Packet identifier = 0x7f (127)
     Length = 72
     Authenticator = F1ECAC22D3C88E0260B287FA35595F80
     Digest-Response-Auth = 29624e0bee4342994d041d07f7bcd44c
     Message-Authenticator = 956312EC57AF51ABC4F6965270F34982

  B->A

     HTTP/1.1 200 OK
     ...

     <html>
     ...

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

Delivery-date: Thu, 23 Aug 2007 08:54:42 +0000
Date: Thu, 23 Aug 2007 10:53:58 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked],  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes

Glen Zorn wrote:
>>     ...
>>     Yes. RFC 2865 mentions only User-Password and CHAP-Password, and
>>     refers to other "authentication information". We could extend the list
>>     to include currently known authentication attributes. But I think it's
>>     better to give directions for future efforts.
>      
>     Speaking of which, shouldn't this be in the design guidelines,
>     rather than issues & fixes?

  Perhaps.  It's in the context of "clarifying how to use state", which
belongs in issues & fixes, because many people got it wrong.  How to use
State in the future is just another sentence here.  The text can be
re-iterated, and expanded in the "guidelines" document.

  Alan DeKok.

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

Delivery-date: Wed, 22 Aug 2007 18:32:13 +0000
Date: Wed, 22 Aug 2007 11:31:38 -0700 (PDT)
From: Glen Zorn <[email-masked]>
Subject: Re: Request for Review: "Issues and Fixes" changes
To: Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked]

--0-1493323623-1187807498=:84117
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  ...
  Yes. RFC 2865 mentions only User-Password and CHAP-Password, and
refers to other "authentication information". We could extend the list
to include currently known authentication attributes. But I think it's
better to give directions for future efforts. 
   
  Speaking of which, shouldn't this be in the design guidelines, rather than issues & fixes?

---------------------------------
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. 
--0-1493323623-1187807498=:84117
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">  <div>...</div>  <div>Yes. RFC 2865 mentions only User-Password and CHAP-Password, and<BR>refers to other "authentication information". We could extend the list<BR>to include currently known authentication attributes. But I think it's<BR>better to give directions for future efforts. </div>  <div dir=ltr style="MARGIN-RIGHT: 0px"><FONT face="arial black" color=#0000ff></FONT>&nbsp;</div>  <div dir=ltr style="MARGIN-RIGHT: 0px"><FONT face="Arial Black" color=#0000ff>Speaking of which, shouldn't this be in the design guidelines, rather than issues &amp; fixes?</FONT></div></BLOCKQUOTE><p>&#32;
      <hr size=1>Ready for the edge of your seat? 
<a href="http://us.rd.yahoo.com/evt=48220/*http://tv.yahoo.com/">Check out tonight's top picks</a> on Yahoo! TV. 

--0-1493323623-1187807498=:84117--

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

Delivery-date: Wed, 22 Aug 2007 16:01:56 +0000
Date: Wed, 22 Aug 2007 09:01:46 -0700 (PDT)
From: Glen Zorn <[email-masked]>
Subject: Re: Reminder: automated key management is often required for new protocols
To: Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked], [email-masked]

--0-1767419651-1187798506=:99339
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Alan DeKok <[email-masked]> wrote:    Bernard Aboba wrote:
> I think you mean "distribution of long-term credentials" here. In
> (D)TLS the session keys are are fresh for each session (via the use of
> client.random and server.random).

Sure. RFC 4107 calls them "long term session keys", but they're long
term credentials in the context of RADIUS.
   
  gwz> What 4107 _really calls them is "long-term keys" (see section 2, paragraph 
  gwz> 2) but whatever...

...

---------------------------------
Fussy? Opinionated? Impossible to please? Perfect.  Join Yahoo!'s user panel and lay it on us.
--0-1767419651-1187798506=:99339
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<BR><BR><B><I>Alan DeKok &lt;[email-masked]&gt;</I></B> wrote:  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">  <div>Bernard Aboba wrote:<BR>&gt; I think you mean "distribution of long-term credentials" here. In<BR>&gt; (D)TLS the session keys are are fresh for each session (via the use of<BR>&gt; client.random and server.random).<BR><BR>Sure. RFC 4107 calls them "long term session keys", but they're long<BR>term credentials in the context of RADIUS.</div>  <div>&nbsp;</div>  <div>gwz&gt; What 4107 _really calls them is "long-term keys" (see section 2, paragraph </div>  <div>gwz&gt; 2) but whatever...<BR><BR>...</div></BLOCKQUOTE><p>&#32;
      <hr size=1>Fussy? Opinionated? Impossible to please? Perfect.  <a href="http://us.rd.yahoo.com/evt=48516/*http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ">Join Yahoo!'s user panel</a> and lay it on us.

--0-1767419651-1187798506=:99339--

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

Delivery-date: Wed, 22 Aug 2007 15:55:44 +0000
Date: Wed, 22 Aug 2007 08:55:32 -0700 (PDT)
From: Glen Zorn <[email-masked]>
Subject: Re: Reminder: automated key management is often required for new protocols
To: Alan DeKok <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: [email-masked]

--0-787850332-1187798132=:96479
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Alan DeKok <[email-masked]> wrote:    ...
  
Section 2.2: The manual key management for long-term session keys
meets the last criteria in this section:

The scale of each deployment is very limited.

Ideally, each long-term key in DTLS is shared only between one server
and one client. Each client-server pair shares a unique key, and those
keys are (ideally) not re-used across multiple client-server pairs.
There aren't many deployments that are smaller scale than two parties.
   
  gwz> I don't think that by "deployment" they mean how many parties share a key 
  gwz> ;-); more like how many NASs to a server (which can be in the thousands).
  
...

---------------------------------
Building a website is a piece of cake. 
Yahoo! Small Business gives you all the tools to get online.
--0-787850332-1187798132=:96479
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<BR><BR><B><I>Alan DeKok &lt;[email-masked]&gt;</I></B> wrote:  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">  <div>...</div>  <div><BR>Section 2.2: The manual key management for long-term session keys<BR>meets the last criteria in this section:<BR><BR>The scale of each deployment is very limited.<BR><BR>Ideally, each long-term key in DTLS is shared only between one server<BR>and one client. Each client-server pair shares a unique key, and those<BR>keys are (ideally) not re-used across multiple client-server pairs.<BR>There aren't many deployments that are smaller scale than two parties.</div>  <div>&nbsp;</div>  <div>gwz&gt; I don't think that by "deployment" they mean how many parties share a key </div>  <div>gwz&gt; ;-); more like how many NASs to a server (which can be in the thousands).</div>  <div><BR>...</div></BLOCKQUOTE><p>&#32;
      <hr size=1>Building a website is a piece of cake. <br>Yahoo! Small Business gives you <a href="http://us.rd.yahoo.com/evt=48251/*http://smallbusiness.yahoo.com/webhosting/?p=PASSPORTPLUS">all the tools to get online.</a>
--0-787850332-1187798132=:96479--

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

Delivery-date: Wed, 22 Aug 2007 15:41:34 +0000
Date: Wed, 22 Aug 2007 08:40:53 -0700 (PDT)
From: Glen Zorn <[email-masked]>
Subject: Re: Request for Review: "Issues and Fixes" changes
To: Bernard Aboba <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]

--0-1512281982-1187797253=:90920
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Bernard Aboba <[email-masked]> wrote:    >To clarify: some SERVER implementations need State for particular
>authentication methods. Others do not.
>
>The only interoperability requirement is on the client. If it sees a
>State in an Access-Challenge, it echoes that back in the next
>Access-Request. There is no interoperability requirement on the server.
>If it needs State, it implements code looking for State. 
   
  gwz> And sending a State attribute in the first place.
   
  >If it doesn't
>need state, it doesn't implement code looking for State.

  gwz> Nor send a State attribute in the first place.
  
I think the issue goes beyond interoperability (although that is certainly 
something worth clarifying).

For example, if an Access-Request contains neither an authentication 
attribute or State attribute, there are security implications.

Some RADIUS attributes (such as Tunnel-Password) reveal confidential 
information about a user, and so they require some evidence of user 
authentication. 
   
  gwz> Well, maybe; but when used w/L2TP (the only real-world usage of the Tunnel-
  gwz> Password attribute of which I'm aware) it normally contains a password for 
  gwz> the NAS/LAC to use to authenticate itself to the LNS & so has nothing to do 
  gwz> with any human user.  The RFC 2868 attributes are often used in replies to 
  gwz> Access-Requests with Service-Type = Call Check, BTW.
   
  > There's no reason for server to send State if they don't need it.

For the reasons above, I don't believe that is what RFC 2865 intended.
   
  gwz> I don't quite get your logic here.  2865 seems pretty clear and unambiguous 
  gwz> (for once ;-) on this topic: usage of the State attribute is always optional on 
  gwz> the server side & server driven and it is always mandatory on the client side -- 
  gwz> if it receives one it must return it unchanged in the next Access-Request (if 
  gwz> any).  
...
  
> The recommendation is that new authentication methods SHOULD use State
>for multiple Access-Request / Access-Challenge sequences. Since
>existing methods *don't* use State all of the time for such sequences,
>it's impolite to require that new methods MUST use it.

  gwz> I agree.
  
RFC 2865 has a MUST relating to inclusion of authentication attributes or 
State within an Access-Request. It would seem that this ignored some cases 
(such as Call-Check) in which State either is optional or realistically 
can't be included at all. 
   
  gwz> I believe that common practice is to include a User-Password attribute in call 
  gwz> checks, possibly containing a canned "password".  This practice has the 
  gwz> nice side-effect of providing (weak) authentication of the NAS as well -- 
  gwz> something that was otherwise impossible pre-2869.
  ...

---------------------------------
Luggage? GPS? Comic books? 
Check out fitting  gifts for grads at Yahoo! Search.
--0-1512281982-1187797253=:90920
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<B><I>Bernard Aboba &lt;[email-masked]&gt;</I></B> wrote:  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">  <div>&gt;To clarify: some SERVER implementations need State for particular<BR>&gt;authentication methods. Others do not.<BR>&gt;<BR>&gt;The only interoperability requirement is on the client. If it sees a<BR>&gt;State in an Access-Challenge, it echoes that back in the next<BR>&gt;Access-Request. There is no interoperability requirement on the server.<BR>&gt;If it needs State, it implements code looking for State. </div>  <div>&nbsp;</div>  <div>gwz&gt; And sending a State attribute in the first place.</div>  <div>&nbsp;</div>  <div>&gt;If it doesn't<BR>&gt;need state, it doesn't implement code looking for State.<BR></div>  <div>gwz&gt; Nor send a State attribute in the first place.</div>  <div><BR>I think the issue goes beyond interoperability (although that is certainly <BR>something worth
 clarifying).<BR><BR>For example, if an Access-Request contains neither an authentication <BR>attribute or State attribute, there are security implications.<BR><BR>Some RADIUS attributes (such as Tunnel-Password) reveal confidential <BR>information about a user, and so they require some evidence of user <BR>authentication. </div>  <div>&nbsp;</div>  <div>gwz&gt; Well, maybe; but when used w/L2TP (the only real-world usage of the Tunnel-</div>  <div>gwz&gt; Password attribute of which I'm aware) it normally contains a password for </div>  <div>gwz&gt; the NAS/LAC to use to authenticate itself to the LNS &amp; so has nothing to do </div>  <div>gwz&gt; with any human user.&nbsp; The RFC 2868 attributes are often used in replies to </div>  <div>gwz&gt; Access-Requests with Service-Type = Call Check, BTW.</div>  <div>&nbsp;</div>  <div>&gt; There's no reason for server to send State if they don't need it.<BR><BR>For the reasons above, I don't believe that is what RFC 2865
 intended.</div>  <div>&nbsp;</div>  <div>gwz&gt;&nbsp;I don't quite get your logic here.&nbsp; 2865 seems pretty clear and unambiguous </div>  <div>gwz&gt; (for once ;-) on this topic: usage of the State attribute is always optional on </div>  <div>gwz&gt; the server side &amp; server driven and it is always mandatory on the client side -- </div>  <div>gwz&gt; if it receives one it must return it unchanged in the next Access-Request (if </div>  <div>gwz&gt; any).&nbsp; <BR>...</div>  <div><BR>&gt; The recommendation is that new authentication methods SHOULD use State<BR>&gt;for multiple Access-Request / Access-Challenge sequences. Since<BR>&gt;existing methods *don't* use State all of the time for such sequences,<BR>&gt;it's impolite to require that new methods MUST use it.<BR></div>  <div>gwz&gt; I agree.</div>  <div><BR>RFC 2865 has a MUST relating to inclusion of authentication attributes or <BR>State within an Access-Request. It would seem that this ignored some cases
 <BR>(such as Call-Check) in which State either is optional or realistically <BR>can't be included at all. </div>  <div>&nbsp;</div>  <div>gwz&gt; I believe that common practice is to include a User-Password attribute in call </div>  <div>gwz&gt; checks, possibly containing a canned "password".&nbsp; This practice has the </div>  <div>gwz&gt; nice side-effect of providing (weak) authentication of the NAS as well -- </div>  <div>gwz&gt; something that was otherwise impossible pre-2869.</div>  <div>...</div></BLOCKQUOTE><p>&#32;
      <hr size=1>Luggage? GPS? Comic books? <br>
Check out fitting <a href="http://us.rd.yahoo.com/evt=48249/*http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz"> gifts for grads</a> at Yahoo! Search.
--0-1512281982-1187797253=:90920--

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

Delivery-date: Wed, 22 Aug 2007 09:59:47 +0000
Date: Wed, 22 Aug 2007 11:59:05 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes  -- Call-Check.

David B. Nelson wrote:
...
>> "The standard use case for Call-Check is pre-screening 
>> authentication based solely on the phone number information in
> 
> s/phone number information/end-point identifier information, such as phone
> number or MAC address,/

  Looks good to me.

> This generalizes the content of the Call*-Station-ID to more closely match
> current practice.

  I agree.

  Alan DeKok.

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

Delivery-date: Wed, 22 Aug 2007 09:47:18 +0000
Date: Wed, 22 Aug 2007 11:46:14 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes

Bernard Aboba wrote:
>> ...
>> Any Access-Request packet that performs authorization checks,
>> including Call Check, MUST contain a Message-Authenticator attribute.
> 
> I'm not sure what it means to say "performs authorization checks".  Do
> you mean that the Access-Request doesn't contain an authentication
> attribute (and therefore that State is required)?  While we do require
> "Authorize Only" Access-Requests to include a Message-Authenticator
> attribute, I'm not sure this is the only case.

  Yes.  The suggested text discusses Authorize Only specifically, but
leaves open the issue of what other authorization checks could be.

  I'd prefer to avoid discussion of "authentication attributes".  I
think it just causes confusion.

> I don't know that the RADIUS server can necessarily determine what
> attributes constitute "confidential information".

  The local administrator configuring the policy can do that.

>   So I think we need
> to try to simplify things somewhat.   Was there an issue with the RFC
> 2865 prescription (either include an authentication attribute or State)?

  Yes.  RFC 2865 mentions only User-Password and CHAP-Password, and
refers to other "authentication information".  We could extend the list
to include currently known authentication attributes.  But I think it's
better to give directions for future efforts.  The alternative is to
issue a later document that patches the list of authentication attributes.

>>   The Call-Check situation is one where the authentication is being done
>> on the call, via the Called / Calling Station Id.  So in this situation,
>> the Called / Calling Station id attributes are the authentication
>> attributes.
> 
> That seems like a reasonable explanation of the RFC 2865 MUST.  I'd
> suggest that we include this explanation in the text to clarify the
> meaning of "authentication attribute" in RFC 2865.

  RFC 2865 uses "authentication information", which seems vague, but useful.

>> ...  This practice should be discouraged, because it results in
>> giving an attacker both the clear-text and cipher-text for User-Password.
> 
> Which in turn can lead to compromise of the User-Password attribute if
> the Request Authenticator is every repeated with the same shared secret
> (e.g. global and temporal uniqueness required as per RFC 2865).  This
> also would be something worth including in the text.

  OK.

...
For
example, if the Request Authenticator does not satisfy the [RFC2865]
requirements on global and temporal uniqueness, the practice described
above may lead to the compromise of the User-Password attribute in
other Access-Requests for unrelated users.  Access to the cipher-text
also greatly simplifies offline dictionary attacks, potentially
exposing the shared secret, and compromising the entire RADIUS
protocol.
...

>>   The server doesn't need to use State for EAP.  It doesn't need to use
>> State for *some* challenge-response systems using User-Password.  It
>> doesn't need to use State for Call-Check... which doesn't leave many
>> areas where it is needed.
> 
> Yup.  RFC 2865 only REQUIRES State where "authentication attributes" are
> not present at all.  So if we can clarify what "authentication
> attributes" mean, then we'll know when State is required.

  State is not required for authentication.  State is required for
authorization checks.  I'm open to suggestions for more detailed text.

> As for other cases, I think it may depend on the attributes included in
> the Access-Accept.  However, in the interest of simplicity, it is
> probably not reasonable for the RADIUS server to keep track of all the
> situations in which a State attribute might be needed.

  I don't think it needs to keep track.  I think that particular
authentication mechanisms may mandate the use of State.  For
authorization, if the Access-Request doesn't contain a State, the server
won't be able to tie it to a previous authentication, and therefore
won't be able to return Access-Accept.

>>   I can't recommend when State MUST be used elsewhere, because I can't
>> think of other situations where it's needed.  The text already makes it
>> a MUST for Authorization-Only, and MUST for other authorization checks.
> 
> Can we define what "authorization checks" means? Is this just
> Service-Type = Call Check or Authorize-Only?

  Service-Type = Call Check is really (pre)-authentication.

  Authorize-Only is an authorization check, and is described as such in
the document,  The additional vague wording on "authorization checks" is
there to catch future uses, and to avoid repeating past mistakes.

  Alan DeKok.

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

Delivery-date: Wed, 22 Aug 2007 06:54:46 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Request for Review: "Issues and Fixes" changes
Date: Tue, 21 Aug 2007 23:54:14 -0700

>   Some of which can be dealt with by mandating Message-Authenticator.
>Once the NAS is authenticated, there are fewer security issues with
>allowing it to perform authorization checks.

There are two somewhat distinct issues.  One is the authenticity of the 
Access-Request; that is addressed by adding Message-Authenticator.  The 
other is whether the NAS is authorized to obtain the user's authorizations.  
That requires the NAS to demonstrate that it is acting on behalf of a live 
user via the inclusion of either an authentication attribute or State.

>RFC 3576 is silent on this issue, because it defines Authorize Only in
>the context of CoA / Disconnect messages, and not for Access-Requests.

Right.

>   Maybe something like this:
>
>...
>Any Access-Request packet that performs authorization checks,
>including Call Check, MUST contain a Message-Authenticator attribute.

I'm not sure what it means to say "performs authorization checks".  Do you 
mean that the Access-Request doesn't contain an authentication attribute 
(and therefore that State is required)?  While we do require "Authorize 
Only" Access-Requests to include a Message-Authenticator attribute, I'm not 
sure this is the only case.

>Any response to an Access-Request performing an authorization check
>MUST NOT contain confidential information about any user (such as
>Tunnel-Password), unless that Access-Request contains a State
>attribute.

I don't know that the RADIUS server can necessarily determine what 
attributes constitute "confidential information".   So I think we need to 
try to simplify things somewhat.   Was there an issue with the RFC 2865 
prescription (either include an authentication attribute or State)?

>   The Call-Check situation is one where the authentication is being done
>on the call, via the Called / Calling Station Id.  So in this situation,
>the Called / Calling Station id attributes are the authentication
>attributes.

That seems like a reasonable explanation of the RFC 2865 MUST.  I'd suggest 
that we include this explanation in the text to clarify the meaning of 
"authentication attribute" in RFC 2865.

>   However, most systems implementing this kind of check (e.g. MAC
>address checking) do so by setting the User-Name and User-Password to
>the MAC address.  This is done because it's easier to just add a MAC
>address as a user/password, rather than implementing a Call-Check
>policy.  This practice should be discouraged, because it results in
>giving an attacker both the clear-text and cipher-text for User-Password.

Which in turn can lead to compromise of the User-Password attribute if the 
Request Authenticator is every repeated with the same shared secret (e.g. 
global and temporal uniqueness required as per RFC 2865).  This also would 
be something worth including in the text.

>   The server doesn't need to use State for EAP.  It doesn't need to use
>State for *some* challenge-response systems using User-Password.  It
>doesn't need to use State for Call-Check... which doesn't leave many
>areas where it is needed.

Yup.  RFC 2865 only REQUIRES State where "authentication attributes" are not 
present at all.  So if we can clarify what "authentication attributes" mean, 
then we'll know when State is required.

>   The most common use of State seems to be in *addition* to the
>authentication attributes.  e.g. EAP, or challenge-response methods that
>leverage User-Password.

Yes.

>   A less common use of State is for authorization checks, in order to
>tie the authorization checks to a previous authentication session.  (And
>how does the server know that the NAS will need State for use in a later
>authorization check?  Should the server ALWAYS send State back?)

In a CoA-Request with "Authorize Only" the DAC expects that an 
Access-Request will result.  Now this presumes that the DAC can obtain a 
State Attribute that the RADIUS server will understand.  Otherwise, the 
RADIUS server won't be able to make sense of the State Attribute provided by 
the DAC.

As for other cases, I think it may depend on the attributes included in the 
Access-Accept.  However, in the interest of simplicity, it is probably not 
reasonable for the RADIUS server to keep track of all the situations in 
which a State attribute might be needed.

>   I can't recommend when State MUST be used elsewhere, because I can't
>think of other situations where it's needed.  The text already makes it
>a MUST for Authorization-Only, and MUST for other authorization checks.

Can we define what "authorization checks" means? Is this just Service-Type = 
Call Check or Authorize-Only?

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

Delivery-date: Wed, 22 Aug 2007 06:32:11 +0000
Date: Wed, 22 Aug 2007 08:31:39 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes

Bernard Aboba wrote:
> For example, if an Access-Request contains neither an authentication
> attribute or State attribute, there are security implications.

  Some of which can be dealt with by mandating Message-Authenticator.
Once the NAS is authenticated, there are fewer security issues with
allowing it to perform authorization checks.

  I would also add that since authorization checks do not include
authentication attributes, they MUST include a Message-Authenticator.
RFC 3576 is silent on this issue, because it defines Authorize Only in
the context of CoA / Disconnect messages, and not for Access-Requests.

  Maybe something like this:

...
Any Access-Request packet that performs authorization checks,
including Call Check, MUST contain a Message-Authenticator attribute.
Any response to an Access-Request performing an authorization check
MUST NOT contain confidential information about any user (such as
Tunnel-Password), unless that Access-Request contains a State
attribute.  The use of State here permits the authorization check to
be tied to an earlier user authentication.  In that case, the server
MAY respond to the NAS with confidential information about that user.
The server MUST NOT respond to that authorization check with
confidential information about any
other user.
...

> Some RADIUS attributes (such as Tunnel-Password) reveal confidential
> information about a user, and so they require some evidence of user
> authentication.  Therefore if there is no authentication attribute
> present, then the server needs some evidence that the request is linked
> to a previous user authentication, so that the server is authorized to
> answer the request.  That evidence is provided by the State Attribute.

  Yes.  See above.

> RFC 2865 has a MUST relating to inclusion of authentication attributes
> or State within an Access-Request.  It would seem that this ignored some
> cases (such as Call-Check) in which State either is optional or
> realistically can't be included at all.

  The Call-Check situation is one where the authentication is being done
on the call, via the Called / Calling Station Id.  So in this situation,
the Called / Calling Station id attributes are the authentication
attributes.

  However, most systems implementing this kind of check (e.g. MAC
address checking) do so by setting the User-Name and User-Password to
the MAC address.  This is done because it's easier to just add a MAC
address as a user/password, rather than implementing a Call-Check
policy.  This practice should be discouraged, because it results in
giving an attacker both the clear-text and cipher-text for User-Password.

>  Given this situation, I don't
> believe that a SHOULD would provide the required clarification. Instead,
> it would be better to clarify the cases in which State is a MUST  and
> the cases in which it is optional.

  The server doesn't need to use State for EAP.  It doesn't need to use
State for *some* challenge-response systems using User-Password.  It
doesn't need to use State for Call-Check... which doesn't leave many
areas where it is needed.

  The most common use of State seems to be in *addition* to the
authentication attributes.  e.g. EAP, or challenge-response methods that
leverage User-Password.

  A less common use of State is for authorization checks, in order to
tie the authorization checks to a previous authentication session.  (And
how does the server know that the NAS will need State for use in a later
authorization check?  Should the server ALWAYS send State back?)

  I can't recommend when State MUST be used elsewhere, because I can't
think of other situations where it's needed.  The text already makes it
a MUST for Authorization-Only, and MUST for other authorization checks.
 Everything else is a SHOULD.

  This is what the text says today.  Are there additional suggestions
for "... MUST use State" ?

  Alan DeKok.

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

Delivery-date: Wed, 22 Aug 2007 05:51:35 +0000
Date: Wed, 22 Aug 2007 07:51:07 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Reminder: automated key management is often required for new protocols

Bernard Aboba wrote:
> I think you mean "distribution of long-term credentials" here.   In
> (D)TLS the session keys are are fresh for each session (via the use of
> client.random and server.random).

  Sure.  RFC 4107 calls them "long term session keys", but they're long
term credentials in the context of RADIUS.

> Even if TLS-PSK is used and the PSKs are re-used across client-server
> pairs (e.g. RADIUS shared secret practices are replicated in TLS-PSK),
> the session keys would still be likely to be temporally and globally
> unique, due to the (D)TLS freshness functionality.

  Yes.

> It might help to articulate the threat model a bit. Are we worried about
> an offline dictionary attack on the PSK or its precursor, or are we
> worried about temporal or global uniqueness of the TLS master secret?

  An offline dictionary attack on the PSK or its precursor.

  The simplest way to avoid that is to suggest the use of certificates.

  Alan DeKok.

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

Delivery-date: Wed, 22 Aug 2007 05:35:48 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Reminder: automated key management is often required for new protocols
Date: Tue, 21 Aug 2007 22:35:17 -0700

>   DTLS requires manual key management to distribute long-term session
>keys.  These can be shared secrets for TLS-PSK methods, or certificates
>for other TLS methods.

I think you mean "distribution of long-term credentials" here.   In (D)TLS 
the session keys are are fresh for each session (via the use of 
client.random and server.random).

>   Section 2.2: The manual key management for long-term session keys
>meets the last criteria in this section:

I think you mean "long-term credentials";  (D)TLS session keys are not 
long-term, they are refreshed on session resume.

>   Ideally, each long-term key in DTLS is shared only between one server
>and one client.  Each client-server pair shares a unique key, and those
>keys are (ideally) not re-used across multiple client-server pairs.
>There aren't many deployments that are smaller scale than two parties.

Even if TLS-PSK is used and the PSKs are re-used across client-server pairs 
(e.g. RADIUS shared secret practices are replicated in TLS-PSK), the session 
keys would still be likely to be temporally and globally unique, due to the 
(D)TLS freshness functionality.

>   We could say that for PSK methods, the PSK that is used in TLS MUST be
>the output of the shared secret amplification, and not the original text
>as entered by the administrator.  This method would be a step to
>addressing the requirements of [RFC4107] Section 2.3.  At the minimum,
>it would increase the attack cost by a fixed factor of (say) 1,000,000.

It might help to articulate the threat model a bit. Are we worried about an 
offline dictionary attack on the PSK or its precursor, or are we worried 
about temporal or global uniqueness of the TLS master secret?

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

Delivery-date: Wed, 22 Aug 2007 05:23:23 +0000
Date: Wed, 22 Aug 2007 07:22:51 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Reminder: automated key management is often required for new protocols

David B. Nelson wrote:
>>> If you have not already taken a look at RFC 4107 in the context of
>>> your working group, please do so.
> 
> So, all of the RADEXT WG members participating in the discussion of our
> Crypto-Agility work item now have some homework to do: read RFC 4107 and
> report back on how it applies to the proposed solutions we are considering.

  DTLS requires manual key management to distribute long-term session
keys.  These can be shared secrets for TLS-PSK methods, or certificates
for other TLS methods.

  Section 2.1:   As noted at the bottom of page 2 of RFC 4107, TLS
provides automated key management.  Therefore the requirements of
Section 2.1 are satisfied by DTLS.

  Section 2.2: The manual key management for long-term session keys
meets the last criteria in this section:

     The scale of each deployment is very limited.

  Ideally, each long-term key in DTLS is shared only between one server
and one client.  Each client-server pair shares a unique key, and those
keys are (ideally) not re-used across multiple client-server pairs.
There aren't many deployments that are smaller scale than two parties.

  Section 2.3: If certificates are used, the certificate generation
scheme will have to satisfy these criteria.  If shared secrets are used
for TLS-PSK, it gets a little harder to meet these criteria.  We could
avoid the problem by pushing the requirements back onto the admistrator
(i.e. You MUST use hard-to-guess shared secrets).  But that's not
particularly secure.

  Perhaps something like Paul Funk's proposal would help:

http://www.funk.com/documents/draft-funk-radiusext-shared-secret-amp-00.txt

  We could say that for PSK methods, the PSK that is used in TLS MUST be
the output of the shared secret amplification, and not the original text
as entered by the administrator.  This method would be a step to
addressing the requirements of [RFC4107] Section 2.3.  At the minimum,
it would increase the attack cost by a fixed factor of (say) 1,000,000.

  Alan DeKok.

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

Delivery-date: Wed, 22 Aug 2007 05:00:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Request for Review: "Issues and Fixes" changes
Date: Tue, 21 Aug 2007 22:00:13 -0700

>To clarify: some SERVER implementations need State for particular
>authentication methods.  Others do not.
>
>The only interoperability requirement is on the client.  If it sees a
>State in an Access-Challenge, it echoes that back in the next
>Access-Request.  There is no interoperability requirement on the server.
>If it needs State, it implements code looking for State.  If it doesn't
>need state, it doesn't implement code looking for State.

I think the issue goes beyond interoperability (although that is certainly 
something worth clarifying).

For example, if an Access-Request contains neither an authentication 
attribute or State attribute, there are security implications.

Some RADIUS attributes (such as Tunnel-Password) reveal confidential 
information about a user, and so they require some evidence of user 
authentication.  Therefore if there is no authentication attribute present, 
then the server needs some evidence that the request is linked to a previous 
user authentication, so that the server is authorized to answer the request. 
  That evidence is provided by the State Attribute.

So I don't think it is accurate to say that the server can dispense with the 
State Attribute without consequences.

>   There's no reason for server to send State if they don't need it.

For the reasons above,  I don't believe that is what RFC 2865 intended.

> > Please refresh my memory regarding these discussions.  Why would an EAP
> > exchange in RADIUS not require the use of State?
>
>   RFC 3579 doesn't recommend using it.  Instead, it has a very
>complicated system which is more fragile, but sometimes functionally
>equivalent.

Where an EAP-Message attribute is included in an Access-Request, the RFC 
2865 requirement for an authentication attribute or State is fulfilled.  So 
I would agree that the use of State is not required.

>   The recommendation is that new authentication methods SHOULD use State
>for multiple Access-Request / Access-Challenge sequences.  Since
>existing methods *don't* use State all of the time for such sequences,
>it's impolite to require that new methods MUST use it.

RFC 2865 has a MUST relating to inclusion of authentication attributes or 
State within an Access-Request.  It would seem that this ignored some cases 
(such as Call-Check) in which State either is optional or realistically 
can't be included at all.  Given this situation, I don't believe that a 
SHOULD would provide the required clarification. Instead, it would be better 
to clarify the cases in which State is a MUST  and the cases in which it is 
optional.

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

Delivery-date: Wed, 22 Aug 2007 05:00:35 +0000
Date: Wed, 22 Aug 2007 06:59:47 +0200
From: Alan DeKok <[email-masked]>
To:  [email-masked]
CC: "David B. Nelson" <[email-masked]>
Subject: Re: Request for Review: "Issues and Fixes" changes

  Replying to myself with suggested  text that may be clearer:

...
   As defined in [RFC2865] Table 5.44, Access-Request packets may
   contain a State attribute.  The table does not qualify this
   statement, while the text in Section 5.24 quoted above adds other
   requirements not specified in that table.

   We extend the requirements of [RFC2865] to say that Access-Requests
   which are part of an ongoing Access-Request / Access-Challenge
   authentication process SHOULD contain a State attribute.  It is the
   responsibility of the server to send a State attribute in an Access-
   Challenge packet, if that server needs a State attribute in a
   subsequent Access-Request to tie multiple Access-Requests together
   into one authentication session.  As defined in [RFC2865] Section
   5.24, the State MUST be sent unmodified from the client to the server
   in the new Access-Request reply to that challenge, if any.

   While most server implementations require the presence of a State
   attribute in an Access-Challenge packet, some challenge-response
   systems can distinguish the initial request from the response to the
   challenge without using a State attribute to track an authentication
   session.  The Access-Challenge and subsequent Access-Request packets
   for those systems do not need to contain a State attribute.

   Other authentication mechanisms need to tie a sequence of Access-
   Request / Access-Challenge packets together into one ongoing
   authentication session.  Servers implementing those authentication
   mechanisms SHOULD include a State attribute in Access-Challenge
   packets.

   In general, if the authentication process involves one or more
   Access-Request / Access-Challenge sequences, the State attribute
   SHOULD be sent by the server in the Access-Challenge packets.  Using
   the State attribute to create a multi-packet session is the simplest
   method available in RADIUS today.  While other methods of creating
   multi-packet sessions are possible (e.g. [RFC3579] Section 2.6.1),
   those methods are NOT RECOMMENDED.

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

Delivery-date: Wed, 22 Aug 2007 04:34:30 +0000
Date: Wed, 22 Aug 2007 06:33:26 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes

David B. Nelson wrote:
>> ... Some need State, others do not.
> 
> Here's the problem with that approach, it doesn't lead to interoperable
> standards.

  To clarify: some SERVER implementations need State for particular
authentication methods.  Others do not.

  The only interoperability requirement is on the client.  If it sees a
State in an Access-Challenge, it echoes that back in the next
Access-Request.  There is no interoperability requirement on the server.
 If it needs State, it implements code looking for State.  If it doesn't
need state, it doesn't implement code looking for State.

>  The documents we produce are supposed to lead to independent,
> interoperable implementations based on the document alone.  I don't see how
> that happens if we decide that the on-the-wire message content is
> implementation-dependent. 

  The server requirements for local policy and authentication are
*always* implementation-dependent.  Sometimes the implementation is the
code, other times the local site policy.

> If any compliant system relies on receiving a given attribute for
> interoperability, then the standard needs to mandate that all
> implementations send that attribute.

  There's no reason for server to send State if they don't need it.

  What interoperability requirements are you thinking about?

>>   I'd like to make it a MUST, but based on the discussions around
>> EAP, I think it's only a SHOULD.
> 
> Please refresh my memory regarding these discussions.  Why would an EAP
> exchange in RADIUS not require the use of State?

  RFC 3579 doesn't recommend using it.  Instead, it has a very
complicated system which is more fragile, but sometimes functionally
equivalent.

  Even in EAP implementations that use State, the initial identity
request from the server doesn't need a State.  It probably *shouldn't*
have one, because allocating one would involve tracking sessions for
unknown, and un-named users.

>>    Some RADIUS client implementations do not properly use the State
>>    attribute in order to distinguish a restarted EAP authentication
>>    process from the continuation of an ongoing process (by the same user
>>    on the same NAS and port).  Where an EAP-Message attribute is
>>    included in an Access-Challenge or Access-Accept attribute, RADIUS
>>    servers SHOULD also include a State attribute.
> 
> Why is this not a MUST?

  See above.  Also, Section 2.1.2 in the document describes the new
method of using State, and makes it a SHOULD.

>>    We extend the requirements of [RFC2865] to say that Access-Requests
>>    which are part of an ongoing Access-Request / Access-Challenge
>>    authentication process SHOULD contain a State attribute.
> 
> Why not MUST for the general case, with SHOULD or MAY for specific exception
> cases?

  The only MUST is that an implementation MUST use State if there's no
simpler way to track a "session".  If multiple packet exchanges don't
need "session" tracking (as above), then there's no need to use State.

  I have no real objection to making it a MUST, but doing so would
involve requiring many implementations to add State that they don't need.

> And how does an implementation that needs State tell that it is talking to
> an implementation that doesn't?  This seems like a real interoperability
> problem.

  A SERVER implementation that needs state talks to a CLIENT
implementation that MUST echo State from an Access-Challenge in any
subsequent Access-Request.

  Server implementations don't talk to each other. :)

>>   Any other Access-
>>    Request packet that does not contain an authentication attribute as
> 
> Uh... We just used the undefined term "authentication attribute".  :-)

  I'll go nuke it.

>>  A server may send an EAP-Message "identity request", and not include
>> State.  For the rest of the EAP session, State may be required.
> 
> May be required?  When?  Why?  Under what circumstances?  I don't think we
> can leave it that open ended.

  RFC 3576 does.  I believe that there are EAP server implementations
that don't use State.

>>> We should also advise authors of VSAs that they ought to take 
>>> note of this issue, and be explicit in their documents as to whether
>>> or not a State attribute is required to pair up with any new 
>>> authentication attributes being defined.
>>   Is the suggested text above clear enough to cover this possibility?
> 
> Not really.  I didn't see any mention of VSAs.

  It's not about VSA's.  It's about the authentication process.  I would
prefer to not discuss VSA's, or the particular authentication attributes
(whatever they are).

  The recommendation is that new authentication methods SHOULD use State
for multiple Access-Request / Access-Challenge sequences.  Since
existing methods *don't* use State all of the time for such sequences,
it's impolite to require that new methods MUST use it.

  Alan DeKok.

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

Delivery-date: Tue, 21 Aug 2007 20:12:38 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Reminder: automated key management is often required for new protocols
Date: Tue, 21 Aug 2007 16:12:29 -0400
Organization: Elbrys Networks, Inc.

> >If you have not already taken a look at RFC 4107 in the context of
> >your working group, please do so.

So, all of the RADEXT WG members participating in the discussion of our
Crypto-Agility work item now have some homework to do: read RFC 4107 and
report back on how it applies to the proposed solutions we are considering.

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

Delivery-date: Tue, 21 Aug 2007 19:51:49 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: FW: Reminder: automated key management is often required for newprotocols
Date: Tue, 21 Aug 2007 12:51:13 -0700

>From: Sam Hartman <[email-masked]>
>To: [email-masked]
>Subject: Reminder: automated key management is often required for 
>newprotocols
>Date: Tue, 21 Aug 2007 12:38:10 -0400 (EDT)
>
>I wanted to send out a brief reminder to working group chairs about
>RFC 4107.  This BCP, published in June of 2005, gives guidance on when
>our protocols need to have an automated key management mechanism.
>
>By this point, you should expect to need to follow RFc 4107 for any
>new protocols and should not be surprised when you are required to
>update protocols to comply with RFC 4107 in order to significantly
>increase their applicability.
>
>In many cases, this means you will need to have an automated mechanism
>for doing key management for security mechanisms your protocol.  This
>does not mean you need to support PKIs or even public-key operations.
>
>If you have not already taken a look at RFc 4107 in the context of
>your working group, please do so.  If you have any questions Tim and I
>would be happy to answer them.
>
>I'm writing because it looks like I will file a number of discuss
>positions this week asking for significant additional security work to
>be done on protocols before they can be published.  I'd like to avoid
>such late surprises for future work.
>
>
>Sam Hartman
>Security Area Director
>

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

Delivery-date: Tue, 21 Aug 2007 17:57:30 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for Review: "Issues and Fixes" changes
Date: Tue, 21 Aug 2007 13:57:00 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   The problem is that the MUST for State is really
> implementation-dependent.  i.e. challenge-response systems
> leverage Access-Challenge and User-Password.  Some need State,
> others do not.

Here's the problem with that approach, it doesn't lead to interoperable
standards.  The documents we produce are supposed to lead to independent,
interoperable implementations based on the document alone.  I don't see how
that happens if we decide that the on-the-wire message content is
implementation-dependent. 

Sure, implementers are free to innovate and go above and beyond the
standard, or even to deviate from the standard if they don't want to claim
strict compliance.  What we cannot do, I think, is decide that the standard
should leave the on-the-wire message format and content up to individual
implementations.  It needs to be fully specified -- standardized.

>   The MAY here means "if your system needs it, it is permitted to use
> it.  If your system doesn't need it, there's no harm in adding it."

If any compliant system relies on receiving a given attribute for
interoperability, then the standard needs to mandate that all
implementations send that attribute.

>   I'd like to make it a MUST, but based on the discussions around
> EAP, I think it's only a SHOULD.

Please refresh my memory regarding these discussions.  Why would an EAP
exchange in RADIUS not require the use of State?

>   The other thing is that the whole use of State for authorization
> checks is a horrible hack.

Well, yeah, maybe.  But it's a standardized hack, upon which many
implementations rely.  :-)  It is what it is.
 
>   I've re-written the text, and as a bonus, it looks like we can drop
> the references to specific authentication attributes:
> 
> ...
>    Some RADIUS client implementations do not properly use the State
>    attribute in order to distinguish a restarted EAP authentication
>    process from the continuation of an ongoing process (by the same user
>    on the same NAS and port).  Where an EAP-Message attribute is
>    included in an Access-Challenge or Access-Accept attribute, RADIUS
>    servers SHOULD also include a State attribute.

Why is this not a MUST?

>    See Section 2.1.3 on
>    Request ID supplementation for additional benefits to using the State
>    attribute in this fashion.
> 
>    As defined in [RFC2865] Table 5.44, Access-Request packets may
>    contain a State attribute.  The table does not qualify this
>    statement, while the text in Section 5.24 quoted above adds
>    additional requirements.
> 
>    We extend the requirements of [RFC2865] to say that Access-Requests
>    which are part of an ongoing Access-Request / Access-Challenge
>    authentication process SHOULD contain a State attribute.

Why not MUST for the general case, with SHOULD or MAY for specific exception
cases?

>    While most
>    implementations require the presence of a State attribute in an
>    Access-Challenge packet, some challenge-response systems can
>    distinguish the initial request from the response to the challenge
>    without using a State attribute to track an authentication session.
>    The Access-Challenge and subsequent Access-Request packets for those
>    systems do not need to contain a State attribute.

And how does an implementation that needs State tell that it is talking to
an implementation that doesn't?  This seems like a real interoperability
problem.
 
>    Other authentication systems require additional information outside
>    of the authentication mechanism in order to tie a sequence of Access-
>    Request / Access-Challenge packets to an ongoing authentication
>    session.  Those systems SHOULD include a State attribute in Access-
>    Challenge packets.
> 
>    In general, if the authentication process involves one or more
>    Access-Request / Access-Challenge sequences, the State attribute
>    SHOULD be sent in the Access-Challenge packets.

Again, why not MUST?  Or at least MUST for the general case, with SHOULD or
MAY for specific exception cases (that we fully describe).

>    The only permissible values for a State attribute are values provided
>    in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
>    Request packet.  A RADIUS client MUST use only those values for the
>    State attribute that it has previously received from a server.  An
>    Access-Request sent as a result of a new or restarted authentication
>    run MUST NOT include the State attribute, even if a State attribute
>    has previously been received in an Access-Challenge for the same user
>    and port.
> 
>    In contrast, Access-Requests which are intended to perform
>    authorization checks MUST contain a State attribute in order to tie
>    the authorization check to a previous authentication session.  This
>    last requirement often means that an Access-Accept needs to contain a
>    State attribute, which is then used in a later Access-Request that
>    performs authorization checks.
> 
>    Access-Request packets that contain a Service-Type attribute with
>    value Authorize Only (17) MUST contain a State attribute.  Access-
>    Request packets that contain a Service-Type attribute with value Call
>    Check (10) SHOULD NOT contain a State attribute.  Any other Access-
>    Request packet that does not contain an authentication attribute as

Uh... We just used the undefined term "authentication attribute".  :-)

>    defined above MUST contain a State attribute.  This list is not
>    exhaustive, and may be extended in future specifications.

>   I would prefer to focus on the process, rather than the attributes.

Agreed.

>  A server may send an EAP-Message "identity request", and not include
> State.  For the rest of the EAP session, State may be required.

May be required?  When?  Why?  Under what circumstances?  I don't think we
can leave it that open ended.

> > We should also advise authors of VSAs that they ought to take 
> > note of this issue, and be explicit in their documents as to whether
> > or not a State attribute is required to pair up with any new 
> > authentication attributes being defined.
> 
>   Is the suggested text above clear enough to cover this possibility?

Not really.  I didn't see any mention of VSAs.

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

Delivery-date: Tue, 21 Aug 2007 15:24:32 +0000
Date: Tue, 21 Aug 2007 17:23:40 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes

David B. Nelson wrote:
> Ah, so you are using MAY to indicate conditional MUST, rather than to
> indicate an option (i.e. personal choice).  That doesn't comport with RFC
> 2119.  I understand why the Table of Attributes has 0-1, but I'm concerned
> about the use of MAY in the text, especially if we really mean a conditional
> MUST.  I think we need to break out the conditions in the text, applying
> MUST and MAY as appropriate.

  The problem is that the MUST for State is really
implementation-dependent.  i.e. challenge-response systems leverage
Access-Challenge and User-Password.  Some need State, others do not.

  The MAY here means "if your system needs it, it is permitted to use
it.  If your system doesn't need it, there's no harm in adding it."

  I'd like to make it a MUST, but based on the discussions around EAP, I
think it's only a SHOULD.

  The other thing is that the whole use of State for authorization
checks is a horrible hack.  Instead, there should be a session
identifier returned by the RADIUS server to the NAS in an Access-Accept,
and that session identifier should be used in all subsequent
authorization checks, and Accounting-Requests.

  I've re-written the text, and as a bonus, it looks like we can drop
the references to specific authentication attributes:

...
   Some RADIUS client implementations do not properly use the State
   attribute in order to distinguish a restarted EAP authentication
   process from the continuation of an ongoing process (by the same user
   on the same NAS and port).  Where an EAP-Message attribute is
   included in an Access-Challenge or Access-Accept attribute, RADIUS
   servers SHOULD also include a State attribute.  See Section 2.1.3 on
   Request ID supplementation for additional benefits to using the State
   attribute in this fashion.

   As defined in [RFC2865] Table 5.44, Access-Request packets may
   contain a State attribute.  The table does not qualify this
   statement, while the text in Section 5.24 quoted above adds
   additional requirements.

   We extend the requirements of [RFC2865] to say that Access-Requests
   which are part of an ongoing Access-Request / Access-Challenge
   authentication process SHOULD contain a State attribute.  While most
   implementations require the presence of a State attribute in an
   Access-Challenge packet, some challenge-response systems can
   distinguish the initial request from the response to the challenge
   without using a State attribute to track an authentication session.
   The Access-Challenge and subsequent Access-Request packets for those
   systems do not need to contain a State attribute.

   Other authentication systems require additional information outside
   of the authentication mechanism in order to tie a sequence of Access-
   Request / Access-Challenge packets to an ongoing authenticaiton
   session.  Those systems SHOULD include a State attribute in Access-
   Challenge packets.

   In general, if the authentication process involves one or more
   Access-Request / Access-Challenge sequences, the State attribute
   SHOULD be sent in the Access-Challenge packets.

   The only permissible values for a State attribute are values provided
   in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-
   Request packet.  A RADIUS client MUST use only those values for the
   State attribute that it has previously received from a server.  An
   Access-Request sent as a result of a new or restarted authentication
   run MUST NOT include the State attribute, even if a State attribute
   has previously been received in an Access-Challenge for the same user
   and port.

   In contrast, Access-Requests which are intended to perform
   authorization checks MUST contain a State attribute in order to tie
   the authorization check to a previous authentication session.  This
   last requirement often means that an Access-Accept needs to contain a
   State attribute, which is then used in a later Access-Request that
   performs authorization checks.

   Access-Request packets that contain a Service-Type attribute with
   value Authorize Only (17) MUST contain a State attribute.  Access-
   Request packets that contain a Service-Type attribute with value Call
   Check (10) SHOULD NOT contain a State attribute.  Any other Access-
   Request packet that does not contain an authentication attribute as
   defined above MUST contain a State attribute.  This list is not
   exhaustive, and may be extended in future specifications.

> I would recommend adding text to that effect, as an implementation note, to
> clarify when the State attribute is and is not required in an
> Access-Challenge and subsequent Access-Request.

  See text above.

> Yes, adding wording as to what attributes require the inclusion of the State
> attribute would be preferable.

  I would prefer to focus on the process, rather than the attributes.  A
server may send an EAP-Message "identity request", and not include
State.  For the rest of the EAP session, State may be required.

> I think we need to mention them, and describe the type of attribute that
> would qualify as authentication attribute in general terms.  We should also
> advise authors of VSAs that they ought to take note of this issue, and be
> explicit in their documents as to whether or not a State attribute is
> required to pair up with any new authentication attributes being defined.

  Is the suggested text above clear enough to cover this possibility?

  Alan DeKok.

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

Delivery-date: Tue, 21 Aug 2007 13:36:40 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for Review: "Issues and Fixes" changes  -- Call-Check.
Date: Tue, 21 Aug 2007 09:36:16 -0400

David B. Nelson writes...

Following up to my last post...

> You might go on to say:
> 
> "The standard use case for Call-Check is pre-screening 
> authentication based solely on the phone number information in

s/phone number information/end-point identifier information, such as phone
number or MAC address,/

> Calling-Station-ID and optionally Called-Station-ID.  In that use 
> case there is no source of the State attribute in the NAS.  Other,
> non-standard, uses of Call-Check may require or permit the use of
> a State Attribute, but are beyond the scope of this document."

This generalizes the content of the Call*-Station-ID to more closely match
current practice.

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

Delivery-date: Tue, 21 Aug 2007 13:10:52 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for Review: "Issues and Fixes" changes  -- Call-Check.
Date: Tue, 21 Aug 2007 09:10:28 -0400

Alan DeKok writes...
 
>   Maybe we want to change that to "... Call Check MAY NOT contain
>   a State attribute".  This permits them to (magically) have one 
>   if they so desire.  It permits them to not have one in real-life
>   implementations.

"MAY NOT" is not a keyword defined in RFC 2119.  I would avoid using it.  I
think you want to say something like:

"Access-Request messages containing a Service-Type attribute with a value of
Call Check SHOULD NOT contain a State attribute."

You might go on to say:

"The standard use case for Call-Check is pre-screening authentication based
solely on the phone number information in Calling-Station-ID and optionally
Called-Station-ID.  In that use case there is no source of the State
attribute in the NAS.  Other, non-standard, uses of Call-Check may require
or permit the use of a State Attribute, but are beyond the scope of this
document."

> This permits them to (magically) have one if they so
> desire.  It permits them to not have one in real-life 
> implementations.

The text I suggest here does the same.  It just makes the usage conditions a
bit more explicit, which I think is desirable. 

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

Delivery-date: Tue, 21 Aug 2007 12:58:30 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for Review: "Issues and Fixes" changes
Date: Tue, 21 Aug 2007 08:57:43 -0400

Alan DeKok writes...

> >>    We extend this definition to say that Access-Requests which
> >>    are part of an ongoing authentication process MAY contain a
> >>    State attribute.
> >
> > So, this sentence really confuses me.  Maybe I'm taking it out
> > of context, but my understanding is that an Access-Request that
> > is part of an ongoing authentication process MUST contain a State
> > Attribute.  This has been the case since the State attribute was
> > defined.  Why are we changing it to MAY?
> 
>   We're not.  RFC 2865, Table 5.44 says State is "0-1" in
> Access-Request.  Note 1 says that Access-Requests contain User-
> Password, CHAP-Password, or State.  Section 2 says that Access-
> Challenges MAY contain State.

Ah, so you are using MAY to indicate conditional MUST, rather than to
indicate an option (i.e. personal choice).  That doesn't comport with RFC
2119.  I understand why the Table of Attributes has 0-1, but I'm concerned
about the use of MAY in the text, especially if we really mean a conditional
MUST.  I think we need to break out the conditions in the text, applying
MUST and MAY as appropriate.  One of the nits that has always bothered me
about RFC 2865 (and others that imitate its style) is relegating important,
normative elements of the protocol definition to footnotes to the Table of
Attributes. I think we can do better to aid readability by pulling those
elements out into text descriptions, in the relevant sections where the
concepts are discussed.

>   While most implementations require State in Access-Challenge, I have
> seen some challenge-response systems that do not require it.  Those
> systems can distinguish the initial request from the response to the
> challenge without using State to track a "session".

I would recommend adding text to that effect, as an implementation note, to
clarify when the State attribute is and is not required in an
Access-Challenge and subsequent Access-Request.

> >>    Any Access-Request that does not contain an authentication
> >>    attribute MUST contain a State attribute.  This list of
> >>    authorization parameters is not exhaustive, and may be extended
> >>    in future specifications.
> >
> > In the second sentence, did you mean "authentication" rather than
> > "authorization"?
> 
>   Maybe.  I think it's safer just to clean up the terminology.

Yes, adding wording as to what attributes require the inclusion of the State
attribute would be preferable.
 
>   What about vendor or SDO extensions?

I think we need to mention them, and describe the type of attribute that
would qualify as authentication attribute in general terms.  We should also
advise authors of VSAs that they ought to take note of this issue, and be
explicit in their documents as to whether or not a State attribute is
required to pair up with any new authentication attributes being defined.
That advice might also go in the Design Guidelines draft, BTW. 

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

Delivery-date: Tue, 21 Aug 2007 09:43:47 +0000
Date: Tue, 21 Aug 2007 11:42:49 +0200
From: Alan DeKok <[email-masked]>
To:  [email-masked]
CC:  [email-masked],  [email-masked],  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Request for review of "AAA Framework for Multicasting"

Bernard Aboba wrote:
> A request for review has been received relating to the document "AAA
> Framework for Multicasting" which is under development within the MBONED
> WG.  The document is available for inspection here:
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt

  One nit: The document formatting appears to be broken.  e.g. Page 12
is mostly blank.  This makes the document harder to read.

  I'm not sure why Section 2 defines the terms Accounting,
Authentication, and Authorization.  The document is already discussing
AAA issues, so familiarity with the three A's should be assumed.

  Perhaps the intent was to give examples of how AAA would be used in
this scenario?

  Section 4.1 is titled "Framework for multicast AAA".  This may lead
someone to conclude that the AAA protocol is being multicast.  I don't
think that's correct. The diagram in that section appears to confuse the
AAA process with the later multicast data.  My understanding is that the
request/response for AAA is unicast, and the data that is being accessed
is then sent via multicast.

  Perhaps a time-sequence diagram would be useful, to replace the
diagram in Section 4.1.

  The text in 4.1 is also awkward.  It contains a series of overlapping
conditionals for setting behavior.  The text should be expanded to
describe specific scenarios in detail from start to finish, rather than
discussing multiple scenarios simultaneously.  Adding a time-sequence
diagram for each scenario would be useful, too.

  Section 4.2 Multiple User IDs is confusing.  In AAA, each user id is
treated as a separate user.  This document should avoid the term "user
id", as it is easy to confuse with the term "user".  Instead, maybe
"access identifier" could be used.  The definition could be added to
Section 2.1.

  The relationships between the terms (1:N, M:N, etc.) should also be
included in the definitions in Section 2.1.  This lets the reader
immediately know the relationships, independent of their use-cases.  The
later discussion of use cases can then become clearer.

  Also, the document sometimes refers to "user", and sometimes to "user
id" in the same context.  (e.g. Section 4.1, "the user requests
content".)  Later, the document clarifies that the user may have
multiple user ID's.  This is confusing, because the document first talks
about users requesting content, and then switches to say no, it's not a
user, it's a user id.

  Instead, all discussion of access requests in the document should be
done using consistent terminology, such as "access identifier", rather
than "user".  In some cases, the user will map 1:1 with an access
identifier.  In others, it will be 1:N.

...
   The actual mapping rules for NSPs and CPs to map user IDs
   with the IDs in other provider domains is a matter for the
   providers.  A solution should provide an API between the
   providers to flexibly support various mapping methods.
...

  API's should be avoided.  Instead, the Chargeable-User-Identity (RFC
4372) should be used to map identifiers to users.  This is simpler,
scalable, and already deployed.

  Section 4.3:

...
   Standardization of the logs or messages to share content
   usage information is important to support a single NSP
   sharing accounting information with multiple CPs or a
   single CP receiving from multiple NSPs.
...

  The logs should not be standardized.  Instead, the contents on the AAA
messages should be standardized.

...
   This framework specifies an accounting API provided by the
   NSP and accessed by the CP to allow for sharing user-
   behavior and content-reception information between the NSP
   AAA and CP AAA. This accounting API should be configurable
   to allow the CP to request only the logging information it
   actually requires.
...

  Negotiation of the contents of accounting messages is not a normal
part of AAA.  This requirement may be unnecessary, OR it may be very
difficult to implement in existing AAA systems.

...
   When
   logging information is shared through the accounting API,
   it is important that the CP be able to match the user as
   described in the database operated by the NSP to the user
   as described in the database operated by the CP.
...

  This is already part of existing AAA systems.  I'm not sure it's
necessary to re-iterate this requirement here.

  Overall, Section 4.3 appears to re-state many common AAA requirements
for accounting.

  The document also spends a lot of time talking about "needs".  Is the
document a framework, a model, or a requirements document?  Or is it all
three?  The document should separate the model from the requirements
more explicitly.  The model should be discussed first, and then the
requirements listed second.

...
4.4 Access Control and CP selection by NSP

   When a NSP receives an access request from a user, it is
   necessary for the NSP to determine to which CP the request
   is to be directed. It is necessary for the NSP to ensure
   that it is not spoofed by an inappropriate CP or user.
...

  Doesn't AAA already do this?  What are the concrete requirements added
by this document?  Or is this document just introducing AAA concepts to
people more familiar with multicast issues?

...
4.5 API for Admission Control Information by NSP

   After authorizing a user request, the NSP may have further
   conditions for determining its admission control decision.
   MACCNT-REQ-draft defines requirements for providing the
   network capability to conduct admission control based on
   the network bandwidth usage status and bandwidth management
   policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) Such QoS
   measurement and policy mechanisms themselves are out of the
   scope of this memo.
...

  These mechanisms are defined (or are in the process of being defined)
in normal AAA.  This document could refer to AAA specifications that
meet its needs.

...
   However the NSP's AAA Server should be
   provided with an Admission control API that allows for
   interfacing so that additional conditions can be added to
   the admission control decision.
...

  I have no idea what this sentence means.  "allows for interfacing" is
extremely vague.  Also, AAA protocols do not provide for much in the way
of capability negotiation.  The authors should double-check the
requirements of this document against the functionality provided by an
existing AAA protocol such as RADIUS.  The requirements MAY be more than
existing protocols can satisfy.

  In general, AAA clients provide a set of information to the AAA server
in the access request, and the AAA server makes an accept/deny decision
based on that information.  AAA servers cannot negotiate for more
information.

  This document should define what information is available to the
participants.  It should discuss what information SHOULD be made
available by the AAA client to the AAA server, and what information MUST
be made available.

...
4.6 Access Control and Distinguishing of Users by CP

   The user ID and authentication information are forwarded
   transparently by the NSP so that the CP can distinguish the
   user, as well as authenticate and authorize the request.
...

  Does this impose requirements on the behavior of the AAA systems?  If
so, what?

...
4.7 Caching of AAA results

   An NSP should be able to cache AAA results based upon an
   agreement between the NSP and a CP.  The AAA cache would
   store information about permissions of a specific user to
   receive multicast data from specified channel(s) up to
   specified expiration date(s) and time(s).
...

  This is not a cache, and should not be referred to as a cache.
Instead, the NSP obtains a policy from the AAA server for a particular
session, and applies that policy to that session, for the duration of
the session.  The term "cache" should be deleted from the document entirely.

  Further:

...
   If such caching is implemented,
...

  The functionality described as a "cache" MUST be implemented.

...
   It should be possible for a CP to send unsolicited requests
   to the NSP to refresh or change the permissions for a user
   for specific channel(s).
...

  This is possible using existing AAA protocols.

...
   When a user is receiving multicast content and the
   permission is about to expire, the NSP may send a
   notification to the user client that his session is about
   to expire, and that he will need to re-connect. The user
   will have to reestablish a connection.
...

  In AAA terms, the user will have to re-authenticate, not re-connect.
There is no AAA "connection" between the user and the NSP.

  I have no comments at this time on Section 5.

  Overall, the document is very rough, and could use substantial
clarifications and editing.

  Recommendations:

- use consistent terminology throughout the document
- expand on the examples
- clearly separate model and requirements
- discuss model before requirements
- clarify requirements
- the authors need MUCH more familiarity with AAA systems
- the requirements need to be validated against AAA functionality

  Alan DeKok.

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

Delivery-date: Tue, 21 Aug 2007 08:28:06 +0000
Date: Tue, 21 Aug 2007 10:27:43 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes

David B. Nelson wrote:
> I don't find the text with the words "authorization parameters" in RFC 2865.
> Perhaps this is a misquote?  Where did this text come from?  I don't find it
> in 2865 or Issues & Fixes -05.  RFC 2865 seems to have it right.

  It was one of the suggested re-wordings I posted to the list.

  Alan DeKok.

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

Delivery-date: Tue, 21 Aug 2007 08:27:31 +0000
Date: Tue, 21 Aug 2007 10:27:05 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>,  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes  -- Call-Check.

David B. Nelson wrote:
> Based on the discussion so far, acknowledging that Call-Check is
> pre-authentication (not in the 802.11i key-caching sense, but in a
> pre-screening sense, you don't have my credentials yet), I think that even
> MAY is stretching the point.  Can anyone describe a use case for Call-Check
> in which the NAS would have a State attribute from an existing user session
> or ongoing authentication sequence?

  Nope.

  Maybe we want to change that to "... Call Check MAY NOT contain a
State attribute".  This permits them to (magically) have one if they so
desire.  It permits them to not have one in real-life implementations.

  Alan DeKok.

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

Delivery-date: Tue, 21 Aug 2007 08:22:36 +0000
Date: Tue, 21 Aug 2007 10:21:42 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes

David B. Nelson wrote:
> Alan DeKok writes...
> 
>>   The Call-Check MAY need to be tied to a previous authentication
>> request.  This can be done via the State attribute being sent in an
>> Access-Accept, and used in a later Access-Request with Call Check.
> 
> Can you suggest a specific use case where this may happen?   My
> understanding of the use of Call-Check is that it always precedes a formal
> authentication.

  Hmm... yes.  RFC 2865 has no requirements on Access-Requests with Call
Check containing State, so I think that requirement can be removed from
the document.

>>    We extend this definition to say that Access-Requests which are part
>>    of an ongoing authentication process MAY contain a State attribute.
> 
> So, this sentence really confuses me.  Maybe I'm taking it out of context,
> but my understanding is that an Access-Request that is part of an ongoing
> authentication process MUST contain a State Attribute.  This has been the
> case since the State attribute was defined.  Why are we changing it to MAY?

  We're not.  RFC 2865, Table 5.44 says State is "0-1" in
Access-Request.  Note 1 says that Access-Requests contain User-Password,
CHAP-Password, or State.  Section 2 says that Access-Challenges MAY
contain State.

  While most implementations require State in Access-Challenge, I have
seen some challenge-response systems that do not require it.  Those
systems can distinguish the initial request from the response to the
challenge without using State to track a "session".

>>    Access-Request packets that contain a Service-Type attribute with
>>    value Call Check (10) or Authorize Only (17) MUST contain a State
>>    attribute.
> 
> I would suggest MUST for Authorize-Only and MAY for Call-Check.

  OK.

>>    Any Access-Request that does not contain an authentication 
>>    attribute MUST contain a State attribute.  This list of 
>>    authorization parameters is not exhaustive, and may be extended
>>    in future specifications.
> 
> In the second sentence, did you mean "authentication" rather than
> "authorization"?

  Maybe.  I think it's safer just to clean up the terminology.

> As I indicated in a separate message, I think we need to include a formal
> definition (e.g. by list) of those attributes we consider to be
> authentication attributes.

  What about vendor or SDO extensions?

> We are debating whether unknown values of other attributes, or unknown
> attribute types, ought to be treated similarly.  The suggestion is that a
> NAS MAY choose to treat them similarly, i.e. treat unknown attribute types,
> or unknown values of known attribute types as an Access-Reject based on
> locally configured policy, with the default being to silently ignore them,
> for backwards compatibility.  NASes MAY implement this local policy feature,
> and it is RECOMMENDED for any new implementations or significant revisions.
> We ought not to deprecate any existing implementations that don't have this
> local policy feature, however.

  Yes.

  Alan DeKok.

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

Delivery-date: Mon, 20 Aug 2007 21:00:14 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for Review: "Issues and Fixes" changes
Date: Mon, 20 Aug 2007 17:00:07 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> > >    Any Access-Request that does not contain an authentication
> > >    attribute MUST contain a State attribute.  This list of
> > >    authorization parameters is not exhaustive, and may be 
> > >    extended in future specifications.
> >
> >In the second sentence, did you mean "authentication" rather than
> >"authorization"?
> 
> This quote came from RFC 2865, so I'm not sure what it means. 
> That's for us to figure out, I guess :)

RFC 2865, Section 4.1 reads, in part:

      An Access-Request MUST contain either a User-Password or a CHAP-
      Password or a State.  An Access-Request MUST NOT contain both a
      User-Password and a CHAP-Password.  If future extensions allow
      other kinds of authentication information to be conveyed, the
      attribute for that can be used in an Access-Request instead of
      User-Password or CHAP-Password.

Note that in this case the word is "authentication".

I don't find the text with the words "authorization parameters" in RFC 2865.
Perhaps this is a misquote?  Where did this text come from?  I don't find it
in 2865 or Issues & Fixes -05.  RFC 2865 seems to have it right.

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

Delivery-date: Mon, 20 Aug 2007 20:34:30 +0000
Subject: RE: Request for Review: "Issues and Fixes" changes -- Call-Check.
Date: Mon, 20 Aug 2007 16:34:15 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

Bernard wrote:

If it breaks existing deployments, I'd like to know where they got the
State Attribute from :)

[Avi] The RADIUS lords work in mysterious ways sometimes.

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

Delivery-date: Mon, 20 Aug 2007 20:30:18 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for Review: "Issues and Fixes" changes  -- Call-Check.
Date: Mon, 20 Aug 2007 16:30:26 -0400
Organization: Elbrys Networks, Inc.

Avi Lior writes...

> > I would suggest MUST for Authorize-Only and MAY for Call-Check.
> 
> [Avi] I agree with David.  I am not buying even the MAY for Call-
> Check. But I can live with it.

Based on the discussion so far, acknowledging that Call-Check is
pre-authentication (not in the 802.11i key-caching sense, but in a
pre-screening sense, you don't have my credentials yet), I think that even
MAY is stretching the point.  Can anyone describe a use case for Call-Check
in which the NAS would have a State attribute from an existing user session
or ongoing authentication sequence?

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

Delivery-date: Mon, 20 Aug 2007 20:26:47 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: Request for Review: "Issues and Fixes" changes -- Call-Check.
Date: Mon, 20 Aug 2007 13:26:26 -0700

>[Avi] I agree with David.  Call-Check is Pre-authentication, there is no 
>prior user-session.

Right.  This seems like a mistake in RFC 2865.  We probably should 
explicitly address this in the document.

>[Avi] I think an Access-Request with Service-Type set to Call-Check MUST
>NOT contain State.  However, making that restriction may break existing
>deployements -- Issues and Fixes should not break existing deployements.
>
>Snip....

If it breaks existing deployments, I'd like to know where they got the State 
Attribute from :)

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

Delivery-date: Mon, 20 Aug 2007 20:23:54 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for Review: "Issues and Fixes" changes
Date: Mon, 20 Aug 2007 16:23:56 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> If I read RFC 2865 correctly, it would seem that an Access-Request
> containing Service-Type="Call-Check" MUST contain a State attribute,
> since this won't contain User-Password, CHAP-Password or any other
> "authentication" attribute".  Now, I'm not sure I understand where
> the NAS is supposed to get the State Attribute from...

Indeed.  This brings to mind one of my favorite sayings regarding software:
"How did this ever work?".

My understanding of the use case for a Access-Request with a Service-Type of
Call-Check is that the Calling-Station-ID (and possibly the
Called-Station-ID) provides the identity of the remote user for the purpose
of a pre-screening authentication, originally used to decide whether the NAS
should accept the call set-up on an ISDN or DSL link, terminating in a modem
pool.  The idea was to avoid tying up a modem, if the user wasn't one of
your authorized customers.  In this use case there can be no valid source of
the State attribute in the NAS.

> ...but that does seem to be what RFC 2865 is saying.

Well, I wonder...
 
> > >    Any Access-Request that does not contain an authentication
> > >    attribute MUST contain a State attribute.  This list of
> > >    authorization parameters is not exhaustive, and may be extended
> > >    in future specifications.
> >
> >In the second sentence, did you mean "authentication" rather than
> >"authorization"?
> 
> This quote came from RFC 2865, so I'm not sure what it means.  
> That's for us to figure out, I guess :)

I'll look at this again, in context, but taken out of context it does seem
confusing.

> That is already in RFC 2865, I believe.

Yes, and we think it's correct!  :-)

> BTW, I believe that there may be some other hints on this in
> RFC 2869. For example, in the ARAP section there is some discussion
> of how NASes that don't support ARAP are supposed to behave.

OK, we can look at that text for any possible guidance.

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

Delivery-date: Mon, 20 Aug 2007 20:16:18 +0000
Subject: RE: Request for Review: "Issues and Fixes" changes  -- Call-Check.
Date: Mon, 20 Aug 2007 16:18:20 -0400
From: "Avi Lior" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>

[Avi] I agree with David.  Call-Check is Pre-authentication, there is no
prior user-session. =20

[Avi] I think an Access-Request with Service-Type set to Call-Check MUST
NOT contain State.  However, making that restriction may break existing
deployements -- Issues and Fixes should not break existing deployements.

Snip....

>    Access-Request packets that contain a Service-Type attribute with
>    value Call Check (10) or Authorize Only (17) MUST contain a State
>    attribute.

I would suggest MUST for Authorize-Only and MAY for Call-Check.

[Avi] I agree with David.  I am not buying even the MAY for Call-Check.
But I can live with it.

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

Delivery-date: Mon, 20 Aug 2007 20:16:10 +0000
Subject: RE: review of "Issues and Fixes"
Date: Mon, 20 Aug 2007 16:18:19 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Well, I think issues and fixes should define the term authentication
attribute.

Authentication attributes contain the information required to
authenticate the user.  Examples are: User-Password, CHAP-Password,
ARAP-Password and EAP-Message.

Regarding Message-Authenticator  -- based on your response, I don't
think that Message-Authenticator is an authentication attribute because
it does not contian information required to authenticate the user.
Message-Authenticator purpose is to protect the packet.

I think that "Other kinds of Authentication Information" must refer to
other kinds of user authentication information.

But if I am wrong, then this is another grey area that needs to be
plugged up.

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]=20
Sent: Monday, August 20, 2007 10:43 AM
To: Avi Lior
Cc: [email-masked]
Subject: RE: review of "Issues and Fixes"

>  As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
>    contain a State attribute.  We extend that definition here, to say
>    that Access-Request packets that contain an authentication
attribute
>    or a Service-Type attribute with the value Call Check (10) MAY
>    contain a State attribute.  Access-Request packets not matching the
>    above description MUST contain a State attribute.
>
>The term authentication attribute is not defined.  What is an=20
>authentication attribute?  Is Message-Authenticator an authetication=20
>attribute?

RFC 2865, Section 4.1 says:

"     An Access-Request MUST contain either a User-Password or a CHAP-
      Password or a State.  An Access-Request MUST NOT contain both a
      User-Password and a CHAP-Password.  If future extensions allow
      other kinds of authentication information to be conveyed, the
      attribute for that can be used in an Access-Request instead of
      User-Password or CHAP-Password."

RFC 2869 Section 2.2 says:

"   Only one of User-Password, CHAP-Password, or ARAP-Password needs to
   be present in an Access-Request, or one or more EAP-Messages.

   If the RADIUS server does not support ARAP it SHOULD return an
   Access-Reject to the NAS."

Based on this, User-Password, CHAP-Password, EAP-Message and
ARAP-Password=20
should fall in the list of authentication attributes.   Based on RFC
4590, a=20
Digest-Response Attribute also qualifies.  Not sure whether
Message-Authenticator falls into "other kinds of authentication
information."

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

Delivery-date: Mon, 20 Aug 2007 20:11:05 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Request for Review: "Issues and Fixes" changes
Date: Mon, 20 Aug 2007 13:10:05 -0700

>I would suggest MUST for Authorize-Only and MAY for Call-Check.

If I read RFC 2865 correctly, it would seem that an Access-Request 
containing Service-Type="Call-Check" MUST contain a State ttribute, since 
this won't contain User-Password, CHAP-Password or any other "authentication 
attribute".  Now, I'm not sure I understand where the NAS is supposed to get 
the State Attribute from, but that does seem to be what RFC 2865 is saying.

> >    Any Access-Request that does not contain an authentication
> >    attribute MUST contain a State attribute.  This list of
> >    authorization parameters is not exhaustive, and may be extended
> >    in future specifications.
>
>In the second sentence, did you mean "authentication" rather than
>"authorization"?

This quote came from RFC 2865, so I'm not sure what it means.  That's for us 
to figure out, I guess :)

>I think you meant "new service".  I agree.
>
>We have previously agreed that unknown values of the Service-Type attribute
>MUST be treated as an Access-Reject.  That much is clear.

That is already in RFC 2865, I believe.

>We are debating whether unknown values of other attributes, or unknown
>attribute types, ought to be treated similarly.  The suggestion is that a
>NAS MAY choose to treat them similarly, i.e. treat unknown attribute types,
>or unknown values of known attribute types as an Access-Reject based on
>locally configured policy, with the default being to silently ignore them,
>for backwards compatibility.  NASes MAY implement this local policy 
>feature,
>and it is RECOMMENDED for any new implementations or significant revisions.
>We ought not to deprecate any existing implementations that don't have this
>local policy feature, however.

BTW, I believe that there may be some other hints on this in RFC 2869.  For 
example, in the ARAP section there is some discussion of how NASes that 
don't support ARAP are supposed to behave.

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

Delivery-date: Mon, 20 Aug 2007 16:08:27 +0000
Date: Mon, 20 Aug 2007 18:07:59 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes

Bernard Aboba wrote:
> I think we 'd also need to include ARAP & Digest authentication, no?

  Yes.

> Think this is "Call Check".   I'm curious whether current
> implementations of Call Check satisfy this or not.

  That was a typo, sorry.  I don't know of implementations that do this...

>>   This also adds an informative reference to RFC 3576.
> 
> The reference should probably be to [RFC3576bis].

  OK... along with RFC4590bis for Digest-Response.

  Alan DeKok.

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

Delivery-date: Mon, 20 Aug 2007 16:04:03 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: review of "Issues and Fixes"
Date: Mon, 20 Aug 2007 12:04:00 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   I would prefer to avoid creating or using a new term.

The perhaps we should use the definition of the "term" instead, as an
in-line macro expansion, as it were.

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

Delivery-date: Mon, 20 Aug 2007 16:00:29 +0000
Date: Mon, 20 Aug 2007 18:00:10 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: review of "Issues and Fixes"

David B. Nelson wrote:
> If we are to user the term "authentication attribute" as words-of-art, then
> I think we should include a definition, along the lines you have just
> suggested.

  I would prefer to avoid creating or using a new term.

  Alan DeKok.

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

Delivery-date: Mon, 20 Aug 2007 15:59:15 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Request for Review: "Issues and Fixes" changes
Date: Mon, 20 Aug 2007 11:59:09 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   The Call-Check MAY need to be tied to a previous authentication
> request.  This can be done via the State attribute being sent in an
> Access-Accept, and used in a later Access-Request with Call Check.

Can you suggest a specific use case where this may happen?   My
understanding of the use of Call-Check is that it always precedes a formal
authentication.

>    We extend this definition to say that Access-Requests which are part
>    of an ongoing authentication process MAY contain a State attribute.

So, this sentence really confuses me.  Maybe I'm taking it out of context,
but my understanding is that an Access-Request that is part of an ongoing
authentication process MUST contain a State Attribute.  This has been the
case since the State attribute was defined.  Why are we changing it to MAY?

>    Access-Request packets that contain a Service-Type attribute with
>    value Call Check (10) or Authorize Only (17) MUST contain a State
>    attribute.

I would suggest MUST for Authorize-Only and MAY for Call-Check.

>    Any Access-Request that does not contain an authentication 
>    attribute MUST contain a State attribute.  This list of 
>    authorization parameters is not exhaustive, and may be extended
>    in future specifications.

In the second sentence, did you mean "authentication" rather than
"authorization"?

As I indicated in a separate message, I think we need to include a formal
definition (e.g. by list) of those attributes we consider to be
authentication attributes.
 
>   I would simply say that the algorithms apply to any client originating
> RADIUS packets, including Disconnect-Requests.  This covers the Dynamic
> Authorization Client, without adding a dependency on RFC 3576bis.
> Suggested text:
> 
>    The following algorithms apply to any client that originates RADIUS
>    packets, including but not limited to Access-Request,
>    Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576].
> 
>   This also adds an informative reference to RFC 3576.

That seems reasonable.

>   Sure.  It's RECOMMENDED.  We can simply say "... the RECOMMENDED
> retransmission algorithm below is..."
> 
> [ MRD and MRC]
> > This could have some unforeseen (and potentially adverse) impacts on
> > RADIUS accounting.  Today, some RADIUS accounting clients continue to
> > retransmit for long periods of time, intentionally, in order to improve
> > reliability.  If there is an upper bound on the number of times a sender
> > may retransmit an accounting message, then accounting messages could be
> > lost in situations where today they would be delivered.  So I think this
> > needs to be changed.
> 
>   We can add a note:
> 
>    For Accounting-Request packets, the default values for MRC, MRD,
>    and MRT SHOULD be zero.  These settings will enable a RADIUS client
>    to continue sending accounting requests to a RADIUS server until
>    the request is acknowledged.  If any of MRC, MRD, or MRT are non-
>    zero, then the accounting information could potentially be
>    discarded without being recorded.

That also seems reasonable.

> > Section 2.5
> >
> > The issue that this section is attempting to address is the 
> > seeming contradiction between [RFC2865] Section 1.1 which states:
> ...
> > and [RFC2865] Section 5 which states:
> ...
> > As I recall, the conclusion was that the advice of Section 1.1 
> > applies to known attributes, so that if a NAS receives an attribute
> > that is known and represents a service, but is not implemented, 
> > it is treated as an Access-Reject.  Whereas if the attribute is not
> > known, then it MAY be ignored.
> 
>   It's difficult to know if a new attribute defines a new server.

I think you meant "new service".  I agree.

We have previously agreed that unknown values of the Service-Type attribute
MUST be treated as an Access-Reject.  That much is clear.

We are debating whether unknown values of other attributes, or unknown
attribute types, ought to be treated similarly.  The suggestion is that a
NAS MAY choose to treat them similarly, i.e. treat unknown attribute types,
or unknown values of known attribute types as an Access-Reject based on
locally configured policy, with the default being to silently ignore them,
for backwards compatibility.  NASes MAY implement this local policy feature,
and it is RECOMMENDED for any new implementations or significant revisions.
We ought not to deprecate any existing implementations that don't have this
local policy feature, however.

> > The question was then what the behavior is for a NAS encountering
> > an unknown attribute.  Given the MAY in Section 5, behavior can 
> > only be recommended, not mandated, because of backward 
> > compatibility.

Agreed.

> > [BA] My recommendation would be to add a clarification of the 
> > meaning of Section 1.1:
> >...  On receiving an Access-Accept including an attribute of 
> > known Type for an unimplemented service, a RADIUS client MUST 
> > treat it as an Access-Reject, as directed in [RFC2865] Section
> > 1.1.
> 
>   It's difficult to know that an unknown type is for an 
> unimplemented service.  But I think I know what you mean.

We know that an unknown value of the Service-Type attribute is an
unimplemented service, by definition.

For unknown attribute types, or unknown value of known attribute types, the
discussion above applies.

> > I think what we are trying to say here is that existing 
> > implementations that ignore unknown attributes should probably 
> > not change to treating them as an Access-Reject by default, or 
> > else on upgrading the NAS, the users could see an unexpected 
> > change in behavior.

Not by default, anyway.  I think it is a good idea to add the capability of
treating unknown attribute type codes or unknown values of known attributes
as Access-Reject as an administrator manageable option.  The default is to
ignore them, for backwards compatibility and maximum interoperability with
RADIUS extensions.  The ability to treat these "unknown" attributes as
Access-Reject for maximum security should be a non-default,
administrator-selectable option.

> > In order to avoid introducing changes in default behavior, 
> > existing implementations that do not obey this recommendation 
> > should make the behavior configurable, with the legacy behavior
> > being enabled by default. A configuration flag such as "treat 
> > unknown attributes as reject" can be exposed to the system 
> > administrator.  If the flag is set to true, then Access-Accepts 
> > containing unknown attributes are treated as Access-Rejects.  If 
> > the flag is set to false, then unknown attributes in Access-
> > Accepts are be silently ignored.

Agreed.

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

Delivery-date: Mon, 20 Aug 2007 15:26:00 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: review of "Issues and Fixes"
Date: Mon, 20 Aug 2007 11:25:18 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> >The term authentication attribute is not defined.  What is an
> >authentication attribute?  Is Message-Authenticator an 
> >authentication attribute?

<snip>

> Based on this, User-Password, CHAP-Password, EAP-Message and
> ARAP-Password should fall in the list of authentication attributes.
> Based on RFC 4590, a Digest-Response Attribute also qualifies.  
> Not sure whether Message-Authenticator falls into "other kinds of 
> authentication information."

If we are to user the term "authentication attribute" as words-of-art, then
I think we should include a definition, along the lines you have just
suggested.

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

Delivery-date: Mon, 20 Aug 2007 14:43:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: review of "Issues and Fixes"
Date: Mon, 20 Aug 2007 07:43:01 -0700

>  As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
>    contain a State attribute.  We extend that definition here, to say
>    that Access-Request packets that contain an authentication attribute
>    or a Service-Type attribute with the value Call Check (10) MAY
>    contain a State attribute.  Access-Request packets not matching the
>    above description MUST contain a State attribute.
>
>The term authentication attribute is not defined.  What is an
>authentication attribute?  Is Message-Authenticator an authetication
>attribute?

RFC 2865, Section 4.1 says:

"     An Access-Request MUST contain either a User-Password or a CHAP-
      Password or a State.  An Access-Request MUST NOT contain both a
      User-Password and a CHAP-Password.  If future extensions allow
      other kinds of authentication information to be conveyed, the
      attribute for that can be used in an Access-Request instead of
      User-Password or CHAP-Password."

RFC 2869 Section 2.2 says:

"   Only one of User-Password, CHAP-Password, or ARAP-Password needs to
   be present in an Access-Request, or one or more EAP-Messages.

   If the RADIUS server does not support ARAP it SHOULD return an
   Access-Reject to the NAS."

Based on this, User-Password, CHAP-Password, EAP-Message and ARAP-Password 
should fall in the list of authentication attributes.   Based on RFC 4590, a 
Digest-Response Attribute also qualifies.  Not sure whether 
Message-Authenticator falls into "other kinds of authentication 
information."

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

Delivery-date: Mon, 20 Aug 2007 14:22:35 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Request for Review: "Issues and Fixes" changes
Date: Mon, 20 Aug 2007 07:22:02 -0700

>    For example, an Access-Request containing one of the authentication
>    attributes User-Password or CHAP-Password MAY contain a State
>    attribute.  Other attributes intended to carry authentication
>    information include EAP-Message, though this list is not exhaustive,
>    and may be extended in future specifications.

I think we 'd also need to include ARAP & Digest authentication, no?

>    Access-Request packets that contain a Service-Type attribute with
>    value Call Chack (10) or Authorize Only (17) MUST contain a State
>    attribute.  Any Access-Request that does not contain an
>    authentication attribute MUST contain a State attribute.  This list
>    of authorization parameters is not exhaustive, and may be extended in
>    future specifications.

Think this is "Call Check".   I'm curious whether current implementations of 
Call Check satisfy this or not.

>    The following algorithms apply to any client that originates RADIUS
>    packets, including but not limited to Access-Request,
>    Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576].
>
>   This also adds an informative reference to RFC 3576.

The reference should probably be to [RFC3576bis].

>   We can add a note:
>
>    For Accounting-Request packets, the default values for MRC, MRD,
>    and MRT SHOULD be zero.  These settings will enable a RADIUS client
>    to continue sending accounting requests to a RADIUS server until
>    the request is acknowledged.  If any of MRC, MRD, or MRT are non-
>    zero, then the accounting information could potentially be
>    discarded without being recorded.

This is better, thanks.

>It's difficult to know that an unknown type is for an unimplemented
>service.  But I think I know what you mean.

Actually, I meant a known type;  for an unknown type, I agree.

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

Delivery-date: Mon, 20 Aug 2007 12:08:51 +0000
Date: Mon, 20 Aug 2007 14:08:27 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Request for Review: "Issues and Fixes" changes

Bernard Aboba wrote:
> Does it make sense to include a State attribute in an Access-Request with
> a Service-Type attribute with value Call Check (10)?  Typically in these
> cases there is no state to encode.

  The Call-Check MAY need to be tied to a previous authentication
request.  This can be done via the State attribute being sent in an
Access-Accept, and used in a later Access-Request with Call Check.

  Suggested text:

...
   As defined in [RFC2865] Table 5.44, Access-Request packets MAY
   contain a State attribute.  The table does not qualify this
   statement, while the text in Section 5.24 says

      This Attribute is available to be sent by the server to the client
      in an Access-Accept that also includes a Termination-Action
      Attribute with the value of RADIUS-Request.  If the NAS performs
      the Termination-Action by sending a new Access-Request upon
      termination of the current session, it MUST include the State
      attribute unchanged in that Access-Request.

   We extend this definition to say that Access-Requests which are part
   of an ongoing authentication process MAY contain a State attribute.
   Access-Requests which are intended to perform authorization checks
   MUST contain a State attribute.  This last requirement often means
   that an Access-Accept will contain a State attribute, so that a later
   authorization check may use that State to tie the authorization check
   to a previous authentication request.

   For example, an Access-Request containing one of the authentication
   attributes User-Password or CHAP-Password MAY contain a State
   attribute.  Other attributes intended to carry authentication
   information include EAP-Message, though this list is not exhaustive,
   and may be extended in future specifications.

   Access-Request packets that contain a Service-Type attribute with
   value Call Chack (10) or Authorize Only (17) MUST contain a State
   attribute.  Any Access-Request that does not contain an
   authentication attribute MUST contain a State attribute.  This list
   of authorization parameters is not exhaustive, and may be extended in
   future specifications.
...

> Section 2.2.1
> 
> I think this section needs to note that the suggested algorithms apply
> not only to a RADIUS client, but also to a Dynamic Authorization Client,
> defined in RFC 3576bis.  Either that, or the algorithm text needs to be
> transplanted into RFC 3576bis.

  I would simply say that the algorithms apply to any client originating
RADIUS packets, including Disconnect-Requests.  This covers the Dynamic
Authorization Client, without adding a dependency on RFC 3576bis.
Suggested text:

   The following algorithms apply to any client that originates RADIUS
   packets, including but not limited to Access-Request,
   Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576].

  This also adds an informative reference to RFC 3576.

> Is the retransmission algorithm OPTIONAL or RECOMMENDED?  The first
> paragraph seems to suggest that only congestive backoff is RECOMMENDED,
> and that the rest of the text is non-normative.  Is that what is
> intended?  I'd suggest that we say something like "A potential
> retransmission algorithm is included below" to make that that clear, if
> that is what is meant.

  Sure.  It's RECOMMENDED.  We can simply say "... the RECOMMENDED
retransmission algorithm below is..."

[ MRD and MRC]
> This could have some unforseen (and potentially adverse) impacts on
> RADIUS accounting.  Today, some RADIUS accounting clients continue to
> retransmit for long periods of time, intentionally, in order to improve
> reliability.  If there is an upper bound on the number of times a sender
> may retransmit an accounting message, then accounting messages could be
> lost in situations where today they would be delivered.  So I think this
> needs to be changed.

  We can add a note:

   For Accounting-Request packets, the default values for MRC, MRD,
   and MRT SHOULD be zero.  These settings will enable a RADIUS client
   to continue sending accounting requests to a RADIUS server until
   the request is acknowledged.  If any of MRC, MRD, or MRT are non-
   zero, then the accounting information could potentially be
   discarded without being recorded.

> Section 2.5
> 
> The issue that this section is attempting to address is the seeming
> contradiction between
> [RFC2865] Section 1.1 which states:
...
> and [RFC2865] Section 5 which states:
...
> As I recall, the conclusion was that the advice of Section 1.1 applies
> to known attributes, so that if a NAS receives an attribute that is
> known and represents a service, but is not implemented, it is treated as
> an Access-Reject.  Whereas if the attribute is not known, then it MAY be
> ignored.

  It's difficult to know if a new attribute defines a new server.

> The question was then what the behavior is for a NAS encountering an
> unknown attribute.  Given the MAY in Section 5,  behavior can only be
> recommended, not mandated, because of backward compatibility.

  Yes.  The text in 2.5 use SHOULD, not MUST.

>   It is possible for either a standard attribute or VSA to represent a
>   request for an unavailable service.  However, where the Type or
>   Vendor-ID is unknown, a RADIUS client will not know whether the
>   attribute defines a service or not.
> 
> [BA] Actually the problem could also arise if the Vendor-ID is known,
> but the Vendor Type is not, right?

  Yes.  We can update it "Type, Vendor-Id, or Vendor-Type".

> [BA] My recommendation would be to add a clarification of the meaning of
> Section 1.1:
>...  On receiving an
> Access-Accept including an attribute of known Type for an unimplemented
> service, a RADIUS client MUST treat it as an Access-Reject, as directed
> in [RFC2865] Section 1.1. 

  It's difficult to know that an unknown type is for an unimplemented
service.  But I think I know what you mean.

> I think what we are trying to say here is that existing implementations
> that ignore unknown attributes should probably not change to treating
> them as an Access-Reject by default, or else on upgrading the NAS, the
> users could see an unexpected change in behavior.  In this situation,
> configuration would be helpful, but the legacy behavior should be the
> default, probably.  However, where the existing implementation already
> implements the recommended behavior, there is no point in introducing
> configuration.  Here is a recommended rewrite:

  OK.

> In order to avoid introducing changes in default behavior, existing
> implementations that do not obey this recommendation should make the
> behavior configurable, with the legacy behavior being enabled by
> default. A configuration flag such as "treat unknown attributes as
> reject" can be exposed to the system administrator.  If the flag is set
> to true, then Access-Accepts containing unknown attributes are treated
> as Access-Rejects.  If the flag is set to false, then unknown
> attributes in Access-Accepts are be silently ignored.

  Looks good to me.

  Alan DeKok.

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

Delivery-date: Mon, 20 Aug 2007 12:08:06 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: FW: review of "Issues and Fixes"
Date: Mon, 20 Aug 2007 08:06:51 -0400

Forwarding to the list...

From: Avi Lior [mailto:[email-masked]]=20
Sent: Monday, August 20, 2007 8:03 AM
To: [email-masked]; [email-masked]; Bernard Aboba
Subject: review of "Issues and Fixes"
=A0
First comment:
=A0
In the following text:
=A0
=A0As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
=A0=A0 contain a State attribute.=A0 We extend that definition here, to =
say
=A0=A0 that Access-Request packets that contain an authentication =
attribute
=A0=A0 or a Service-Type attribute with the value Call Check (10) MAY
=A0=A0 contain a State attribute.=A0 Access-Request packets not matching =
the
=A0=A0 above description MUST contain a State attribute.
The term authentication attribute is not defined.=A0 What is an =
authentication
attribute?=A0 Is Message-Authenticator an authetication attribute.
=A0
Second Comment:
=A0
The State attribute is needed to be included in an Access-Request with
Service-Type set to "Authorize-Only".
=A0
Currently it is not clear how the State attribute is available at the =
NAS.=A0
In the case of COA we are very explicit.=A0 Currently 2865 states:
=A0
This Attribute(State) is available to be sent by the server to the =
client
=A0=A0=A0=A0=A0 in an Access-Accept that also includes a =
Termination-Action
=A0=A0=A0=A0=A0 Attribute with the value of RADIUS-Request.=A0=20
=A0
The assumption here is that Termination-Action can trigger another
Access-Request and thus we want to use the State attribute to link them
together.=A0 However, today a NAS can send an Access-Request with =
Service-Type
Authorize-Only for other reasons.=A0=A0 Thus it would be helpful to =
allow a
State attribute to be included in an Access-Accept period.
=A0
I would suggest the following text or something similar for Issues and
Fixes.
=A0
A RADIUS server MAY include the State attribute in an Access-Accept.=A0 =
A
RADIUS server MUST include the State attribute in an Access-Accept if it =
is
anticipated that the RADIUS client will generate an Access-Request with
Service-Type set to "Authorize-Only".
=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Avi =
Lior=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20
Bridgewater Systems Corporation=20
Phone :=A0 +1 (613) 591-9104 x6417
Cell=A0=A0=A0=A0:=A0 +1 (613)=A0796-4183
E-mail : mailto:[email-masked]
www.bridgewatersystems.com=A0
=A0

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

Delivery-date: Sat, 18 Aug 2007 22:00:18 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Update on RFC 4590bis
Date: Sat, 18 Aug 2007 15:00:05 -0700

As noted on July 8, 2007, the publication of RFC 4590bis was approved by the 
IESG:
http://ops.ietf.org/lists/radiusext/2007/msg00501.html

In the process of review of Appendix A, it was noted that the addresses used 
were not compatible with the address space allocated for example usage.  As 
a result, an RFC Editor Note is required.  The corrected text required for 
Appendix A is enclosed below as prepared by Wolfgang:

-----Ursprüngliche Nachricht-----
Von: Beck, Wolfgang
Gesendet: Montag, 9. Juli 2007 11:37
An: 'Bernard Aboba'
Betreff: AW: idnits warnings in rfc4590bis

Bernard,

here's a corrected version.

Wolfgang
-----------------------------------

   This is an example selected from the traffic between a softphone (A),
   a Proxy Server (B), and an example.com RADIUS server (C).  The
   communication between the Proxy Server and a SIP Public Switched
   Telephone Network (PSTN) gateway is omitted for brevity.  The SIP
   messages are not shown completely.

   The password of user '12345678' is 'secret'. The shared secret
   between RADIUS client and server is 'secret'. To ease testing,
   only the last byte of the RADIUS authenticator changes between
   requests. In a real implementation, this would be a serious flaw.

   A->B

      INVITE sip:[email-masked] SIP/2.0
      From: <sip:[email-masked]>
      To: <sip:[email-masked]>

   B->A

      SIP/2.0 100 Trying

   B->C

      Code = Access-Request (1)
      Packet identifier = 0x7c (124)
      Length = 97
      Authenticator = F5E55840E324AA49D216D9DBD069807C
      NAS-IP-Address = 192.0.2.38
      NAS-Port = 5
      User-Name = 12345678
      Digest-Method = INVITE
      Digest-URI = sip:[email-masked]
      Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B

   C->B

      Code = Access-challenge (11)
      Packet identifier = 0x7c (124)
      Length = 72
      Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D
      Digest-Nonce = 3bada1a0
      Digest-Realm = example.com
      Digest-Qop = auth
      Digest-Algorithm = MD5
      Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3

   B->A

      SIP/2.0 407 Proxy Authentication Required
      Proxy-Authenticate: Digest realm="example.com"
           ,nonce="3bada1a0",qop=auth,algorithm=MD5
      Content-Length: 0

   A->B

      ACK sip:[email-masked] SIP/2.0

   A->B

      INVITE sip:[email-masked] SIP/2.0
      Proxy-Authorization: Digest algorithm="md5",nonce="3bada1a0"
           ,realm="example.com"
           ,response="7679b84a560835846ec553174dbabb69"
           ,uri="sip:[email-masked]",username="12345678"
           ,qop=auth,algorithm=MD5
           ,cnonce="56593a80,nc="00000001"

      From: <sip:[email-masked]>
      To: <sip:[email-masked]>

   B->C

      Code = Access-Request (1)
      Packet identifier = 0x7d (125)
      Length = 221
      Authenticator = F5E55840E324AA49D216D9DBD069807D
      NAS-IP-Address = 192.0.2.38
      NAS-Port = 5
      User-Name = 12345678
      Digest-Method = INVITE
      Digest-URI = sip:[email-masked]
      Digest-Realm = example.com
      Digest-Qop = auth
      Digest-Algorithm = MD5
      Digest-CNonce = 56593a80
      Digest-Nonce = 3bada1a0
      Digest-Nonce-Count = 00000001
      Digest-Response = 7679b84a560835846ec553174dbabb69
      Digest-Username = 12345678
      SIP-AOR = sip:[email-masked]
      Message-Authenticator = BD037498E8385878A46ECF4D5F8D2B48

   C->B

      Code = Access-Accept (2)
      Packet identifier = 0x7d (125)
      Length = 72
      Authenticator = 36E1201AD4377664E720184CE7B3D8C6
      Digest-Response-Auth = 3792d3109224eb67213659e2d789f10d
      Message-Authenticator = 9B79B410CEBD335176DAEB24735DCF64

   B->A

      SIP/2.0 180 Ringing

   B->A

      SIP/2.0 200 OK

   A->B

      ACK sip:[email-masked] SIP/2.0

   A second example shows the traffic between a web browser (A), web
   server (B), and a RADIUS server (C).

   A->B

      GET /index.html HTTP/1.1

   B->C
      Code = Access-Request (1)
      Packet identifier = 0x7e (126)
      Length = 68
      Authenticator = F5E55840E324AA49D216D9DBD069807E
      NAS-IP-Address = 192.0.2.38
      NAS-Port = 5
      Digest-Method = GET
      Digest-URI = /index.html
      Message-Authenticator = 690BFC95E88DF3B185F15CD78E469992

   C->B

      Code = Access-challenge (11)
      Packet identifier = 0x7e (126)
      Length = 72
      Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E
      Digest-Nonce = a3086ac8
      Digest-Realm = example.com
      Digest-Qop = auth
      Digest-Algorithm = MD5
      Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A

   B->A

      HTTP/1.1 401 Authentication Required
      WWW-Authenticate: Digest realm="example.com",
          nonce="a3086ac8",qop=auth,algorithm=MD5
      Content-Length: 0

   A->B

      GET /index.html HTTP/1.1
      Authorization: Digest algorithm=MD5,qop=auth,nonce="a3086ac8"
           ,nc="00000001",cnonce="56593a78"
           ,realm="example.com"
           ,response="ba623217b5ec024d30c4aaef9d8494de"
           ,uri="/index.html",username="12345678"

   B->C

      Code = Access-Request (1)
      Packet identifier = 0x7f (127)
      Length = 176
      Authenticator = F5E55840E324AA49D216D9DBD069807F
      NAS-IP-Address = 192.0.2.38
      NAS-Port = 5
      User-Name = 12345678
      Digest-Method = GET
      Digest-URI = /index.html
      Digest-Realm = example.com
      Digest-Qop = auth
      Digest-Algorithm = MD5
      Digest-CNonce = 56593a80
      Digest-Nonce = a3086ac8
      Digest-Nonce-Count = 00000001
      Digest-Response = ba623217b5ec024d30c4aaef9d8494de
      Digest-Username = 12345678
      Message-Authenticator = C360BFCEDFFBCE893469E802013DA5AA

   C->B

      Code = Access-Accept (2)
      Packet identifier = 0x7f (127)
      Length = 72
      Authenticator = F1ECAC22D3C88E0260B287FA35595F80
      Digest-Response-Auth = 29624e0bee4342994d041d07f7bcd44c
      Message-Authenticator = 956312EC57AF51ABC4F6965270F34982

   B->A

      HTTP/1.1 200 OK
      ...

      <html>
      ...

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

Delivery-date: Sat, 18 Aug 2007 21:54:13 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Completion of Review of RADIUS GEOPRIV Location Specification
Date: Sat, 18 Aug 2007 14:54:04 -0700

On Wednesday, July 4, 2007 a request for review was posted to the RADEXT WG 
mailing list relating to the RADIUS Geopriv specification:

http://ops.ietf.org/lists/radiusext/2007/msg00484.html

The specification is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-15.txt

So far, no comments have been received.  The document has now completed IESG 
review and is awaiting resolution of IESG DISCUSS comments.   If there are 
any further comments on this document, please speak up NOW.

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

Delivery-date: Sat, 18 Aug 2007 21:49:17 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for review of "AAA Framework for Multicasting"
Date: Sat, 18 Aug 2007 14:49:00 -0700

A request for review has been received relating to the document "AAA 
Framework for Multicasting" which is under development within the MBONED WG. 
  The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-04.txt

The Request for Review will last until September 5, 2007.  Please post your 
comments on this document to the RADEXT WG mailing list, CC:'ing the 
document authors.

Information on the review request was previously posted to the RADEXT WG 
mailing list:
http://ops.ietf.org/lists/radiusext/2007/msg00528.html

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

Delivery-date: Sat, 18 Aug 2007 21:43:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG review of draft-nelson-radius-management-authorization
Date: Sat, 18 Aug 2007 14:43:44 -0700

On August 2, 2007 a request for review of 
draft-nelson-radius-management-authorization was posted to the RADEXT WG 
mailing list:
http://ops.ietf.org/lists/radiusext/2007/msg00581.html

The review concluded on August 16, 2007.   More than half a dozen 
individuals indicated interest and support for the document, and there were 
no dissenting opinions.  As a result, the document has been adopted as a 
RADEXT WG work item.

The following comments were received:
http://ops.ietf.org/lists/radiusext/2007/msg00623.html  (Bert Wijnen)
http://ops.ietf.org/lists/radiusext/2007/msg00630.html (Stefan Winter)

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

Delivery-date: Sat, 18 Aug 2007 21:39:12 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Review of "Issues and Fixes" changes
Date: Sat, 18 Aug 2007 14:38:55 -0700

On Firday, August 3, 2007 a request for review of the "Issues and Fixes" 
document changes to address IESG DISCUSS comments was posted to the RADEXT 
WG mailing list:
http://ops.ietf.org/lists/radiusext/2007/msg00584.html

The review request completed on August 17, 2007.

A single review comment was received:
http://ops.ietf.org/lists/radiusext/2007/msg00585.html

If anyone has any further comments on the changes made between -04 and -05, 
please post them by Friday, August 25, 2007.  Since this document has 
completed IESG evaluation, it can be put back on the IESG agenda once the 
IESG DISCUSS comments are resolved.  The latest version is available here:

http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-05.txt

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

Delivery-date: Sat, 18 Aug 2007 21:35:28 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG last call on "RADIUS Attributes for Filtering and Redirection"
Date: Sat, 18 Aug 2007 14:34:43 -0700

On July 5, 2007 the RADEXT WG began WG last call on "RADIUS Attributes for 
Filtering and Redirection":

http://ops.ietf.org/lists/radiusext/2007/msg00494.html
http://ops.ietf.org/lists/radiusext/2007/msg00541.html

This WG last call was to last until Monday, July 23, 2007.

During the WG last call, only a single comment was received, from Hannes 
Tschofenig:
http://ops.ietf.org/lists/radiusext/2007/msg00496.html

No other messages were posted to the RADEXT WG mailing list indicating that 
WG participants had read the document.

Given the light level of participation, we are going to extend the WG last 
call for 10 more days (until August 28, 2007).   If you have read the 
document and approve of its publication as a Proposed Standard, please post 
your approval to the list, even if you have no comments to provide.

If you have comments, please provide them in the format described on the 
RADEXT WG Issues page:
http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Sat, 18 Aug 2007 13:18:02 +0000
Subject: RE: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization
Date: Sat, 18 Aug 2007 09:17:03 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I have read through the document and I support it becoming a WG item.

Thanx.=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Tuesday, August 14, 2007 10:32 AM
To: [email-masked]
Subject: REMINDER: RADEXT WG review of
draft-nelson-radius-management-authorization

The WG review request ends on August 16, 2007.  So far we have had only
person express interest - not enough to adopt this document as a WG work
item.  Please post to the list if you support taking this on as a WG
work item (even if you have no comments to post).

>From: "Wijnen, Bert (Bert)" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>,        "Bernard Aboba"=20
><[email-masked]>
>Subject: RE: [Isms] [[email-masked]: Review o=20
>fdraft-nelson-radius-management-authorization-05.txt]
>Date: Tue, 14 Aug 2007 11:35:43 +0200
>
>Some nits:
>
>Sect 4
>
>    The local application of the Management-Policy-Id within the
managed
>    entity may take the form of (a) one of an enumeration of command
>    privilege levels, (b) a mapping into an SNMP View Based Access
>    Control Method (VACM) table [RFC3415], or (c) some other set of
>
>Did you intend to writhe "Method", or do you mean "Model"?
>VACM stands for View Based Access Control Model in the SNMP context.
>
>Sect 7.3
>    The Text field is one or more octets, and its contents are
>    implementation dependent.  It is intended to be human readable and
>    MUST NOT affect operation of the protocol.  It is recommended that
>    the message contain UTF-8 encoded 10646 [RFC2279] characters.
>
>The latest RFC for UTF-8 is RFC3629.
>I guess it is better reference that one.
>
>I can support this work item as a topic for the RADEXT WG.
>Not sure how much I can contribute though, but I will try to review=20
>revisions of the document
>
>Bert Wijnen

--

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

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

Delivery-date: Thu, 16 Aug 2007 11:40:44 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Review of draft-nelson-radius-management-authorization-05.txt
Date: Thu, 16 Aug 2007 07:40:32 -0400
Organization: Elbrys Networks, Inc.

Stefan Winter writes...

> Is there a specific reason for not enumerating "Telnet" as one
> of the Framed-Management-Protocol values?

A loose definition of "framed management" is anything that is not CLI-based.
Since Telnet is used, exclusively to my knowledge, to provide remote
terminal emulation access to the CLI of the NAS, it is not considered a
framed management protocol.  That's why it was omitted.  Rlogin falls into
that same category.

Of course, I would hope that the WG members would provide just this sort of
comment during review of the draft prior to WGLC, so that we can include
enumerated values covering the complete range of NAS management options.

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

Delivery-date: Thu, 16 Aug 2007 05:52:48 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Review of draft-nelson-radius-management-authorization-05.txt
Date: Thu, 16 Aug 2007 07:51:22 +0200
Cc: [email-masked]

--nextPart1235753.SEP9XBH9n6
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

I also support its adoption. After having a quick glance: Is there a specif=
ic=20
reason for not enumerating "Telnet" as one of the Framed-Management-Protoco=
l=20
values?

Stefan

=2D-=20
Stefan WINTER

Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na=
tionale et de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked] =C2=A0 =C2=A0 Tel.:  =C2=A0 =C2=A0+352 424=
409-1
http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0  =C2=A0 Fax=
: =C2=A0 =C2=A0 =C2=A0+352 422473

--nextPart1235753.SEP9XBH9n6
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart1235753.SEP9XBH9n6--

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

Delivery-date: Thu, 16 Aug 2007 03:16:22 +0000
From: "Okita, Cat" <[email-masked]>
To: "Rati, Shiddalinganagouda" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 16 Aug 2007 03:14:23 +0000
Subject: RE: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization 
Accept-Language: en-US
acceptlanguage: en-US

I also agree - I have read through the document, and would like to see it a=
s a WG item.

Cat Okita
Network and Security Services
Hewlett-Packard (Canada) Co.
[email-masked]
+1 416 309 6438
________________________________________
From: [email-masked] [[email-masked]] On Behalf=
 Of Rati, Shiddalinganagouda
Sent: Wednesday, August 15, 2007 20:23
To: [email-masked]
Subject: REMINDER: RADEXT WG review of draft-nelson-radius-management-autho=
rization

I have gone through the document and I support this document as a WG item.

-Siddu Rati

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

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

Delivery-date: Thu, 16 Aug 2007 00:24:00 +0000
From: "Rati, Shiddalinganagouda" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 16 Aug 2007 00:23:05 +0000
Subject: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization 
Accept-Language: en-US
acceptlanguage: en-US

I have gone through the document and I support this document as a WG item.

-Siddu Rati

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

Delivery-date: Tue, 14 Aug 2007 19:54:25 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: FW: Review of draft-nelson-radius-management-authorization-05.txt
Date: Tue, 14 Aug 2007 15:54:12 -0400
Organization: Elbrys Networks, Inc.

Forwarding to the list...

> -----Original Message-----
> From: Kaushik Narayan [mailto:[email-masked]]
> Sent: Tuesday, August 14, 2007 3:51 PM
> To: David B. Nelson; Bernard Aboba
> Subject: Re: Review of draft-nelson-radius-management-authorization-05.txt
> 
> 
> Hi Bernard, David
> 
> I would like to see this document taken on as a WG item. I believe 
> that beyond the usage for ISMS, the mechanisms described in this 
> document can be applied to other management protocols such as netconf.
> 
> I will review the document and send in my comments.
> 
> regards,
>  kaushik

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

Delivery-date: Tue, 14 Aug 2007 18:12:28 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization
Date: Tue, 14 Aug 2007 11:09:53 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7DE9E.963B426D
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bernard Aboba wrote:
> The WG review request ends on August 16, 2007.  So far we have had =
only
> person express interest - not enough to adopt this document as a WG =
work
> item.  Please post to the list if you support taking this on as a WG
> work item (even if you have no comments to post).

  I support this document as a WG item.
gwz> Me, too (though I'd like to point out that that does _not_ mean =
that I support its rubberstaming ;-).=20

  Alan DeKok.

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

------_=_NextPart_001_01C7DE9E.963B426D
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.59">=0A=
<TITLE>Re: REMINDER: RADEXT WG review of =
draft-nelson-radius-management-authorization</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText79423 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT size=3D2>Bernard Aboba wrote:<BR>&gt; The WG review =
request =0A=
ends on August 16, 2007.&nbsp; So far we have had only<BR>&gt; person =
express =0A=
interest - not enough to adopt this document as a WG work<BR>&gt; =
item.&nbsp; =0A=
Please post to the list if you support taking this on as a WG<BR>&gt; =
work item =0A=
(even if you have no comments to post).<BR><BR>&nbsp; I support this =
document as =0A=
a WG item.</FONT></DIV><FONT size=3D2></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2><FONT face=3DArial color=3D#0000ff>gwz&gt; =
Me, too (though =0A=
I'd like to point out that that does _not_ mean that I support its =
rubberstaming =0A=
;-).</FONT>=0A=
<DIV dir=3Dltr><BR><BR>&nbsp; Alan DeKok.<BR><BR>--<BR>to unsubscribe =
send a =0A=
message to [email-masked] with<BR>the word 'unsubscribe' =
in a =0A=
single line as the message text body.<BR>archive: &lt;<A =0A=
href=3D"http://psg.com/lists/radiusext/">http://psg.com/lists/radiusext/<=
/A>&gt;<BR></DIV></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C7DE9E.963B426D--

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

Delivery-date: Tue, 14 Aug 2007 17:59:36 +0000
Content-class: urn:content-classes:message
Subject: RE: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization
Date: Tue, 14 Aug 2007 17:40:02 -0000
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I have reviewed this document and believe it should be considered as a
WG document.  There is significant value in leveraging the AAA framework
for management access and as this draft points out there are
enhancements required and additional attributes needed to represent and
authorize the how devices are managed today.

Paul Congdon=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, August 14, 2007 7:32 AM
> To: [email-masked]
> Subject: REMINDER: RADEXT WG review of=20
> draft-nelson-radius-management-authorization
>=20
> The WG review request ends on August 16, 2007.  So far we=20
> have had only person express interest - not enough to adopt=20
> this document as a WG work item.  Please post to the list if=20
> you support taking this on as a WG work item (even if you=20
> have no comments to post).
>=20
>=20
> >From: "Wijnen, Bert (Bert)" <[email-masked]>
> >To: <[email-masked]>, <[email-masked]>
> >CC: <[email-masked]>,        "Bernard Aboba"=20
> ><[email-masked]>
> >Subject: RE: [Isms] [[email-masked]: Review o=20
> >fdraft-nelson-radius-management-authorization-05.txt]
> >Date: Tue, 14 Aug 2007 11:35:43 +0200
> >
> >Some nits:
> >
> >Sect 4
> >
> >    The local application of the Management-Policy-Id within=20
> the managed
> >    entity may take the form of (a) one of an enumeration of command
> >    privilege levels, (b) a mapping into an SNMP View Based Access
> >    Control Method (VACM) table [RFC3415], or (c) some other set of
> >
> >Did you intend to writhe "Method", or do you mean "Model"?
> >VACM stands for View Based Access Control Model in the SNMP context.
> >
> >Sect 7.3
> >    The Text field is one or more octets, and its contents are
> >    implementation dependent.  It is intended to be human=20
> readable and
> >    MUST NOT affect operation of the protocol.  It is=20
> recommended that
> >    the message contain UTF-8 encoded 10646 [RFC2279] characters.
> >
> >The latest RFC for UTF-8 is RFC3629.
> >I guess it is better reference that one.
> >
> >I can support this work item as a topic for the RADEXT WG.
> >Not sure how much I can contribute though, but I will try to review=20
> >revisions of the document
> >
> >Bert Wijnen
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 14 Aug 2007 16:44:41 +0000
Date: Tue, 14 Aug 2007 12:44:03 -0400
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization

Bernard Aboba wrote:
> The WG review request ends on August 16, 2007.  So far we have had only
> person express interest - not enough to adopt this document as a WG work
> item.  Please post to the list if you support taking this on as a WG
> work item (even if you have no comments to post).

  I support this document as a WG item.

  Alan DeKok.

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

Delivery-date: Tue, 14 Aug 2007 15:25:51 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization
Date: Tue, 14 Aug 2007 11:25:53 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> The WG review request ends on August 16, 2007.

Thanks for issuing the reminder.

I didn't previously see this post, as it went to my previous employment
address, and apparently not to the RADEXT list.  I'll comment in-line,
below.

Bert Wijnen writes...

> >Sect 4
> >
> >    The local application of the Management-Policy-Id within the managed
> >    entity may take the form of (a) one of an enumeration of command
> >    privilege levels, (b) a mapping into an SNMP View Based Access
> >    Control Method (VACM) table [RFC3415], or (c) some other set of
> >
> >Did you intend to writhe "Method", or do you mean "Model"?
> >VACM stands for View Based Access Control Model in the SNMP context.

Yes, "Model" was the intended word.  Thanks, we'll fix that.

> >Sect 7.3
> >    The Text field is one or more octets, and its contents are
> >    implementation dependent.  It is intended to be human readable and
> >    MUST NOT affect operation of the protocol.  It is recommended that
> >    the message contain UTF-8 encoded 10646 [RFC2279] characters.
> >
> >The latest RFC for UTF-8 is RFC3629.
> >I guess it is better reference that one.

Good catch.  We'll fix that one, too.

> >I can support this work item as a topic for the RADEXT WG.
> >Not sure how much I can contribute though, but I will try to 
> >review revisions of the document

Thanks.

Obviously, as an author, I support this work being adopted as a RADEXT WG
work item, for what little that opinion may be worth.

For those who may not yet have reviewed this draft, or those who have not
reviewed a recent version, let me recap its purpose.

This draft adds a couple of new attributes and a new value for an existing
attribute to allow provisioning of management access authorization beyond
the existing two-level authorization for access to the CLI of the NAS.  The
type of additional authorization supported includes specific authorization
for management access methods and protocols other than CLI, such as SNMP, or
HTTP.  It also provides for more granular access levels than privileged and
non-privileged.  Many NASes in wide use today have multiple levels of
management access permissions.  This draft provides a standardized way to
provision such access.

Much of the body of RADIUS work is about provisioning securely authorized
access to network resources, through the services of a NAS.  This work is
about provisioning securely authorized access to the management interfaces
of the NAS itself, as part of an overall network infrastructure security
solution.

All of the attributes and value introduced in this draft can be implemented
as new entries in the attribute dictionary of a dictionary driven RADIUS
server implementation.

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

Delivery-date: Tue, 14 Aug 2007 15:16:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Review of draft-nelson-radius-management-authorization-05.txt
Date: Tue, 14 Aug 2007 15:13:01 -0000
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multipart message in MIME format.

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

I support this work and would like to see it become an official WG item.

MS

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, August 02, 2007 11:20 AM
> To: [email-masked]
> Subject: Review of draft-nelson-radius-management-authorization-05.txt
> 
> The ISMS WG has requested that RADEXT WG take on "Remote Authentication
> Dial-In User Service (RADIUS) Authorization for Network Access Server
> (NAS)
> Management" as a WG work item.
> 
> In response to this request, we are requesting reviews of the document,
> which is found here:
> http://www.ietf.org/internet-drafts/draft-nelson-radius-management-
> authorization-05.txt
> 
> The request for review will last until August 16, 2007.  Please
> indicate
> whether you would like this document to be taken on as a WG work item.
> Please respond even if you have no issues with the document; if you
> have
> comments, please send the issues to the RADEXT WG mailing list in the
> format
> provided on here:
> http://www.drizzle.com/~aboba/RADEXT/
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

------=_NextPart_000_007E_01C7DE5B.B22C8200
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_007E_01C7DE5B.B22C8200--

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

Delivery-date: Tue, 14 Aug 2007 14:32:27 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: REMINDER: RADEXT WG review of draft-nelson-radius-management-authorization
Date: Tue, 14 Aug 2007 07:31:36 -0700

The WG review request ends on August 16, 2007.  So far we have had only 
person express interest - not enough to adopt this document as a WG work 
item.  Please post to the list if you support taking this on as a WG work 
item (even if you have no comments to post).

>From: "Wijnen, Bert (Bert)" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>,        "Bernard Aboba" 
><[email-masked]>
>Subject: RE: [Isms] [[email-masked]: Review o 
>fdraft-nelson-radius-management-authorization-05.txt]
>Date: Tue, 14 Aug 2007 11:35:43 +0200
>
>Some nits:
>
>Sect 4
>
>    The local application of the Management-Policy-Id within the managed
>    entity may take the form of (a) one of an enumeration of command
>    privilege levels, (b) a mapping into an SNMP View Based Access
>    Control Method (VACM) table [RFC3415], or (c) some other set of
>
>Did you intend to writhe "Method", or do you mean "Model"?
>VACM stands for View Based Access Control Model in the SNMP context.
>
>Sect 7.3
>    The Text field is one or more octets, and its contents are
>    implementation dependent.  It is intended to be human readable and
>    MUST NOT affect operation of the protocol.  It is recommended that
>    the message contain UTF-8 encoded 10646 [RFC2279] characters.
>
>The latest RFC for UTF-8 is RFC3629.
>I guess it is better reference that one.
>
>I can support this work item as a topic for the RADEXT WG.
>Not sure how much I can contribute though, but I will try to review
>revisions of the document
>
>Bert Wijnen

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

Delivery-date: Sun, 12 Aug 2007 13:33:17 +0000
Date: Sun, 12 Aug 2007 09:32:11 -0400
From: Alan DeKok <[email-masked]>
To: Dan Harkins <[email-masked]>
CC: Leif Johansson <[email-masked]>,  "David B. Nelson" <[email-masked]>, [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

Dan Harkins wrote:
>   Each RADIUS client MUST go through the step of obtaining the certificate
> of the certification authority and affirmatively trusting it before it is
> used to authenticate the TLS exchange.

  In the BOF that started RADEXT, I presented a "client kickstart"
draft, co-authored with Robert Moskowitz.  It's functionally equivalent
to (D)TLS + DNS lookups to find the server, along with fingerprint
validation.

>   There is a dangerous attraction to (D)TLS because people can do server-
> side authentication only and base that on a self-signed certificate--
> they typically say something along the lines of "just click <ok> when
> asked if you want to proceed!". They think that since they're using TLS
> then everything is secure when, in fact, their deployment is patently
> insecure.

  <g>  "Just use IPSec!"

  The issue that (D)TLS solves is one of mind-share.  Administrators are
familiar with TLS, and with the tools to deploy a TLS-based infrastructure.

> This sort of provisioning is something that people who manage
> RADIUS servers have done before since it's how the current RADIUS secret
> is provisioned. Asking administrators to install a certificate in a
> trusted store on every RADIUS client, in addition to asking them to install
> a username and password, might be alot to ask. Would demanding that they
> deploy a PKI and assign a certificate and private key to every RADIUS
> client be too much to ask?

  For new deployments, it's possible.  Existing ones are often beyond hope.

  Alan DeKok.

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

Delivery-date: Sat, 11 Aug 2007 19:09:06 +0000
Date: Sat, 11 Aug 2007 21:08:29 +0200
From: Leif Johansson <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

Bernard Aboba wrote:
>> You can use x509 as a key-only mechanism too. Just configure
>> each radius endpoint with a self-signed cert and use the (say)
>> fingerprint to express trust. That is equivalent (in terms of
>> the work involved) to a shared-secret database and can be
>> automated (in tools) almost the same way.
>
> Is this something that current RADSEC implementations support?
>
>
>
I can't be absolutely sure but since openssl has hooks for certificate
validation it would be a no-brainer to put it in.

    Cheers Leif

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

Delivery-date: Sat, 11 Aug 2007 18:30:04 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Continued discussion of RADIUS Crypto-Agility
Date: Sat, 11 Aug 2007 11:29:01 -0700

>You can use x509 as a key-only mechanism too. Just configure
>each radius endpoint with a self-signed cert and use the (say)
>fingerprint to express trust. That is equivalent (in terms of
>the work involved) to a shared-secret database and can be
>automated (in tools) almost the same way.

Is this something that current RADSEC implementations support?

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

Delivery-date: Sat, 11 Aug 2007 08:59:25 +0000
Date: Sat, 11 Aug 2007 10:59:24 +0200
From: Leif Johansson <[email-masked]>
To: Dan Harkins <[email-masked]>
CC: "David B. Nelson" <[email-masked]>,  [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

>   Using (D)TLS does not absolve you of the requirement to have some
> sort of credential on the client. To be secure you MUST enroll every
> RADIUS client in a certification authority and install the server's
> certificate in a trusted store. In addition you need to provision some
> client-side credential, either a username and password or a certificate
> and private key.
>   
Correct. My point was that people know how to do that and that
these steps need to be defined and well understood för keywrap.
>   Each RADIUS client MUST go through the step of obtaining the certificate
> of the certification authority and affirmatively trusting it before it is
> used to authenticate the TLS exchange. Now I happen to believe that PKI is
> not that big of a deal. But the continued existence of this working group
> underscores the fact that such a belief is a minority one. People are
> much more comfortable with massive secret key databases than with PKI.
>   
You can use x509 as a key-only mechanism too. Just configure
each radius endpoint with a self-signed cert and use the (say)
fingerprint to express trust. That is equivalent (in terms of
the work involved) to a shared-secret database and can be
automated (in tools) almost the same way.
>   There is a dangerous attraction to (D)TLS because people can do server-
> side authentication only and base that on a self-signed certificate--
> they typically say something along the lines of "just click <ok> when
> asked if you want to proceed!". They think that since they're using TLS
> then everything is secure when, in fact, their deployment is patently
> insecure.
>   
Not unless you "click ok" by manually configuring the trust. This
gives you the crypto agility of tls with almost no extra complexity
from TLS.
>   The keywrap draft defines 2 new keys, one for wrapping the key and
> another for integrity verification of the entire message. (Note that using
> a different algorithm as "enc-type" could obviate the need for the second
> one). This sort of provisioning is something that people who manage
> RADIUS servers have done before since it's how the current RADIUS secret
> is provisioned. Asking administrators to install a certificate in a
> trusted store on every RADIUS client, in addition to asking them to install
> a username and password, might be alot to ask. Would demanding that they
> deploy a PKI and assign a certificate and private key to every RADIUS
> client be too much to ask?
>   
Sure but they don't have to :-)

Also deployments of EAP-TLS already perform these steps today.

    Cheers  Leif
>   Dan.
>
>
>
>   

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

Delivery-date: Sat, 11 Aug 2007 08:53:09 +0000
Date: Sat, 11 Aug 2007 10:52:27 +0200
From: Leif Johansson <[email-masked]>
To: Dan Harkins <[email-masked]>
CC: Stefan Winter <[email-masked]>,  Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: [Re: Continued discussion of RADIUS Crypto-Agility]

>
>   It's the ciphersuite in TLS provides the crypto-agility. Similarly
> the "enc-type" in the keywrap draft provides the crypto-agility. One
> value of "enc-type" is for RFC3394 style AES Keywrap. A different value
> could define RFC3217-style 3DES or RC2 keywrapping. There are many nice
> things about AES though that make something like SIV-AES style keywrapping
> even more appealing that RFC3394.
>
>
>   
Yes you're right, I missed this when reading the draft.

    Cheers Leif

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

Delivery-date: Sat, 11 Aug 2007 00:37:54 +0000
Date: Fri, 10 Aug 2007 17:37:22 -0700 (PDT)
Subject: Re: Continued discussion of RADIUS Crypto-Agility
From: "Dan Harkins" <[email-masked]>
To: "Leif Johansson" <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, [email-masked]

  Hi Leif,

On Fri, August 10, 2007 6:07 am, Leif Johansson wrote:
>
>> Glen has explained to us why he thinks that TLS is excluded on
>> procedural
>> grounds (charter exclusion).  I haven't heard much debate about the
>> relative
>> merits of an internal vs. external solution.
>>
>>
>>
> I've tried to argue that I favor TLS/DTLS on the grounds that
> the work required can be done by radius experts which there
> are lots of in this wg as opposed to the aes-keywrap draft which
> requires work by security protocol experts (to specify
> how to do key agreement etc) of which there are few in this wg.

  Using (D)TLS does not absolve you of the requirement to have some
sort of credential on the client. To be secure you MUST enroll every
RADIUS client in a certification authority and install the server's
certificate in a trusted store. In addition you need to provision some
client-side credential, either a username and password or a certificate
and private key.

  Each RADIUS client MUST go through the step of obtaining the certificate
of the certification authority and affirmatively trusting it before it is
used to authenticate the TLS exchange. Now I happen to believe that PKI is
not that big of a deal. But the continued existence of this working group
underscores the fact that such a belief is a minority one. People are
much more comfortable with massive secret key databases than with PKI.

  There is a dangerous attraction to (D)TLS because people can do server-
side authentication only and base that on a self-signed certificate--
they typically say something along the lines of "just click <ok> when
asked if you want to proceed!". They think that since they're using TLS
then everything is secure when, in fact, their deployment is patently
insecure.

  The keywrap draft defines 2 new keys, one for wrapping the key and
another for integrity verification of the entire message. (Note that using
a different algorithm as "enc-type" could obviate the need for the second
one). This sort of provisioning is something that people who manage
RADIUS servers have done before since it's how the current RADIUS secret
is provisioned. Asking administrators to install a certificate in a
trusted store on every RADIUS client, in addition to asking them to install
a username and password, might be alot to ask. Would demanding that they
deploy a PKI and assign a certificate and private key to every RADIUS
client be too much to ask?

  Dan.

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

Delivery-date: Sat, 11 Aug 2007 00:14:58 +0000
Date: Fri, 10 Aug 2007 17:14:02 -0700 (PDT)
Subject: Re: [Re: Continued discussion of RADIUS Crypto-Agility]
From: "Dan Harkins" <[email-masked]>
To: "Leif Johansson" <[email-masked]>
Cc: "Dan Harkins" <[email-masked]>, "Stefan Winter" <[email-masked]>, "Bernard Aboba" <[email-masked]>, [email-masked]

  Hi Leif,

On Fri, August 10, 2007 12:47 am, Leif Johansson wrote:
> Dan Harkins wrote:
>>   Hello,
>>
>> On Wed, August 8, 2007 7:22 am, Leif Johansson wrote:
>> [snip]
>>
>>> There are two fundamental ways to address this problem: reference
>>> some work or roll your own. Radius+DTLS and RadSec fall into the
>>> first category, keywrap falls into the second category.
>>>
>>
>>   I have to disagree. Keywrap is not "roll your own". It uses RFC3394
>> which itself describes a NIST specification of a mode of AES that came
>> out of a draft standard from X9.102. It has received extensive vetting.
>> The authors of the keywrap draft are proposing to use an existing
>> standard to solve the problem it was created to solve--
>> cryptographically
>> protecting keying material in transit.
>>
>>   Dan.
>>
>>
> Another thing that bothers me is the direct reference to AES.
>
> Introducing a dependency on any one algorithm does not
> constitute agility in any sense of the word. The point (imho) is
> not to demonstrate how much we trust AES today but to make
> sure radius doesn't have to go through this again when AES
> needs replacing.
>
>     Cheers Leif

  It's the ciphersuite in TLS provides the crypto-agility. Similarly
the "enc-type" in the keywrap draft provides the crypto-agility. One
value of "enc-type" is for RFC3394 style AES Keywrap. A different value
could define RFC3217-style 3DES or RC2 keywrapping. There are many nice
things about AES though that make something like SIV-AES style keywrapping
even more appealing that RFC3394.

  Dan.

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

Delivery-date: Fri, 10 Aug 2007 21:34:09 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Fri, 10 Aug 2007 14:33:39 -0700

>Glen has explained to us why he thinks that TLS is excluded on procedural
>grounds (charter exclusion).  I haven't heard much debate about the 
>relative
>merits of an internal vs. external solution.

I am not sure that internal vs. external is the right point of comparison.  
To me the issue comes down to static vs. dynamic keying.

To my mind, there are some major negatives associated with an approach that 
depends on static keying, whether it is internal or external.  These involve 
both management issues as well as security concerns.

>From a management perspective, the existing RADIUS shared-secret mechanism 
already seems to be more than many deployments can handle.  We now have many 
deployments with hundreds or thousands of NASes, and in these situations, 
allocating a different shared secret for each NAS-RADIUS server pair is 
difficult to manage.  As a result, in many cases, a single RADIUS shared 
secret is used, and this not only creates domino effect vulnerabilities, but 
negates many of the security guarantees that RADIUS is required to provide 
in key management applications.

When combined with l ack of client or server conformance to the RFC 2865 
recommendations on shared secret length, use of a single shared secret 
creates a vulnerability to offline dictionary attack.
This is not an issue that crypto-agility by itself can address.

On the other hand, with dynamic keying, it is possible to have some 
confidence that the keys used to protect traffic between NAS-RADIUS server 
pairs are unique and fresh, and are not susceptible to offline dictionary 
attack.  Of course, a vulnerability to offline dictionary attack may still 
exist if the dynamic keys are themselves derived based on pre-shared keys 
(e.g. IKE or TLS pre-shared key authentication modes).  If certificates are 
used instead of pre-shared keys, then the result is a substantial increase 
in footprint and certificate management issues on the NAS.

The end result of this is that static keying, while probably more easily 
deployed than dynamic keying, will probably not improve RADIUS secruity 
substantially in the long-term, given existing practice.

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

Delivery-date: Fri, 10 Aug 2007 21:12:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: RE: [Re: Continued discussion of RADIUS Crypto-Agility]
Date: Fri, 10 Aug 2007 14:11:52 -0700

>Another thing that bothers me is the direct reference to AES.
>
>Introducing a dependency on any one algorithm does not
>constitute agility in any sense of the word. The point (imho) is
>not to demonstrate how much we trust AES today but to make
>sure radius doesn't have to go through this again when AES
>needs replacing.

It is fine (required, really) to specify and reference a 
mandatory-to-implement algorithm for each usage.  This includes not only 
keywrap but also the MIC.   However, it should also be possible to negotiate 
alternative algorithms.  That requires a mechanism negotiate algorithms, as 
well as IANA considerations to allocate code points to additional algorithms 
beyond those specified in the document.

Are you saying that any of these things is missing from the document?

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

Delivery-date: Fri, 10 Aug 2007 13:28:16 +0000
Date: Fri, 10 Aug 2007 09:27:27 -0400
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

David B. Nelson wrote:
> Glen has explained to us why he thinks that TLS is excluded on procedural
> grounds (charter exclusion).  I haven't heard much debate about the relative
> merits of an internal vs. external solution.

  An internal solution involves changing the internal RADIUS
implementation of servers and clients.  An external solution involves
encapsulating RADIUS as-is in another transport stream.

  Having spent time poking the internals of RADIUS servers and clients,
I would prefer to avoid doing more of that.  Many RADIUS implementations
 are fragile.  Changing them, or trying to inter-operate with them is
problematic.

  If we leverage (D)TLS, we gain the interoperability tests done for
every other protocol (HTTP, SIP, etc.).  We gain the momentum behind
security fixes to implementations or protocol designs.

  An internal implementation involves yet another RADIUS-specific thing.

  Alan DeKok.

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

Delivery-date: Fri, 10 Aug 2007 13:07:56 +0000
Date: Fri, 10 Aug 2007 15:07:48 +0200
From: Leif Johansson <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

> Glen has explained to us why he thinks that TLS is excluded on procedural
> grounds (charter exclusion).  I haven't heard much debate about the relative
> merits of an internal vs. external solution.
>
>
>   
I've tried to argue that I favor TLS/DTLS on the grounds that
the work required can be done by radius experts which there
are lots of in this wg as opposed to the aes-keywrap draft which
requires work by security protocol experts (to specify
how to do key agreement etc) of which there are few in this wg.

    Cheers Leif

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

Delivery-date: Fri, 10 Aug 2007 12:22:51 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Fri, 10 Aug 2007 08:22:31 -0400

Stefan Winter writes...

> The point I tried to make was that the *security properties*
> of a protocol can be made mostly independent of the layer 4 
> transport.

I agree.

It seems to me that the decision tree for the RADEXT crypto-agility work
would be something like:

Internal security or external security?

(Internal means defined within the application layer PDUs.)

If internal, then keywrap & encrypted attributes or something else yet to be
offered.

If external, then DTLS or TLS? (Or something else yet to be offered.)

I think it would help the discussion to debate the pros and cons of these
choices.

Glen has explained to us why he thinks that TLS is excluded on procedural
grounds (charter exclusion).  I haven't heard much debate about the relative
merits of an internal vs. external solution.

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

Delivery-date: Fri, 10 Aug 2007 12:11:35 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Fri, 10 Aug 2007 08:10:55 -0400

Leif Johansson writes...

> Another thing that bothers me is the direct reference to AES.
> 
> Introducing a dependency on any one algorithm does not
> constitute agility in any sense of the word. The point (imho) is
> not to demonstrate how much we trust AES today but to make
> sure radius doesn't have to go through this again when AES
> needs replacing.

The keywrap draft was originally created for the purpose of obtaining
FIPS-140 certification of an 802.11 WLAN solution.  It pre-dates the RADEXT
crypto-agility effort.

The fact that it contains cipher-suite identifiers means that it can be
considered in the more general sense for crypto-agility.  As I said in my
last post in this thread, we really need to consider the encrypted
attributes draft together with the keywrap draft to meet the RADEXT
crypto-agility requirements.

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

Delivery-date: Fri, 10 Aug 2007 07:47:37 +0000
Date: Fri, 10 Aug 2007 09:47:13 +0200
From: Leif Johansson <[email-masked]>
To: Dan Harkins <[email-masked]>
CC: Stefan Winter <[email-masked]>,  Bernard Aboba <[email-masked]>, [email-masked]
Subject: [Re: Continued discussion of RADIUS Crypto-Agility]

Dan Harkins wrote:
>   Hello,
>
> On Wed, August 8, 2007 7:22 am, Leif Johansson wrote:
> [snip]
>   
>> There are two fundamental ways to address this problem: reference
>> some work or roll your own. Radius+DTLS and RadSec fall into the
>> first category, keywrap falls into the second category.
>>     
>
>   I have to disagree. Keywrap is not "roll your own". It uses RFC3394
> which itself describes a NIST specification of a mode of AES that came
> out of a draft standard from X9.102. It has received extensive vetting.
> The authors of the keywrap draft are proposing to use an existing
> standard to solve the problem it was created to solve-- cryptographically
> protecting keying material in transit.
>
>   Dan.
>
>   
Another thing that bothers me is the direct reference to AES.

Introducing a dependency on any one algorithm does not
constitute agility in any sense of the word. The point (imho) is
not to demonstrate how much we trust AES today but to make
sure radius doesn't have to go through this again when AES
needs replacing.

    Cheers Leif

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

Delivery-date: Fri, 10 Aug 2007 06:00:48 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: Re: Continued discussion of RADIUS Crypto-Agility
Date: Fri, 10 Aug 2007 08:00:25 +0200
Cc: [email-masked]

--nextPart1276520.SQbAxGchIF
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

>> The impact of connectionless vs. connection is not very significant when
>> discussing the protocol's *security*, IMO.
>
> So I gather that as far as you're concerned a network "protocol" solely
> consistes of the format of the innermost PDU?

No. The point I tried to make was that the *security properties* of a proto=
col=20
can be made mostly independent of the layer 4 transport. That's why I put=20
*security* in *bold*. That's what I thought this thread was supposed to be=
=20
about. I am not trying to argue that connectionless and connection-oriented=
=20
transports are the same thing (what a fool would I be).

TLS and DTLS are a good example in that respect: they deliver very similar,=
=20
maybe even identical (I don't dare judge on that), security properties even=
=20
though one is using a connection-oriented, the other one a connectionless=20
transport layer.

>> Well, it's _almost_ RADIUS, especially if one takes into account the
>> mechanisms in RADIUS to detect duplication, retransmission etc, which
>> already contains parts of the merits of TCP.
>
> By that logic, a cobra is _almost_ a pidgeon.
[...]
> Only if snakes are almost birds...

You lost me here. I thought I had provided some *arguments* that show the=20
similarities between RADIUS+DTLS and RadSec. Instead of countering that wit=
h=20
reason, you counter it by throwing strange anatomical claims at me (which y=
ou=20
don't bother to further explain - but I guess that's for the better since i=
t=20
is largely OT anyway). Forgive me if I ignore that part of your post.

Stefan

=2D-=20
Stefan WINTER

Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na=
tionale et de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked] =C2=A0 =C2=A0 Tel.:  =C2=A0 =C2=A0+352 424=
409-1
http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0  =C2=A0 Fax=
: =C2=A0 =C2=A0 =C2=A0+352 422473

--nextPart1276520.SQbAxGchIF
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart1276520.SQbAxGchIF--

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

Delivery-date: Fri, 10 Aug 2007 05:40:55 +0000
Date: Fri, 10 Aug 2007 07:40:55 +0200
From: Leif Johansson <[email-masked]>
To: Dan Harkins <[email-masked]>
CC: Stefan Winter <[email-masked]>,  Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

>   No, and no. RFC3394 is a _use of_ AES. A specific use. It's to solve the
> problem of transmitting keying material over an untrusted network. And
> that is _exactly_ the problem the keywrap draft is solving.
>
>   One thing the IETF does well (in addition to apparently referencing
> existing crypto) is take work from outside the IETF and document it in
> RFCs. TLS is a perfect example. So is RFC3394. Neither one is "roll your
> own" and neither is a proposal to use one of them.
>
>   Dan.
>
>
>   

Yes I was unclear in my comment, sorry.

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

Delivery-date: Fri, 10 Aug 2007 05:40:02 +0000
Date: Fri, 10 Aug 2007 07:39:24 +0200
From: Leif Johansson <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

David B. Nelson wrote:
> Leif Johansson writes...
>
>   
>> That is absolutely "roll your own" - RFC3394 is AES which is
>> crypto not a security protocol.
>>     
>
> No.  RFC 3394 is "Advanced Encryption Standard (AES) Key Wrap Algorithm".
> That's not simply a definition of AES (crypto), which is normatively defined
> in FIPS-197.  It's a specific application of crypto for key wrapping.  It is
> not a key agreement, key distribution or key management protocol, of course.
>
>
>   
Sorry I was not clear enough. What I meant to say is that in order
to deploy radius+keywrap you actually need all of those things and
they are (relatively) well understood in tls.

    Cheers Leif

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

Delivery-date: Fri, 10 Aug 2007 00:30:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Thu, 9 Aug 2007 17:29:54 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Stefan Winter" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7DAE5.92E11188
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

> Well, except that in order to place these things in a common category =
it
> is necessary to ignore one of the defining characteristics of RADIUS:
> that it is only and intentionally defined as a connectionless =
protocol.

The impact of connectionless vs. connection is not very significant when
discussing the protocol's *security*, IMO.
So I gather that as far as you're concerned a network "protocol" solely =
consistes of the format of the innermost PDU?=20

> might like to believe so, RadSec is _not_ RADIUS,

Well, it's _almost_ RADIUS, especially if one takes into account the
mechanisms in RADIUS to detect duplication, retransmission etc, which =
already
contains parts of the merits of TCP.
By that logic, a cobra is _almost_ a pidgeon.

> & therefore far out of
> scope of not just the crypto-agility discussions but of this WG.
> RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS &
> therefore _is_ in scope.

I have understood that DTLS is considered in scope, while RadSec is out =
of
scope (Reminder: I never claimed otherwise). Just keep in mind that DTLS
itself requires even more characteristics of TCP, so when combining the
RADIUS mechanisms that come on top of UDP + the transport mechanisms in =
DTLS,
the end result is getting very close to TCP already. So the distance =
between
in-scope and out-of-scope is a very thin line.
Only if snakes are almost birds...

...

------_=_NextPart_001_01C7DAE5.92E11188
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7651.59">=0A=
<TITLE>Re: Continued discussion of RADIUS Crypto-Agility</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText23571 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT size=3D2>Hi,<BR><BR>&gt; Well, except that in order =
to place =0A=
these things in a common category it<BR>&gt; is necessary to ignore one =
of the =0A=
defining characteristics of RADIUS:<BR>&gt; that it is only and =
intentionally =0A=
defined as a connectionless protocol.<BR><BR>The impact of =
connectionless vs. =0A=
connection is not very significant when<BR>discussing the protocol's =
*security*, =0A=
IMO.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2><FONT face=3DArial color=3D#0000ff>So I =
gather that as far =0A=
as you're concerned a network "protocol" solely consistes of the format =
of the =0A=
innermost PDU?&nbsp;<BR></FONT><BR>&gt; might like to believe so, RadSec =
is =0A=
_not_ RADIUS,<BR><BR>Well, it's _almost_ RADIUS, especially if one takes =
into =0A=
account the<BR>mechanisms in RADIUS to detect duplication, =
retransmission etc, =0A=
which already<BR>contains parts of the merits of TCP.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2><FONT face=3DArial color=3D#0000ff>By that =
logic, a cobra =0A=
is _almost_ a pidgeon.<BR></FONT><BR>&gt; &amp; therefore far out =
of<BR>&gt; =0A=
scope of not just the crypto-agility discussions but of this WG.<BR>&gt; =0A=
RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS =
&amp;<BR>&gt; =0A=
therefore _is_ in scope.<BR><BR>I have understood that DTLS is =
considered in =0A=
scope, while RadSec is out of<BR>scope (Reminder: I never claimed =
otherwise). =0A=
Just keep in mind that DTLS<BR>itself requires even more characteristics =
of TCP, =0A=
so when combining the<BR>RADIUS mechanisms that come on top of UDP + the =0A=
transport mechanisms in DTLS,<BR>the end result is getting very close to =
TCP =0A=
already. So the distance between<BR>in-scope and out-of-scope is a very =
thin =0A=
line.</FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2><FONT face=3DArial color=3D#0000ff>Only if =
snakes are =0A=
almost birds...<BR></FONT><BR><FONT face=3DArial =0A=
color=3D#0000ff>...</FONT></DIV></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C7DAE5.92E11188--

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

Delivery-date: Thu, 09 Aug 2007 22:22:29 +0000
Date: Thu, 9 Aug 2007 15:21:31 -0700 (PDT)
Subject: Re: Continued discussion of RADIUS Crypto-Agility
From: "Dan Harkins" <[email-masked]>
To: "Leif Johansson" <[email-masked]>
Cc: "Dan Harkins" <[email-masked]>, "Stefan Winter" <[email-masked]>, "Bernard Aboba" <[email-masked]>, [email-masked]

On Thu, August 9, 2007 1:58 pm, Leif Johansson wrote:
> Dan Harkins wrote:
>>   Hello,
>>
>> On Wed, August 8, 2007 7:22 am, Leif Johansson wrote:
>> [snip]
>>
>>> There are two fundamental ways to address this problem: reference
>>> some work or roll your own. Radius+DTLS and RadSec fall into the
>>> first category, keywrap falls into the second category.
>>>
>>
>>   I have to disagree. Keywrap is not "roll your own". It uses RFC3394
>>
> That is absolutely "roll your own" - RFC3394 is AES which is
> crypto not a security protocol. Of course no-one in the IETF
> is silly enough not to reference existing crypto :-)

  No, and no. RFC3394 is a _use of_ AES. A specific use. It's to solve the
problem of transmitting keying material over an untrusted network. And
that is _exactly_ the problem the keywrap draft is solving.

  One thing the IETF does well (in addition to apparently referencing
existing crypto) is take work from outside the IETF and document it in
RFCs. TLS is a perfect example. So is RFC3394. Neither one is "roll your
own" and neither is a proposal to use one of them.

  Dan.

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

Delivery-date: Thu, 09 Aug 2007 21:10:30 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Thu, 9 Aug 2007 17:10:16 -0400
Organization: Elbrys Networks, Inc.

Leif Johansson writes...

> That is absolutely "roll your own" - RFC3394 is AES which is
> crypto not a security protocol.

No.  RFC 3394 is "Advanced Encryption Standard (AES) Key Wrap Algorithm".
That's not simply a definition of AES (crypto), which is normatively defined
in FIPS-197.  It's a specific application of crypto for key wrapping.  It is
not a key agreement, key distribution or key management protocol, of course.

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

Delivery-date: Thu, 09 Aug 2007 20:58:52 +0000
Date: Thu, 09 Aug 2007 22:58:40 +0200
From: Leif Johansson <[email-masked]>
To: Dan Harkins <[email-masked]>
CC: Stefan Winter <[email-masked]>,  Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

Dan Harkins wrote:
>   Hello,
>
> On Wed, August 8, 2007 7:22 am, Leif Johansson wrote:
> [snip]
>   
>> There are two fundamental ways to address this problem: reference
>> some work or roll your own. Radius+DTLS and RadSec fall into the
>> first category, keywrap falls into the second category.
>>     
>
>   I have to disagree. Keywrap is not "roll your own". It uses RFC3394
>   
That is absolutely "roll your own" - RFC3394 is AES which is
crypto not a security protocol. Of course no-one in the IETF
is silly enough not to reference existing crypto :-)

    Cheers Leif

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

Delivery-date: Thu, 09 Aug 2007 20:15:09 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Thu, 9 Aug 2007 16:14:58 -0400
Organization: Elbrys Networks, Inc.

Dan Harkins writes ...

> On Wed, August 8, 2007 7:22 am, Leif Johansson wrote:
> [snip]
> > There are two fundamental ways to address this problem: reference
> > some work or roll your own. Radius+DTLS and RadSec fall into the
> > first category, keywrap falls into the second category.
> 
>   I have to disagree. Keywrap is not "roll your own". It uses RFC3394
> which itself describes a NIST specification of a mode of AES that came
> out of a draft standard from X9.102. It has received extensive vetting.
> The authors of the keywrap draft are proposing to use an existing
> standard to solve the problem it was created to solve-- cryptographically
> protecting keying material in transit.

It would be more accurate to portray the two approaches as (a) wrap all the
PDUs in a secure transport vs. (b) protect individual elements in selected
PDUs, i.e., external (to the protocol) vs. internal (to the protocol)
security.

The other fact to keep in mind is that the protection of keying material
does not address the complete scope of the RADEXT crypto-agility
requirements.  You need to consider both the keywrap draft and the encrypted
attribute draft.

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

Delivery-date: Thu, 09 Aug 2007 20:02:03 +0000
Date: Thu, 9 Aug 2007 13:01:09 -0700 (PDT)
Subject: Re: Continued discussion of RADIUS Crypto-Agility
From: "Dan Harkins" <[email-masked]>
To: "Leif Johansson" <[email-masked]>
Cc: "Stefan Winter" <[email-masked]>, "Bernard Aboba" <[email-masked]>, [email-masked]

  Hello,

On Wed, August 8, 2007 7:22 am, Leif Johansson wrote:
[snip]
> There are two fundamental ways to address this problem: reference
> some work or roll your own. Radius+DTLS and RadSec fall into the
> first category, keywrap falls into the second category.

  I have to disagree. Keywrap is not "roll your own". It uses RFC3394
which itself describes a NIST specification of a mode of AES that came
out of a draft standard from X9.102. It has received extensive vetting.
The authors of the keywrap draft are proposing to use an existing
standard to solve the problem it was created to solve-- cryptographically
protecting keying material in transit.

  Dan.

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

Delivery-date: Thu, 09 Aug 2007 14:47:07 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Continued discussion of RADIUS Crypto-Agility
Date: Thu, 09 Aug 2007 07:46:35 -0700

>This sort of thing is problematic for the IETF - narrowly scoped
>charters can be a tool for delivering on time but it can also be
>a blunt instrument for beating people over the head with.

As Dan has noted, the RADEXT WG has been given leeway to include RADSEC in 
the charter if there is consensus for doing that.

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

Delivery-date: Thu, 09 Aug 2007 14:15:32 +0000
Date: Thu, 09 Aug 2007 16:15:25 +0200
From: Leif Johansson <[email-masked]>
To: Stefan Winter <[email-masked]>
CC: "Glen Zorn (gwz)" <[email-masked]>,  [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

> the end result is getting very close to TCP already. So the distance between 
> in-scope and out-of-scope is a very thin line.
>
>   
This sort of thing is problematic for the IETF - narrowly scoped
charters can be a tool for delivering on time but it can also be
a blunt instrument for beating people over the head with.

    Cheers Leif

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

Delivery-date: Thu, 09 Aug 2007 14:00:41 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: "Glen Zorn \(gwz\)" <[email-masked]>, [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility
Date: Thu, 9 Aug 2007 15:59:44 +0200

--nextPart8245323.VinDj1bgLn
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

> Well, except that in order to place these things in a common category it
> is necessary to ignore one of the defining characteristics of RADIUS:
> that it is only and intentionally defined as a connectionless protocol.

The impact of connectionless vs. connection is not very significant when=20
discussing the protocol's *security*, IMO.

> might like to believe so, RadSec is _not_ RADIUS,

Well, it's _almost_ RADIUS, especially if one takes into account the=20
mechanisms in RADIUS to detect duplication, retransmission etc, which alrea=
dy=20
contains parts of the merits of TCP.

> & therefore far out of=20
> scope of not just the crypto-agility discussions but of this WG.
> RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS &
> therefore _is_ in scope.

I have understood that DTLS is considered in scope, while RadSec is out of=
=20
scope (Reminder: I never claimed otherwise). Just keep in mind that DTLS=20
itself requires even more characteristics of TCP, so when combining the=20
RADIUS mechanisms that come on top of UDP + the transport mechanisms in DTL=
S,=20
the end result is getting very close to TCP already. So the distance betwee=
n=20
in-scope and out-of-scope is a very thin line.

Greetings,

Stefan

=2D-=20
Stefan WINTER

Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e=
t de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked] =A0 =A0 Tel.:  =A0 =A0+352 424409-1
http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0  =A0 Fax: =A0 =A0 =A0+352 422=
473

--nextPart8245323.VinDj1bgLn
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart8245323.VinDj1bgLn--

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

Delivery-date: Thu, 09 Aug 2007 08:14:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Thu, 9 Aug 2007 10:13:27 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Leif Johansson" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Leif Johansson
> Sent: Thursday, August 09, 2007 10:42 AM
> To: Bernard Aboba
> Cc: [email-masked]; [email-masked]
> Subject: Re: Continued discussion of RADIUS Crypto-Agility
>=20
> Bernard Aboba wrote:
> >> The wg should (imho) explicitly state if the issue is=20
> getting rid of=20
> >> MD5 or getting rid of MD5 at the same time as a whole=20
> bunch of other=20
> >> things are done. That will probably make this process go a=20
> whole lot=20
> >> easier.
> >
> > David has posted the set of requirements that a solution needs to=20
> > meet.  Beyond those, the WG can also take into account=20
> other desirable=20
> > security characteristics in making a determination.
> >
> Draft?

There is no I-D if this is what you are asking about, but the
requirements were set in the following message from the WG co-chair:=20

https://ops.ietf.org/lists/radiusext/2007/msg00185.html

Dan

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

Delivery-date: Thu, 09 Aug 2007 07:42:35 +0000
Date: Thu, 09 Aug 2007 09:41:53 +0200
From: Leif Johansson <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

Bernard Aboba wrote:
>> The wg should (imho) explicitly state if the issue is getting rid of MD5
>> or getting rid of MD5 at the same time as a whole bunch of other
>> things are done. That will probably make this process go a whole lot
>> easier.
>
> David has posted the set of requirements that a solution needs to
> meet.  Beyond those, the WG can also take into account other desirable
> security characteristics in making a determination.
>
Draft?
> However, in doing so, I would warn against feature creep.  RADIUS has
> succeeded largely because of its simplicity and modest footprint.  So
> the goal is to address the crypto-agility issue with a minimum of
> unrelated changes.
>
Very wise.

    Cheers Leif

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

Delivery-date: Thu, 09 Aug 2007 00:12:59 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Continued discussion of RADIUS Crypto-Agility
Date: Wed, 08 Aug 2007 17:12:03 -0700

>The wg should (imho) explicitly state if the issue is getting rid of MD5
>or getting rid of MD5 at the same time as a whole bunch of other
>things are done. That will probably make this process go a whole lot
>easier.

David has posted the set of requirements that a solution needs to meet.  
Beyond those, the WG can also take into account other desirable security 
characteristics in making a determination.

However, in doing so, I would warn against feature creep.  RADIUS has 
succeeded largely because of its simplicity and modest footprint.  So the 
goal is to address the crypto-agility issue with a minimum of unrelated 
changes.

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

Delivery-date: Wed, 08 Aug 2007 20:53:48 +0000
Date: Wed, 08 Aug 2007 22:53:17 +0200
From: Leif Johansson <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
CC: Stefan Winter <[email-masked]>,  Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

Glen Zorn (gwz) wrote:
> Stefan Winter <> allegedly scribbled on Wednesday, August 08, 2007 5:06
> AM:
>
>   
>> Hello,
>>
>>     
>>> We can certainly entertain a discussion of whether RADSEC is
>>> appropriate as a RADEXT WG work item.  However, I am not entirely
>>> clear that this question is relevant to the current crypto-agility
>>> discussion (although I'm certainly willing to be convinced
>>> otherwise). 
>>>       
>> I agree that it is not relevant for crypto-agility discussions. As I
>> see it, DTLS and RadSec fall under a common category in this respect:
>> whole packet encryption, with encryption negotiation happening
>> outside of RADIUS.   
>>     
>
> Well, except that in order to place these things in a common category it
> is necessary to ignore one of the defining characteristics of RADIUS:
> that it is only and intentionally defined as a connectionless protocol.
>
>   
A situation not unlike SIP btw which also started as a UDP-based
protocol but which had to evolve in the face of among other
things the requirement to protect the transport in the absence
of deployable s/mime.

Sure SIP could have rolled an in-band security layer but that
would not have helped an already complex protocol. In-band
authentication combined with channel-bindings to a lower
security layer is imo a much simpler and cleaner solution for
most protocols.

    Cheers Leif

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

Delivery-date: Wed, 08 Aug 2007 16:43:37 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Wed, 8 Aug 2007 09:42:32 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Stefan Winter" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Stefan Winter <> allegedly scribbled on Wednesday, August 08, 2007 5:06
AM:

> Hello,
>=20
>> We can certainly entertain a discussion of whether RADSEC is
>> appropriate as a RADEXT WG work item.  However, I am not entirely
>> clear that this question is relevant to the current crypto-agility
>> discussion (although I'm certainly willing to be convinced
>> otherwise).=20
>=20
> I agree that it is not relevant for crypto-agility discussions. As I
> see it, DTLS and RadSec fall under a common category in this respect:
> whole packet encryption, with encryption negotiation happening
> outside of RADIUS.  =20

Well, except that in order to place these things in a common category it
is necessary to ignore one of the defining characteristics of RADIUS:
that it is only and intentionally defined as a connectionless protocol.
This is not an accidental result of the transport choice as you seem to
imply below ("{some transport}+{the equivalent of TLS for that
transport}"), but a fundamental quality of RADIUS itself.  Much as you
might like to believe so, RadSec is _not_ RADIUS, & therefore far out of
scope of not just the crypto-agility discussions but of this WG.
RADIUSoDTLS, OTOH, doesn't alter the fundamental nature of RADIUS &
therefore _is_ in scope.

> Basically everything that falls under {some transport}+{the
> equivalent of TLS for that transport} would fall into this same class
> (i.e. also yet-exotic combinations like DCCP+DTLS or SCTP+TLS would
> be covered). keywrap represents a second, fundamentally different
> class: per-attribute encryption, with encryption negotiation
> happening inside the packet. I guess discussions re the general
> crypto-agility problem could focus on discussing those two classes of
> approach.     =20
>=20
> Greetings,
>=20
> Stefan Winter

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

Delivery-date: Wed, 08 Aug 2007 14:23:19 +0000
Date: Wed, 08 Aug 2007 16:22:52 +0200
From: Leif Johansson <[email-masked]>
To: Stefan Winter <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Continued discussion of RADIUS Crypto-Agility

Stefan Winter wrote:
> Hello,
>
>   
>> We can certainly entertain a discussion of whether RADSEC is appropriate as
>> a RADEXT WG work item.  However, I am not entirely clear that this question
>> is relevant to the current crypto-agility discussion (although I'm
>> certainly willing to be convinced otherwise).
>>     
>
> I agree that it is not relevant for crypto-agility discussions. As I see it, 
>   

I have to disagree. The purpose of the IESG crypto-agility "challenge"
is to get rid of hard dependencies on vulnerable mechanisms, notably
MD5 and to make sure that the current situation wrt to these mechs
don't arise again in the future.

There are two fundamental ways to address this problem: reference
some work or roll your own. Radius+DTLS and RadSec fall into the
first category, keywrap falls into the second category.

There is no doubt that these 3 proposals aren't created equal and
sort differently depending on what problems _besides_ crypto and
hash agility you may want to solve at the same time but they clearly
all solve the basic problem of crypto and hash agility.

The wg should (imho) explicitly state if the issue is getting rid of MD5
or getting rid of MD5 at the same time as a whole bunch of other
things are done. That will probably make this process go a whole lot
easier.

    Cheers Leif

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

Delivery-date: Wed, 08 Aug 2007 12:06:45 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: "Bernard Aboba" <[email-masked]>
Subject: Re: Continued discussion of RADIUS Crypto-Agility
Date: Wed, 8 Aug 2007 14:05:35 +0200
Cc: [email-masked]

--nextPart1294329.xytfafCASa
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

> We can certainly entertain a discussion of whether RADSEC is appropriate =
as
> a RADEXT WG work item.  However, I am not entirely clear that this questi=
on
> is relevant to the current crypto-agility discussion (although I'm
> certainly willing to be convinced otherwise).

I agree that it is not relevant for crypto-agility discussions. As I see it=
,=20
DTLS and RadSec fall under a common category in this respect: whole packet=
=20
encryption, with encryption negotiation happening outside of RADIUS.=20
Basically everything that falls under {some transport}+{the equivalent of T=
LS=20
for that transport} would fall into this same class (i.e. also yet-exotic=20
combinations like DCCP+DTLS or SCTP+TLS would be covered). keywrap represen=
ts=20
a second, fundamentally different class: per-attribute encryption, with=20
encryption negotiation happening inside the packet.
I guess discussions re the general crypto-agility problem could focus on=20
discussing those two classes of approach.

Greetings,

Stefan Winter

=2D-=20
Stefan WINTER

Stiftung RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education Na=
tionale et de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked] =C2=A0 =C2=A0 Tel.:  =C2=A0 =C2=A0+352 424=
409-1
http://www.restena.lu =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0  =C2=A0 Fax=
: =C2=A0 =C2=A0 =C2=A0+352 422473

--nextPart1294329.xytfafCASa
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart1294329.xytfafCASa--

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

Delivery-date: Sat, 04 Aug 2007 20:24:29 +0000
Date: Sat, 04 Aug 2007 22:23:41 +0200
From: Leif Johansson <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked],  [email-masked]
Subject: Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap

Bernard Aboba wrote:
>>   Crypto-agility isn't just the ability to substitute one algorithm for
>> another, it should include the jettisoning any unnecessary baggage that
>> might've been appropriate (or required) for one algorithm if it's not
>> appropriate (or required) for another.
>
> Let's just say that crypto-agility includes negotiation of parameters
> relating to the cryptographic algorithms, as well as the algorithms
> themselves.
>
> One question that I'd like to understand is the extent to which the
> negotiation can be protected in either of the proposals.
>
> WIth DTLS, in the absence of DNSSEC, I think that an attacker in the
> middle could subvert the DTLS up-negotiation, so as to cause a client
> and server that support DTLS to negotiate plain RADIUS.  So some sort
> of policy pre-configuration is required (e.g. RADIUS server requires
> DTLS on these NASes).  With DNSSEC, it is possible to specify whether
> a NAS/Server supports DTLS in a DNS SRV RR, so it seems like protected
> negotiation would be possible.
>
> I'm not sure about the level of protection provided in draft-zorn.
>
>
This problem crops up whenever a server-announced parameter needs
to be negotiated securely (for instance SASL mechanisms). What you
need to do, unless you can actually protect the parameter, is to verify
the parameter against the first set you received from the server _after_
you negotiate a secure channel, and complain if it doesn't match.

For instance, if your server was once DTLS and now isn't your client
should not silently accept a "downgrade". This requires a basic leap-of-
faith that the first negotiation was either non-intercepted or
determined by policy.

    Cheers Leif

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

Delivery-date: Sat, 04 Aug 2007 13:29:34 +0000
Date: Sat, 04 Aug 2007 17:28:37 +0400
From: Victor Gamov <[email-masked]>
To: [email-masked]
Subject: Re: Internet Draft: RadSec - RADIUS over TCP+TLS

Stefan Winter wrote:
> Hello!
> 
> My name is Stefan Winter of the Luxembourg Research and Education Network.
> Together with Stig Venaas (Norwegian REN) and Mike McCauley from Open Systems 
> Consultants (creators of the Radiator RADIUS server) I have created an 
> internet draft describing two implementations of a transport profile for 
> RADIUS that transports the RADIUS payload over a TCP+TLS link.

(sorry for late response)

Hi Stefan!

I work with RADIUS protocol about 10 years and question "why UDP not 
TCP" is the biggest question without answer for me (yes I red RFC286 
part 2.4).

When I thinking about "UDP vs TCP" I found many arguments for TCP 
advantages like produced by your draft so I agree with it.

I think that this draft is a good start point to think about new 
transport for RADIUS. (and may be to prepare new version of this simply 
and nice protocol without current problems even)

-- 
CU,
Victor Gamov

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

Delivery-date: Sat, 04 Aug 2007 01:34:25 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Request for Review: "Issues and Fixes" changes
Date: Fri, 03 Aug 2007 18:33:44 -0700

Here is my review of the "Issues and Fixes" changes (taken from a diff of 
-04 and -05):

<    A State attribute is REQUIRED in Access-Request packets neither
<    including an authentication attribute nor a Service-Type attribute
<    with the value Call Check (10).
<
<
<
---
>    As defined in [RFC 2865] Table 5.44, Access-Request packets MAY
>    contain a State attribute.  We extend that definition here, to say
>    that Access-Request packets that contain an authentication attribute
>    or a Service-Type attribute with the value Call Check (10) MAY
>    contain a State attribute.  Access-Request packets not matching the
>    above description MUST contain a State attribute.

Does it make sense to include a State attribute in an Access-Request with
a Service-Type attribute with value Call Check (10)?  Typically in these 
cases there
is no state to encode.

I'd rewrite this as follows:

As noted [RFC 2865] Table 5.44, Access-Request packets MAY
contain a State attribute.  An Access-Request packet not containing
an authentication attribute or a Service-Type attribute with a value of
Call Check (10) MUST contain a State attribute.   If an authentication
attribute is present, then a State Attribute MAY be included.

Section 2.2.1

I think this section needs to note that the suggested algorithms apply not 
only to a RADIUS client, but also to a Dynamic Authorization Client, defined 
in RFC 3576bis.  Either that, or the algorithm text needs to be transplanted 
into RFC 3576bis.

     Congestive backoff.  While it is not necessary for RADIUS client
     implementations to implement complex retransmission algorithms,
     implementations SHOULD support congestive backoff within the limits
     suggested by [RFC2865] Section 2.4.

     RADIUS retransmission timers are based on the model used in DHCPv6
     [RFC3315].  Variables used here are also borrowed from this
     specification.  RADIUS is a request/response-based protocol.  The
     message exchange terminates when the requester successfully
     receives the answer or the message exchange is considered to have
     failed according to the retransmission mechanism described below.

Is the retransmission algorithm OPTIONAL or RECOMMENDED?  The first 
paragraph seems to suggest that only congestive backoff is RECOMMENDED, and 
that the rest of the text is non-normative.  Is that what is intended?  I'd 
suggest that we say something like "A potential retransmission algorithm is 
included below" to make that that clear, if that is what is meant.

     MRD specifies an upper bound on the length of time a sender may
     retransmit a message.  The message exchange fails once MRD seconds
     have elapsed since the client first transmitted the message.  MRD
     MUST be set, and SHOULD have a value between 5 and 30 seconds.
     These values mirror the values for a servers duplicate detection
     cache, as described in the next section.

     MRC specifies an upper bound on the number of times a sender may
     retransmit a message.  if MRC is zero, the message exchange fails
     once MRD seconds have elapsed since the client first transmitted
     the message.  If MRC is non-zero, the message exchange fails when
     the either the sender has transmitted the message MRC times, or
     when MRD seconds have elapsed since the client first transmitted
     the message.

This could have some unforseen (and potentially adverse) impacts on RADIUS 
accounting.  Today, some RADIUS accounting clients continue to retransmit 
for long periods of time, intentionally, in order to improve reliability.  
If there is an upper bound on the number of times a sender may retransmit an 
accounting message, then accounting messages could be lost in situations 
where today they would be delivered.  So I think this needs to be changed.

Section 2.5

The issue that this section is attempting to address is the seeming 
contradiction between
[RFC2865] Section 1.1 which states:

      A NAS that does not implement a given service MUST NOT implement
      the RADIUS attributes for that service.  For example, a NAS that
      is unable to offer Apple Remote Access Protocol (ARAP) service
      MUST NOT implement the RADIUS attributes for ARAP.  A NAS MUST
      treat a RADIUS access-accept authorizing an unavailable service as
      an access-reject instead.

and [RFC2865] Section 5 which states:

      A RADIUS server MAY ignore Attributes with an unknown Type.
      A RADIUS client MAY ignore Attributes with an unknown Type.

As I recall, the conclusion was that the advice of Section 1.1 applies to 
known attributes, so that if a NAS receives an attribute that is known and 
represents a service, but is not implemented, it is treated as an 
Access-Reject.  Whereas if the attribute is not known, then it MAY be 
ignored.

The question was then what the behavior is for a NAS encountering an unknown 
attribute.  Given the MAY in Section 5,  behavior can only be recommended, 
not mandated, because of backward compatibility.

   It is possible for either a standard attribute or VSA to represent a
   request for an unavailable service.  However, where the Type or
   Vendor-ID is unknown, a RADIUS client will not know whether the
   attribute defines a service or not.

[BA] Actually the problem could also arise if the Vendor-ID is known, but 
the Vendor Type is not, right?

   In general, it is best for RADIUS clients to err on the side of
   caution.  On receiving an Access-Accept including an attribute of
   unknown Type, a RADIUS client SHOULD assume that it is a potential
   service definition, and treat it as an Access-Reject.  Unknown VSAs
   SHOULD be ignored by RADIUS clients.

[BA] My recommendation would be to add a clarification of the meaning of 
Section 1.1:

In general, it is best for a RADIUS clients to err on the side of caution.  
On receiving an
Access-Accept including an attribute of known Type for an unimplemented 
service, a RADIUS client MUST treat it as an Access-Reject, as directed in 
[RFC2865] Section 1.1.  On receiving an Access-Accept including an attribute 
of unknown Type, a RADIUS client SHOULD assume that it is a potential 
service definition, and treat it as an Access-Reject.   Unknown VSAs SHOULD 
be ignored by RADIUS clients.

   As there may be interoperability issues with the above suggestion,
   client implementations SHOULD make the suggested behavior
   configurable.  A configuration flag such as "treat unknown attributes
   as reject" can be exposed to the system administrator.  If the flag
   is set to true, then Access-Accepts containing unknown attributes are
   treated as Access-Rejects.  If the flag is set to false, then unknown
   attributes in Access-Accepts are be silently ignored. The default
   value for the flag SHOULD be set to true.

I think what we are trying to say here is that existing implementations that 
ignore unknown attributes should probably not change to treating them as an 
Access-Reject by default, or else on upgrading the NAS, the users could see 
an unexpected change in behavior.  In this situation, configuration would be 
helpful, but the legacy behavior should be the default, probably.  However, 
where the existing implementation already implements the recommended 
behavior, there is no point in introducing configuration.  Here is a 
recommended rewrite:

In order to avoid introducing changes in default behavior, existing 
implementations that do not obey this recommendation should make the 
behavior configurable, with the legacy behavior being enabled by default. A 
configuration flag such as "treat unknown attributes as reject" can be 
exposed to the system administrator.  If the flag is set to true, then 
Access-Accepts containing unknown attributes are treated as Access-Rejects.  
If the flag is set to false, then unknown
attributes in Access-Accepts are be silently ignored.

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

Delivery-date: Sat, 04 Aug 2007 00:39:07 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for Review: "Issues and Fixes" changes
Date: Fri, 03 Aug 2007 17:37:57 -0700

In response to IESG comments, the "Issues and Fixes" document has been 
updated:

http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-05.txt

This version contains significant changes, including:

1. Addition of a suggested retransmission algorithm (Section 2.2.1)
2. Changes to RADIUS client and server processing of unknown attributes 
(Section 2.5)

Given these changes, we are requesting that RADEXT WG participants review 
the document carefully.

The request for review will last until August 17, 2007.  Please post your 
comments to the RADEXT WG mailing list in the format described on the RADEXT 
Issues list:
http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Fri, 03 Aug 2007 12:31:36 +0000
Date: Fri, 03 Aug 2007 08:30:27 -0400
From: Alan DeKok <[email-masked]>
To: Stefan Winter <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Crypto-agility requirement and  draft-zorn-radius-encattr/draft-zorn-radius-keywrap

Stefan Winter wrote:
>>   Yes.  The failure cases for DTLS negotiation are:
>>
>>   a) server doesn't support DTLS (and thinks it's a bad RADIUS packet)
>>   b) server is slow / down
>>   c) attacker is faking (a) or (b)
> 
> d) the network is unreliable and drops some negotiation datagrams?

  Which is indistinguishable from (b).

  Alan DeKok.

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

Delivery-date: Thu, 02 Aug 2007 16:27:08 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Thu, 02 Aug 2007 09:26:41 -0700

>Yes, at the same time Working Group meetings and mail lists can discuss
>items that are candidates for future work. This includes items that do
>not belong strictly within a current charter, but may become part of an
>extended charter later.

We can certainly entertain a discussion of whether RADSEC is appropriate as 
a RADEXT WG work item.  However, I am not entirely clear that this question 
is relevant to the current crypto-agility discussion (although I'm certainly 
willing to be convinced otherwise).

For practical reasons, the discussion has primarily centered on mechanisms 
applying to the RADIUS protocol as defined in RFC 2865.  Virtually all 
RADIUS implementations today are based on UDP, and this is likely to remain 
the case for the forseeable future.  Therefore, unless we think it is likely 
that RADIUS will migrate to TCP transport *exclusively*, then a 
crypto-agility solution needs to be provided for UDP transport as well.  As 
a result, RADSEC cannot be considered a solution to the RADIUS 
crypto-agility problem as currently posed, though perhaps a combination of 
DTLS and RADSEC could qualify.

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

Delivery-date: Thu, 02 Aug 2007 16:20:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Review of draft-nelson-radius-management-authorization-05.txt
Date: Thu, 02 Aug 2007 09:19:39 -0700

The ISMS WG has requested that RADEXT WG take on "Remote Authentication 
Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) 
Management" as a WG work item.

In response to this request, we are requesting reviews of the document, 
which is found here:
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-05.txt

The request for review will last until August 16, 2007.  Please indicate 
whether you would like this document to be taken on as a WG work item.  
Please respond even if you have no issues with the document; if you have 
comments, please send the issues to the RADEXT WG mailing list in the format 
provided on here:
http://www.drizzle.com/~aboba/RADEXT/

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

Delivery-date: Thu, 02 Aug 2007 11:14:52 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Thu, 2 Aug 2007 13:13:37 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Stephen Hanna" <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Stephen Hanna

>=20
> I have asked Juniper's RADIUS experts to join us for this=20
> discussion. They should be here within a few hours. Sorry for=20
> the delay.
>=20

Just as a friendly note - anybody joining the discussion is welcome, but
discussions in IETF are being conducted among individuals, not among
experts representing companies.=20

Dan

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

Delivery-date: Thu, 02 Aug 2007 11:02:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Thu, 2 Aug 2007 13:01:23 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

=20

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]]=20
> Sent: Wednesday, August 01, 2007 11:07 PM
> To: Romascanu, Dan (Dan); David B. Nelson
> Cc: [email-masked]
> Subject: RE: Continued discussion of RADIUS Crypto-Agility
>=20
> Romascanu, Dan (Dan) <mailto:[email-masked]> allegedly=20
> scribbled on Wednesday, August 01, 2007 10:12 AM:
>=20
> ...
>=20
> > Seriously, I was the one to recommend the author to ask for a time=20
> > slot on the RADEXT agenda. I believe that the RADSEC work is if not=20
> > within at least related to the WG scope (but not necessarily as a=20
> > crypto-agility solution), although undertaking it would mean an=20
> > extension of the charter.
>=20
> OK, I'm confused: the scope of a WG is _not_ defined by its=20
> charter?  If the charter doesn't define the scope of a WG, what does?
>=20

Yes, at the same time Working Group meetings and mail lists can discuss
items that are candidates for future work. This includes items that do
not belong strictly within a current charter, but may become part of an
extended charter later.=20

Dan

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

Delivery-date: Thu, 02 Aug 2007 06:39:13 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: Alan DeKok <[email-masked]>
Subject: Re: Crypto-agility requirement and  draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Thu, 2 Aug 2007 08:39:01 +0200
Cc: Bernard Aboba <[email-masked]>, [email-masked]

--nextPart1706593.6ueWxZqrgU
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

>   Yes.  The failure cases for DTLS negotiation are:
>
>   a) server doesn't support DTLS (and thinks it's a bad RADIUS packet)
>   b) server is slow / down
>   c) attacker is faking (a) or (b)

d) the network is unreliable and drops some negotiation datagrams?

=2D-=20
Stefan WINTER

Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e=
t de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked] =A0 =A0 Tel.:  =A0 =A0+352 424409-1
http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0  =A0 Fax: =A0 =A0 =A0+352 422=
473

--nextPart1706593.6ueWxZqrgU
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart1706593.6ueWxZqrgU--

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

Delivery-date: Thu, 02 Aug 2007 05:06:19 +0000
Date: Thu, 02 Aug 2007 01:05:30 -0400
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>,  [email-masked]
Subject: Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap

Bernard Aboba wrote:
> WIth DTLS, in the absence of DNSSEC, I think that an attacker in the
> middle could subvert the DTLS up-negotiation, so as to cause a client
> and server that support DTLS to negotiate plain RADIUS.

  Yes.  The failure cases for DTLS negotiation are:

  a) server doesn't support DTLS (and thinks it's a bad RADIUS packet)
  b) server is slow / down
  c) attacker is faking (a) or (b)

>  So some sort of
> policy pre-configuration is required (e.g. RADIUS server requires DTLS
> on these NASes).  With DNSSEC, it is possible to specify whether a
> NAS/Server supports DTLS in a DNS SRV RR, so it seems like protected
> negotiation would be possible.

  Yes.

  If the NAS has a static server certificate configured for DTLS, it can
assume that this means the server supports DTLS.  If the server accepts
"known" NASes by certificate rather than by IP, an attacker can start
many DTLS sessions.  This may DoS the server.

  Alan DeKok.

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

Delivery-date: Thu, 02 Aug 2007 04:40:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635
Date: Wed, 1 Aug 2007 23:40:10 -0500
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

David,

I copied Stephan on the mail, as he asked to be contacted for any
follow-up questions.=20
With respect to being compatible to Open Source, what is meant is that
Nokia will not
assert its patents against open source implementations (as far as I
know), though
Stephan can correct me.

John

>-----Original Message-----
>From: ext David B. Nelson [mailto:[email-masked]]=20
>Sent: 01 August, 2007 20:40
>To: Loughney John (Nokia-NRC/PaloAlto); [email-masked];=20
>[email-masked]
>Subject: RE: Nokia Patent discussion FW: [Dime] First results=20
>on Diameter vs. RadSec patent research:EP1147635
>
>> Non-assert statements like this are widely used in the IETF, as they=20
>> are believed to provide sufficient defensive protection for=20
>the owner,=20
>> while still allowing implementers and users to exercise the=20
>protected=20
>> technology without a license and for free, as long as they behave=20
>> similarly nice...
>
>It is true that "non-assert" IPR statements are frequently=20
>issued these days.
>
>> In that, non-asserts are believed to be compatible with most open=20
>> source licenses.
>
>Compatible?  What does that mean?
>
>A reciprocal non-assert is not quite the same thing as open=20
>source.  Open source has to do with copyright IPR, not patent=20
>IPR.  Additionally, reciprocal non-asserts would appear to=20
>apply to all patents that an organization may hold, not only=20
>those that are related to standards.  In that regard, it is=20
>tantamount to an implicit (and broad) cross-licensing=20
>agreement, which would include patents covering proprietary=20
>technology as well as open standards based technology.
>
>Still, it is better than nothing, and very useful to companies=20
>that don't intend to enforce _any_ of their patent portfolio=20
>against infringement by the non-assert grantors.  Of course,=20
>it also works out fine for companies that don't have patents=20
>to enforce.  :-)
>
>Standard disclaimer: I am not a lawyer.
>
>
>

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

Delivery-date: Thu, 02 Aug 2007 04:25:21 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 01 Aug 2007 21:24:24 -0700

>The fact that implementations of earlier
>versions of our draft (of necessity using vendor-specific
>equivalents to the attributes defined in the draft) have been
>certified by NIST obviously does not entail (or even imply)
>that the final product of this WG will also be thus
>certifiable, even if it is based upon our work...
>If our draft is chosen as the basis for the radext
>crypto-agility work, it will certainly be changed

Given that the current document describes existing implementations,  it 
would probably make sense to publish it as an RFC, utilizing the VSAs that 
are actually used.  That way, there would be no confusion between that RFC 
implementation documentation and another, evolving document utilizing IETF 
standards space attributes.

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

Delivery-date: Thu, 02 Aug 2007 02:04:22 +0000
Date: Wed, 1 Aug 2007 19:03:53 -0700 (PDT)
Subject: RE: Crypto-agility requirement and  draft-zorn-radius-encattr/draft-zorn-radius-keywrap
From: "Dan Harkins" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]

  Hi Bernard

On Wed, August 1, 2007 6:16 pm, Bernard Aboba wrote:
[snip]
> I'm not clear why the KEK ID or KM ID is a covert channel any more than
> the
> IPsec SPI is a covert channel in the case where manual keying is used.

  A SPI for IPsec (manual keying or not) uniquely identifies necessary
context (the SA) to process the IPsec packet. It's possible that
different SAs could apply to different selectors and therefore have
different processessing requirements as well as different keys.

  The KEK ID does not identify necessary context to process a RADIUS
message because the draft only defines one addition key for use as a KEK
so that's all the context you need-- you implemented the draft you know
what the KEK is, it's the one you added to implement the draft. No need
to further identify it.

  The KM ID does not identify necessary context because the App ID says
what the particular key is. It's either an EAP-MSK or an EAP-EMSK or
an ERX-rMSK or an 11r-PMK or whatever. Sending multiple EAP-MSKs or
multiple ERX-rMSKs or muultiple 11r-PMKs in a single message to a
single RADIUS client for a single peer does not seem to be a requirement
of any EAP method or any application (HOKEY, 11i, etc) so there's no
need to further identify the key.

  The point being that there is nothing that could take the place of the
SPI to identify an IPsec SA but there is something that could take the
place of a KEK ID to identify a KEK (implicit context) and there is
something that could take the place of a KM ID to identify the keying
material being disclosed (App ID).

> However, two other questions come to mind:
>
> 1. As I understood it, the need for an explicit RADIUS shared secret name
> arises from the potential for key rollover and dynamic key management.
> Given the use of AES as the algorithm, is rollover support really
> necessary?

  I think the number of AES key wraps that can be safely done with a
single KEK is 2^48. I don't think that's a limit we need to worry
about. We could do one per second for 8.9 million years before we reach
the "unsafe" point.

>    Also, is there really a need for dynamic key management?  If not, could
> we get by with the RADIUS shared secret key naming scheme (using the IP
> addresses of the client and server as the key name)?

  Yes, that is the key name of the KEK. And the name of the KM is "<app-id>
for <foo>" where <app-id> is the identity in the App ID field and <foo> is
the username of the peer being authenticated. There is no need for a KEK ID
and a KM ID unless you want to send some information over a covert
channel.

  Dan.

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

Delivery-date: Thu, 02 Aug 2007 01:28:49 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 01 Aug 2007 18:28:22 -0700

>   Crypto-agility isn't just the ability to substitute one algorithm for
>another, it should include the jettisoning any unnecessary baggage that
>might've been appropriate (or required) for one algorithm if it's not
>appropriate (or required) for another.

Let's just say that crypto-agility includes negotiation of parameters 
relating to the cryptographic algorithms, as well as the algorithms 
themselves.

One question that I'd like to understand is the extent to which the 
negotiation can be protected in either of the proposals.

WIth DTLS, in the absence of DNSSEC, I think that an attacker in the middle 
could subvert the DTLS up-negotiation, so as to cause a client and server 
that support DTLS to negotiate plain RADIUS.  So some sort of policy 
pre-configuration is required (e.g. RADIUS server requires DTLS on these 
NASes).  With DNSSEC, it is possible to specify whether a NAS/Server 
supports DTLS in a DNS SRV RR, so it seems like protected negotiation would 
be possible.

I'm not sure about the level of protection provided in draft-zorn.

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

Delivery-date: Thu, 02 Aug 2007 01:20:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 01 Aug 2007 18:20:10 -0700

>Attribute grouping.  The reason why the various key IDs, etc. are all
>part of the Keying-Material attribute is because they need to be
>associated w/a specific key (it's possible to deliver more than one key
>in a single message).  Attribute grouping enables that association w/out
>requiring the multiple sub-attribute technique that we use.

This would be helpful for several reasons:

1. It would avoid a discussion of the merits/demerits of complex attributes.

2. It would disentangle discussion of the keywrap mechanism (which doesn't 
seem to have encountered objections) from the key naming issue.

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

Delivery-date: Thu, 02 Aug 2007 01:17:12 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 01 Aug 2007 18:16:09 -0700

>Since AES Key Wrap is the only one specified & SIV doesn't actually
>exist as a standard, this doesn't make much sense to me.

Since the proposal supports negotiation, SIV could be supported in the 
future, once it is specified.

>Actually, this is largely irrelevant: the purpose of the Mac-Randomizer
>is to facillitate the use of the Message-Authentication-Code in
>accounting & CoA messages.  It is actually independent of the
>Keying-Material attribute.  I suppose that we could further specify it
>as only required if the Message-Authenticator-Attribute is used in one
>of those messages...

The Mac-Randomizer is designed to prevent against replay where RADIUS 
doesn't provide that protection, correct?

> >   - not everyone is comfortable with massive covert channels like KEK
> >     ID and KM ID. I suggest making them optional and using a bit it
> >     the reserved field to indicate their presense or absense.
>
>So having optional "massive covert channels" is somehow better?  Why?

I'm not clear why the KEK ID or KM ID is a covert channel any more than the 
IPsec SPI is a covert channel in the case where manual keying is used.

However, two other questions come to mind:

1. As I understood it, the need for an explicit RADIUS shared secret name 
arises from the potential for key rollover and dynamic key management.  
Given the use of AES as the algorithm, is rollover support really necessary? 
   Also, is there really a need for dynamic key management?  If not, could 
we get by with the RADIUS shared secret key naming scheme (using the IP 
addresses of the client and server as the key name)?

2. There is also the question of compatibility with the keying naming scheme 
in the EAP Key Management Framework document as well as in the RADIUS ERX 
proposal.  Couldn't we just wrap the MSK and send the MSK key name 
separately as specified in RFC 4072?

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

Delivery-date: Wed, 01 Aug 2007 23:04:31 +0000
Date: Wed, 1 Aug 2007 16:04:05 -0700 (PDT)
Subject: RE: Crypto-agility requirement and       draft-zorn-radius-encattr/draft-zorn-radius-keywrap
From: "Dan Harkins" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: "Dan Harkins" <[email-masked]>, "David B. Nelson" <[email-masked]>, [email-masked]

  Yea, I get it Glen. But if you have different App IDs then the that
field is used to identify different wrapped keys in the same message
("here's an EAP-MSK for <foo> and an EAP-EMSK for <foo>"). The KM ID still
serves no purpose.

  Dan.

On Wed, August 1, 2007 3:43 pm, Glen Zorn (gwz) wrote:
> Dan Harkins <mailto:[email-masked]> allegedly scribbled on
> Wednesday, August 01, 2007 3:35 PM:
>
>>   Hi Glen,
>>
>>   That's very interesting. The App ID field only defines an EAP-MSK.
>
> That's extensible, Dan.
>
> ...
>

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

Delivery-date: Wed, 01 Aug 2007 22:43:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility requirement and      draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 15:43:00 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Dan Harkins" <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, <[email-masked]>

Dan Harkins <mailto:[email-masked]> allegedly scribbled on
Wednesday, August 01, 2007 3:35 PM:

>   Hi Glen,
>=20
>   That's very interesting. The App ID field only defines an EAP-MSK.

That's extensible, Dan.

...

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

Delivery-date: Wed, 01 Aug 2007 22:35:22 +0000
Date: Wed, 1 Aug 2007 15:34:53 -0700 (PDT)
Subject: RE: Crypto-agility requirement and  draft-zorn-radius-encattr/draft-zorn-radius-keywrap
From: "Dan Harkins" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: "David B. Nelson" <[email-masked]>, [email-masked]

  Hi Glen,

  That's very interesting. The App ID field only defines an EAP-MSK.
I can see how a KEK ID could indicate what key was used to encrypt
this EAP-MSK if the client and server had more than one KEK. I don't see
a point in having more than one KEK and since your draft only adds one
key to be used as a KEK (the other key it adds is for integrity
protection) the KEK ID seems extranneous. But KEK ID aside, having
multiple KM IDs would imply that there are more than one EAP-MSK being
disclosed in a single message. What EAP methods produce more than one
MSK that would require having different KM IDs but the same App ID in a
single message?

  Dan.

On Wed, August 1, 2007 3:09 pm, Glen Zorn (gwz) wrote:
> David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007
> 2:56 PM:
>
> ...
>
>>> ...the first thing _I_ think should be done is to modify the
>>> attributes to align with the attribute extension work...
>>
>> What properties of the extended attribute format are particularly
>> attractive for the crypto-agility work?
>
> Attribute grouping.  The reason why the various key IDs, etc. are all
> part of the Keying-Material attribute is because they need to be
> associated w/a specific key (it's possible to deliver more than one key
> in a single message).  Attribute grouping enables that association w/out
> requiring the multiple sub-attribute technique that we use.
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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

Delivery-date: Wed, 01 Aug 2007 22:10:22 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 15:09:53 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007
2:56 PM:

...

>> ...the first thing _I_ think should be done is to modify the
>> attributes to align with the attribute extension work...
>=20
> What properties of the extended attribute format are particularly
> attractive for the crypto-agility work?=20

Attribute grouping.  The reason why the various key IDs, etc. are all
part of the Keying-Material attribute is because they need to be
associated w/a specific key (it's possible to deliver more than one key
in a single message).  Attribute grouping enables that association w/out
requiring the multiple sub-attribute technique that we use.

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

Delivery-date: Wed, 01 Aug 2007 21:58:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 14:57:59 -0700
From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
To: "Glen Zorn \(gwz\)" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

When working on the key wrap draft we did consider crypto-agility,
however we did not spend much time thinking about authenticating ciphers
that Dan is referring to.  =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Glen Zorn (gwz)
> Sent: Wednesday, August 01, 2007 2:46 PM
> To: David B. Nelson
> Cc: [email-masked]
> Subject: RE: Crypto-agility requirement and=20
> draft-zorn-radius-encattr/draft-zorn-radius-keywrap
>=20
> David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007
> 1:28 PM:
>=20
> > Dan Harkins writes...
> >=20
> >> If you're submitting a draft that only does AES Key wrap with no=20
> >> capability to substitute anything else then you can mandate other=20
> >> attributes that may be necessary. This isn't crypto-agile though.
> >=20
> > That's a good point.  True crypto-agility is about modularly=20
> > interchangeable cipher suites, not simply replacing a fixed, but=20
> > compromised, cipher suite with another fixed, but currently robust,=20
> > cipher suite.
>=20
> I guess that I haven't been a model of clarity here ;-); I=20
> apologize & will try to clarify things now.  This draft has=20
> been around for a long time, long enough I think that the=20
> term "crypto-agility" didn't exist when the work was begun. =20
> The purpose of our work was to enable the use of IEEE 802.11i=20
> networks in FIPS 140-2 environments, while providing a higher=20
> level of security RADIUSoIPsec.  We accomplished that goal.
> Again, although we made provisions for variations in the=20
> cryptographic algorithms used, crypto-agility was _not_ a=20
> primary goal.  The fact that implementations of earlier=20
> versions of our draft (of necessity using vendor-specific=20
> equivalents to the attributes defined in the draft) have been=20
> certified by NIST obviously does not entail (or even imply)=20
> that the final product of this WG will also be thus=20
> certifiable, even if it is based upon our work.  I think that=20
> what it _does_ say is that our overall approach is valid.  If=20
> our draft is chosen as the basis for the radext=20
> crypto-agility work, it will certainly be changed: the first=20
> thing _I_ think should be done is to modify the attributes to=20
> align with the attribute extension work, which (along with=20
> some minor editorial
> adjustments) take care of Dan's concerns.  Of course, that=20
> would be up to WG consensus: the point I'm trying to make is=20
> that there's no need to worry about backward compatibility=20
> with existing implementations of our draft going forward=20
> since (whether it is accepted or not) we will likely publish=20
> an Informational RFC including the actual VSAs used in the=20
> implementation, purely for the convenience of other vendors=20
> that might wish to build their own version of the existing protocol.
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Wed, 01 Aug 2007 21:55:28 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 17:55:38 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> This draft has been around for a long time, long enough I think 
> that the term "crypto-agility" didn't exist when the work was begun.

Quite possibly.

> The purpose of our work was to enable the use of IEEE 802.11i
> networks in FIPS 140-2 environments...

Yep.

> ...the first thing _I_ think should be done is to modify the 
> attributes to align with the attribute extension work...

What properties of the extended attribute format are particularly attractive
for the crypto-agility work?

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

Delivery-date: Wed, 01 Aug 2007 21:48:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 14:48:07 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007
2:10 PM:

> Glen Zorn writes...
>=20
>> ...the person @ Cisco who does is OOF...
>=20
> OOF?

Sorry, a Microsoft-ism, I guess: Out of the OFfice.

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

Delivery-date: Wed, 01 Aug 2007 21:45:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 14:45:32 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007
1:28 PM:

> Dan Harkins writes...
>=20
>> If you're submitting a draft that only does AES Key wrap with no
>> capability to substitute anything else then you can mandate other
>> attributes that may be necessary. This isn't crypto-agile though.
>=20
> That's a good point.  True crypto-agility is about modularly
> interchangeable cipher suites, not simply replacing a fixed, but
> compromised, cipher suite with another fixed, but currently robust,
> cipher suite.=20

I guess that I haven't been a model of clarity here ;-); I apologize &
will try to clarify things now.  This draft has been around for a long
time, long enough I think that the term "crypto-agility" didn't exist
when the work was begun.  The purpose of our work was to enable the use
of IEEE 802.11i networks in FIPS 140-2 environments, while providing a
higher level of security RADIUSoIPsec.  We accomplished that goal.
Again, although we made provisions for variations in the cryptographic
algorithms used, crypto-agility was _not_ a primary goal.  The fact that
implementations of earlier versions of our draft (of necessity using
vendor-specific equivalents to the attributes defined in the draft) have
been certified by NIST obviously does not entail (or even imply) that
the final product of this WG will also be thus certifiable, even if it
is based upon our work.  I think that what it _does_ say is that our
overall approach is valid.  If our draft is chosen as the basis for the
radext crypto-agility work, it will certainly be changed: the first
thing _I_ think should be done is to modify the attributes to align with
the attribute extension work, which (along with some minor editorial
adjustments) take care of Dan's concerns.  Of course, that would be up
to WG consensus: the point I'm trying to make is that there's no need to
worry about backward compatibility with existing implementations of our
draft going forward since (whether it is accepted or not) we will likely
publish an Informational RFC including the actual VSAs used in the
implementation, purely for the convenience of other vendors that might
wish to build their own version of the existing protocol.

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

Delivery-date: Wed, 01 Aug 2007 21:09:42 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 17:09:39 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> ...the person @ Cisco who does is OOF...

OOF?

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

Delivery-date: Wed, 01 Aug 2007 20:58:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 13:58:00 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007
1:09 PM:

> Glen Zorn writes...
>=20
>> There are multiple interoperable implementations which have been NIST
>> (& at in least one case) Common Criteria certified, however, so we'll
>> just be leaving it as is for now.
>=20
> I has previously asked if information on the implementations and the
> certifications you mention could (and would) be made available to the
> WG.  I didn't get a response, so I'll ask again.=20

Since I don't deal with government affairs or crypto validation & the
person @ Cisco who does is OOF, I am unable to provide detailed
information on the certifications at this time.  The independent
implementations are by 3eTI & Cisco & I believe that the certifications
include FIPS 140-2.
=20
>=20
> Since the "certifyability" seems to be a selling point for this
> approach, it seems relevant for the WG to evaluate that information,
> in deciding on a solution.=20

If the WG can actually evaluate that information they are better humans
than I ;-).  However, I would think that anybody qualified to evaluate
it (that's not me) would be able to find it (also not me, but I do know
it's somewhere on the NIST Web site).=20

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

Delivery-date: Wed, 01 Aug 2007 20:42:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Wed, 1 Aug 2007 13:42:15 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Stephen Hanna" <[email-masked]>, "Romascanu, Dan \(Dan\)" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

Stephen Hanna <mailto:[email-masked]> allegedly scribbled on
Wednesday, August 01, 2007 10:32 AM:

> Thanks, Dan. I'm glad you did suggest that we consider the RADSEC
> work.=20

> Now we can consider the alternatives on their technical merits

Hang on a minute, here.  This is absolutely NOT "an alternative" for the
crypto-agility work.

> and set aside the charter or process questions for the moment (to be
> revisited if necessary).  =20
>=20
> I have asked Juniper's RADIUS experts to join us for this discussion.

Since it is pretty painfully obvious that RADSEC is NOT RADIUS, what
will they have to say?

> They should be here within a few hours. Sorry for the delay.=20
>=20
> Thanks,
>=20
> Steve
>=20

...

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

Delivery-date: Wed, 01 Aug 2007 20:28:04 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 16:28:19 -0400
Organization: Elbrys Networks, Inc.

Dan Harkins writes...

> If you're submitting a draft that only does AES Key wrap with no
> capability to substitute anything else then you can mandate other
> attributes that may be necessary. This isn't crypto-agile though.

That's a good point.  True crypto-agility is about modularly interchangeable
cipher suites, not simply replacing a fixed, but compromised, cipher suite
with another fixed, but currently robust, cipher suite.

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

Delivery-date: Wed, 01 Aug 2007 20:26:43 +0000
Date: Wed, 1 Aug 2007 13:26:19 -0700 (PDT)
Subject: RE: Crypto-agility requirement and  draft-zorn-radius-encattr/draft-zorn-radius-keywrap
From: "Dan Harkins" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Cc: [email-masked]

  I agree completely. I'd also request that, to the fullest extent
possible, this information address some of the more unexplained parts of
the draft, like key ids. If NIST requires a KEK ID and a KM ID as well
as (the more obvious requirement of) using an approved cipher in an
approved mode then I'd like to know why.

  Dan.

On Wed, August 1, 2007 1:08 pm, David B. Nelson wrote:
> Glen Zorn writes...
>
>> There are multiple interoperable implementations which
>> have been NIST (& at in least one case) Common Criteria certified,
>> however, so we'll just be leaving it as is for now.
>
> I has previously asked if information on the implementations and the
> certifications you mention could (and would) be made available to the WG.
> I
> didn't get a response, so I'll ask again.
>
> Since the "certifyability" seems to be a selling point for this approach,
> it
> seems relevant for the WG to evaluate that information, in deciding on a
> solution.
>
>
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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

Delivery-date: Wed, 01 Aug 2007 20:19:34 +0000
Date: Wed, 1 Aug 2007 13:19:01 -0700 (PDT)
Subject: RE: Crypto-agility requirement and       draft-zorn-radius-encattr/draft-zorn-radius-keywrap
From: "Dan Harkins" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: "Dan Harkins" <[email-masked]>, [email-masked]

  Hi Glen,

On Wed, August 1, 2007 12:51 pm, Glen Zorn (gwz) wrote:
> Dan Harkins <> allegedly scribbled on Wednesday, August 01, 2007 11:04
> AM:
>
>>   Hi Joe,
>>
>>   As I mentioned at the mic during the meeting at IETF69
>> draft-zorn-radius-keywrap is not really very (crypto-)agile and I
>> think with some minor modifications could be made more so. For
>> example:
>>
>>   - do not require that Message-Authentication-Code MUST be present
>>     if Keying-Material is present. SIV is a much preferrable key
>>     wrapping technique than RFC3394 and if SIV was specified in the
>>     enc-type of Keying-Material then Message-Authentication-Code would
>>     be redundant. Please say that if enc-type is RFC3394 then
>>     Message-Authentication-Code MUST also be present. Other enc-types
>>     can mandate it or not as needed.
>
> Since AES Key Wrap is the only one specified & SIV doesn't actually
> exist as a standard, this doesn't make much sense to me.

  It makes sense if you think about it in terms of crypto-agility.
If you're submitting a draft that only does AES Key wrap with no
capability to substitute anything else then you can mandate other
attributes that may be necessary. This isn't crypto-agile though.

  The subject of this thread concerns the crypto-agility requirement and
to be crypto-agile it doesn't make sense to mandate use of attributes that
are only necessary if you're using one particular enc-type. The whole
idea is that we're going to be plugging in other enc-types, no?

>>
>>   - do not require Mac-Randomizer if Message-Authentication-Code is
>>     present. The reason a deterministic authenticated encryption
>>     scheme like RFC3394 can provide what amounts to probabilistic
>>     authenticated encryption is because what it's wrapping is,
>>     itself, random. The further addition of randomness is unnecessary.
>
> Actually, this is largely irrelevant: the purpose of the Mac-Randomizer
> is to facillitate the use of the Message-Authentication-Code in
> accounting & CoA messages.  It is actually independent of the
> Keying-Material attribute.  I suppose that we could further specify it
> as only required if the Message-Authenticator-Attribute is used in one
> of those messages...

  That would work I think. My comment was not very good because my real
concern is the dependency on having a Mac-Randomizer if you have a
Keying-Material attribute. The dependency may be happenstance but
according to the draft if you have the Keying-Material attribute then you
MUST also have a Mac-Randomizer. If that dependency was not there then
I don't think I'd care so much.

  (Unrelated to crypto-agility, but an informative note on the point
behind the Mac-Randomizer-- replay? some esoteric security property?--
would be most helpful and some text in the Security Considerations
regarding the implications on reuse of this "random" number in different
messages would be very important).

>>
>>   - the IV is not necessary. Key wrapping (RFC3394 or even SIV in its
>>     key wrapping varient) is deterministic. RFC3394 has a default IV
>>     which is used to determine whether the unwrapping was successful
>>     or not but that does not need to be communicated.
>>     draft-zorn-radius-keywrap even says that if RFC3394 is being used
>>     as the enc-type then the IV MUST be A6A6A6A6A6A6A6A6. That serves
>> no useful purpose.
>
> Fine.
>
>>
>>   - not everyone is comfortable with massive covert channels like KEK
>>     ID and KM ID. I suggest making them optional and using a bit it
>>     the reserved field to indicate their presense or absense.
>
> So having optional "massive covert channels" is somehow better?  Why?

  Actually no they're not but I was trying to be generous since it is
claimed that there are implementations using this already. But you're
right. Get rid of the whole key id stuff. That is certainly acceptable.
You're only recommending the creation of 2 new keys to implement this
draft so key id fields are, strictly speaking, unnecessary.

  Dan.

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

Delivery-date: Wed, 01 Aug 2007 20:08:32 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 16:08:48 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> There are multiple interoperable implementations which
> have been NIST (& at in least one case) Common Criteria certified,
> however, so we'll just be leaving it as is for now.

I has previously asked if information on the implementations and the
certifications you mention could (and would) be made available to the WG.  I
didn't get a response, so I'll ask again.

Since the "certifyability" seems to be a selling point for this approach, it
seems relevant for the WG to evaluate that information, in deciding on a
solution.

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

Delivery-date: Wed, 01 Aug 2007 20:07:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Wed, 1 Aug 2007 13:07:12 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Romascanu, Dan \(Dan\)" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

Romascanu, Dan (Dan) <mailto:[email-masked]> allegedly scribbled on
Wednesday, August 01, 2007 10:12 AM:

...

> Seriously, I was the one to recommend the author to ask for a time
> slot on the RADEXT agenda. I believe that the RADSEC work is if not
> within at least related to the WG scope (but not necessarily as a
> crypto-agility solution), although undertaking it would mean an
> extension of the charter.=20

OK, I'm confused: the scope of a WG is _not_ defined by its charter?  If
the charter doesn't define the scope of a WG, what does?

> I believe it was good for the working group
> to hear it and discuss whether there is consensus to include it as a
> future work item. This discussion is happening right now, and it's
> good.  =20

Just a historical note: in the beginnings of Diameter development, the
adoption of TCP as a transport for RADIUS between servers was discussed
at length (how this perfectly reasonable idea evolved into TCP/SCTP
everywhere I don't know).  If the IESG's goal is still to avoid having
RADIUS & Diameter compete then adopting RADSEC is a very bad idea.=20
 =20
>=20
> Dan

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

Delivery-date: Wed, 01 Aug 2007 19:56:06 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility requirement and      draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 12:55:53 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Dan Harkins" <[email-masked]>, "Joseph Salowey \(jsalowey\)" <[email-masked]>
Cc: <[email-masked]>

BTW, I forgot to mention in my reply: if our draft is adopted as a WG
item, we will be more than amenable to your (and any other) suggestions
for improvement.  There are multiple interoperable implementations which
have been NIST (& at in least one case) Common Criteria certified,
however, so we'll just be leaving it as is for now.

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

Delivery-date: Wed, 01 Aug 2007 19:51:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Crypto-agility requirement and      draft-zorn-radius-encattr/draft-zorn-radius-keywrap
Date: Wed, 1 Aug 2007 12:51:11 -0700
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "Dan Harkins" <[email-masked]>
Cc: <[email-masked]>

Dan Harkins <> allegedly scribbled on Wednesday, August 01, 2007 11:04
AM:

>   Hi Joe,
>=20
>   As I mentioned at the mic during the meeting at IETF69
> draft-zorn-radius-keywrap is not really very (crypto-)agile and I
> think with some minor modifications could be made more so. For
> example:  =20
>=20
>   - do not require that Message-Authentication-Code MUST be present
>     if Keying-Material is present. SIV is a much preferrable key
>     wrapping technique than RFC3394 and if SIV was specified in the
>     enc-type of Keying-Material then Message-Authentication-Code would
>     be redundant. Please say that if enc-type is RFC3394 then
>     Message-Authentication-Code MUST also be present. Other enc-types
>     can mandate it or not as needed.

Since AES Key Wrap is the only one specified & SIV doesn't actually
exist as a standard, this doesn't make much sense to me.

>=20
>   - do not require Mac-Randomizer if Message-Authentication-Code is
>     present. The reason a deterministic authenticated encryption
>     scheme like RFC3394 can provide what amounts to probabilistic
>     authenticated encryption is because what it's wrapping is,
>     itself, random. The further addition of randomness is unnecessary.

Actually, this is largely irrelevant: the purpose of the Mac-Randomizer
is to facillitate the use of the Message-Authentication-Code in
accounting & CoA messages.  It is actually independent of the
Keying-Material attribute.  I suppose that we could further specify it
as only required if the Message-Authenticator-Attribute is used in one
of those messages...

>=20
>   - the IV is not necessary. Key wrapping (RFC3394 or even SIV in its
>     key wrapping varient) is deterministic. RFC3394 has a default IV
>     which is used to determine whether the unwrapping was successful
>     or not but that does not need to be communicated.
>     draft-zorn-radius-keywrap even says that if RFC3394 is being used
>     as the enc-type then the IV MUST be A6A6A6A6A6A6A6A6. That serves
> no useful purpose.=20

Fine.

>=20
>   - not everyone is comfortable with massive covert channels like KEK
>     ID and KM ID. I suggest making them optional and using a bit it
>     the reserved field to indicate their presense or absense.

So having optional "massive covert channels" is somehow better?  Why?

...

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

Delivery-date: Wed, 01 Aug 2007 19:15:34 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-radext-rfc3576bis-09.txt 
Date: Wed, 01 Aug 2007 15:15:01 -0400

--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		: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)	: M. Chiba, et al.
	Filename	: draft-ietf-radext-rfc3576bis-09.txt
	Pages		: 37
	Date		: 2007-8-1
	
This document describes a currently deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, allowing
   dynamic changes to a user session, as implemented by network access
   server products.  This includes support for disconnecting users and
   changing authorizations applicable to a user session.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-radext-rfc3576bis-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-09.txt

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

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

--OtherAccess--

--NextPart--

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

Delivery-date: Wed, 01 Aug 2007 19:00:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635
Date: Wed, 01 Aug 2007 12:00:10 -0700

Please note that the publication date of RFC 3588 (which included a Nokia 
author) was September 2003, and that this Nokia IPR claim was submitted to 
the IETF on January 6, 2004, several months after the Diameter RFC was 
published.  As co-chair of the AAA WG, I would not have allowed RFC 3588 to 
be submitted to the IESG for publication without WG discussion of the IPR 
claim, had the IPR claim been submitted prior to publication of the Diameter 
RFC.

>From: <[email-masked]>
>To: <[email-masked]>, <[email-masked]>, <[email-masked]>
>Subject: FW: Nokia Patent discussion FW: [Dime] First results on Diameter 
>vs. RadSec patent research:EP1147635
>Date: Wed, 1 Aug 2007 12:15:02 -0500
>
>Hi all,
>
>I was asked to forward this to the DiME, RADext and OPSA WG mailing lists.
>
>Thanks,
>John
>
>
>	Dear Stefan,
>
>	I asked John to forward this message as I'm not a regular on the DIME 
>list.  I'm responsible for handling IETF related IPR cases in Nokia.
>
>	As you suggested, Nokia believes EP1147635, and other members of the same 
>patent family, are essential to practice RFC3588.
>
>	However, I do suggest that you, and other folks interested, contact your 
>respective legal folks regarding the implication of the existence of the 
>patent, in conjunction with our patent declaration.  I do not believe that 
>Stefan's claim is correct:
>
>				Every implementation of the
>				Diameter base protocol will use the patented technology and
>				needs to either license it or will violate it.
>
>
>	In order to help the group to understand our declaration, please allow me 
>to provide a simplistic explanation.  As for the binding legal language, 
>please see the declaration itself (cited correctly by Stefan in his 
>original email):
>
>
>			Nokia agrees not to assert those claims in Nokia above
>			mentioned patents that apply to the RFC3588 and are
>			technically necessary to implement this IETF standard
>			specification against any other party in respect of its
>			implementation of the specification, provided that the party
>			relying on this commitment does not assert its patents against Nokia.
>
>
>	Our licensing declaration is what is commonly known as a "non-assert" 
>statement.  What it says is that if you don't come after Nokia with your 
>patents, Nokia will not use its patents against your RFC 3588 
>implementation.
>
>	Non-assert statements like this are widely used in the IETF, as they are 
>believed to provide sufficient defensive protection for the owner, while 
>still allowing implementers and users to exercise the protected technology 
>without a license and for free, as long as they behave similarly nice (i.e. 
>not going after Nokia with their patents).  In that, non-asserts are 
>believed to be compatible with most open source licenses.
>
>
>	Feel free to contact me in private if you have more questions.
>
>	Best regards,
>	Stephan Wenger
>	[email-masked]
>
>	 -----Original Message-----
>
>			From: ext Stefan Winter [mailto:[email-masked]]
>			Sent: 01 August, 2007 15:28
>			To: [email-masked]; [email-masked]
>			Subject: [Dime] First results on Diameter vs. RadSec patent
>			research:EP1147635
>
>			Hello all,
>
>			(sorry for cross-posting, this may also be of interest for dime)
>
>			when presenting the RadSec draft in IETF69 Chicago, I
>			mentioned the patent claims of Nokia concerning Diameter. As a
>			reaction, some participants claimed that RadSec itself
>			implements a subset of the Diameter features and may very well
>			itself be subject to these patents. So I started an
>			investigation in this respect.
>
>			I started the research myself by grabbing a copy of patent
>			EP1147635 by Nokia, which is claiming to affect Diameter. My
>			focus of the patent's examination was whether this patent
>			might also affect RadSec.
>
>			The content of this patent is, in short, that packets on a
>			network get tagged as "possible duplicate" on retransmission
>			in order to make the endpoint aware that the received content
>			may be a duplicate of a previous packet. It also provides a
>			mechanism to correlate the multiple copies even when the
>			packets took different paths through the network.
>
>			Diameter does exactly that, described in section 5.5.4
>			"Failover and Failback Procedures" of RFC3588: a bit in the
>			Diameter header, the "T" bit, is set whenever a Diameter
>			packet needed to be retransmitted. Also, Diameter packets
>			carry an end-to-end identifier that makes it possible to
>			identify duplicates.
>
>			This means that at least from my point of view, Nokia's claim
>			concerning Diameter is true. Every implementation of the
>			Diameter base protocol will use the patented technology and
>			needs to either license it or will violate it.
>			(Note: I am not a lawyer. This is just my interpretation;
>			consider my knowledge being "Slashdot-level").
>			From the wording in this section 5.5.4 and the explanation of
>			the T bit in chapter 3, it seems that setting the T bit is
>			mandatory on retransmissions, so adhering to the protocol
>			specification leaves no room for circumventing the content of
>			the patent (e.g., by keeping it 0 at all times).
>
>			Luckily, RadSec does not implement such a sophisticated
>			duplicate packet detection algorithm. So, this particular
>			patent appears not to be of any concern for implementors of RadSec.
>
>			I will continue investigating the bunch of other patents and
>			patent applications relating to Diameter as soon as I get
>			copies of them. For reference, here is Nokia's claim statement
>			concerning Diameter (as submitted to the IETF IPR tracker):
>
>			----------
>
>			Title: Nokia's Statement About IPR Claimed in RFC 3588
>			Received: January 6, 2004
>			From: [email-masked]
>
>			This is to advise the IETF that Nokia believes the Nokia
>			patents: EP1147635 and AU757984, and the related patent
>			applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102,
>			JP2000-595452 and US09/903863 may be relevant to Diameter Base
>			Protocol RFC3588.
>
>			Nokia agrees not to assert those claims in Nokia above
>			mentioned patents that apply to the RFC3588 and are
>			technically necessary to implement this IETF standard
>			specification against any other party in respect of its
>			implementation of the specification, provided that the party
>			relying on this commitment does not assert its patents against Nokia.
>
>			Regards,
>
>			Harri Honkasalo
>
>			Director of IPR, Standard Technology
>
>			Nokia Corporation
>
>			----------
>
>
>			Greetings,
>
>			Stefan Winter
>
>			--
>			Stefan WINTER
>
>			RESTENA Foundation - Réseau Téléinformatique de l'Education
>			Nationale et de la Recherche R&D Engineer
>
>			6, rue Richard Coudenhove-Kalergi
>			L-1359 Luxembourg
>			email: [email-masked]     Tel.:     +352 424409-1
>			http://www.restena.lu               Fax:      +352 422473
>
>
>			<signature.asc>
>
>		_______________________________________________
>		DiME mailing list
>		[email-masked]
>		https://www1.ietf.org/mailman/listinfo/dime
>
>

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

Delivery-date: Wed, 01 Aug 2007 18:04:38 +0000
Date: Wed, 1 Aug 2007 11:04:11 -0700 (PDT)
Subject: Re: Crypto-agility requirement and  draft-zorn-radius-encattr/draft-zorn-radius-keywrap
From: "Dan Harkins" <[email-masked]>
To: "Joseph Salowey (jsalowey)" <[email-masked]>
Cc: [email-masked]

  Hi Joe,

  As I mentioned at the mic during the meeting at IETF69
draft-zorn-radius-keywrap is not really very (crypto-)agile and I
think with some minor modifications could be made more so. For example:

  - do not require that Message-Authentication-Code MUST be present
    if Keying-Material is present. SIV is a much preferrable key
    wrapping technique than RFC3394 and if SIV was specified in the
    enc-type of Keying-Material then Message-Authentication-Code would
    be redundant. Please say that if enc-type is RFC3394 then
    Message-Authentication-Code MUST also be present. Other enc-types
    can mandate it or not as needed.

  - do not require Mac-Randomizer if Message-Authentication-Code is
    present. The reason a deterministic authenticated encryption scheme
    like RFC3394 can provide what amounts to probabilistic authenticated
    encryption is because what it's wrapping is, itself, random. The
    further addition of randomness is unnecessary.

  - the IV is not necessary. Key wrapping (RFC3394 or even SIV in its
    key wrapping varient) is deterministic. RFC3394 has a default IV which
    is used to determine whether the unwrapping was successful or not but
    that does not need to be communicated. draft-zorn-radius-keywrap even
    says that if RFC3394 is being used as the enc-type then the IV MUST
    be A6A6A6A6A6A6A6A6. That serves no useful purpose.

  - not everyone is comfortable with massive covert channels like KEK ID
    and KM ID. I suggest making them optional and using a bit it the
    reserved field to indicate their presense or absense.

  Crypto-agility isn't just the ability to substitute one algorithm for
another, it should include the jettisoning any unnecessary baggage that
might've been appropriate (or required) for one algorithm if it's not
appropriate (or required) for another. Some of this stuff might be
needed if you're using RFC3394 and some stuff might be useful for
whatever your existing implementation is using them for but I don't think
I should be forced to add covert channels, repeat known information
(A6A6A6A6...), or unnecessarily integrity protect an already integrity
protected message. It surely isn't (crypto-)agile to force me to.

  thanks,

  Dan.

On Mon, July 23, 2007 9:03 am, Joseph Salowey (jsalowey) wrote:
>
>
> SECURITY SERVICES
>
> 2. Proposals MUST support the negotiation of cryptographic algorithms
> for per-packet integrity/authentication protection.
> Support for confidentiality of entire RADIUS packets is OPTIONAL.
> However, proposals MUST support the negotiation of algorithms for
> encryption (sometimes referred to as "hiding") of RADIUS attributes.
> If possible, it is desirable for proposals to provide for the encryption
> of existing attributes.  This includes existing "hidden"
> attributes as well as attributes (such as location attributes) that
> require confidentiality.
>
> Included in negotiation techniques are "hint and consent" mechanisms
> where the NAS provides a list of algorithms and the server selects one.
>
> [Joe] Algorithms within the proposal are identified so they can be
> replaced.  The client can specify the algorithm it wishes the server to
> use.
>
>
> 3. Proposals MUST support replay protection.  The existing mechanisms
> for replay protection are considered adequate and should be maintained.
>
> [Joe] Existing replay protection mechanisms are maintained
>
> 4. Crypto-agility solutions MUST specify mandatory-to-implement
> algorithms for each mechanism.
>
> [Joe] Mandatory to implement algorithms are specified (AES-CBC,
> AES-Keywrap, HMAC-SHA1)
>
> BACKWARD COMPATIBILITY
>
> 5. Solutions to the problem MUST demonstrate backward compatibility with
> existing RADIUS implementations.  That is, a crypto-agility solution
> needs to be able to send packets that a legacy RADIUS client or server
> will receive and process successfully.  Similarly, a crypto-agility
> solution needs to be capable of receiving and processing packets from a
> legacy RADIUS client or server.
>
> [Joe]  The proposal requires the use of new RADIUS attributes.  All
> other aspects of the RADIUS protocol can remain the same, so backward
> compatibility is possible.  However it is important to note that if
> stronger that current security algorithms are required then backwards
> compatibility is not possible.
>
> 6. Crypto-agility solutions MUST avoid security compromise, even in
> situations where the existing cryptographic algorithms utilized by
> RADIUS implementations are shown to be weak enough to provide little or
> no security (e.g. in event of compromise of the "legacy" RADIUS shared
> secret). Included in this would be protection against bidding down
> attacks.
>
> [Joe] Depending upon the selection of the key the new protection can be
> completely separate from the existing protection.  The selection of the
> key is currently a deployment choice.
>
>
> INTEROPERABILITY AND CHANGE CONTROL
>
> 7. Proposals MUST indicate a willingness to cede change control to the
> IETF.
>
> [Joe] Change control can be cede. An informational RFC may be published
> to document existing implementations.
>
> 8. Crypto-agility solutions MUST be interoperable between independent
> implementations based purely on the information provided in the
> specification.
>
> [Joe] Interoperable implementations exist based on this specification.
> These implementations use VSAs instead of standard attributes.
>
> SCOPE OF WORK
>
> 9. Crypto-agility solutions MUST apply to all RADIUS packet types,
> including Access-Request, Challenge, Reject & Accept,
> Accounting-Request/Response, and CoA/Disconnect messages.
>
> [Joe] The attributes described can be added to any of these mechanisms.
>
> 10. Proposals MUST include a Diameter compatibility section, although it
> is expected that the work will occur purely within RADIUS or in the
> transport, and therefore does not affect message data that is exchanged
> with Diameter.
>
> [Joe] A Diameter compatibility section will need to be added.
>
> 11. Crypto-agility solutions SHOULD NOT require fundamental changes to
> The RADIUS operational model, such as the introduction of new commands
> Or maintenance of state on the RADIUS server.  Similarly, a proposal
> Should focus on the crypto-agility problem and nothing else.  For
> example, proposals should not require new attribute formats or include
> definition of new RADIUS services.  Unless modified, the restrictions in
> the RADEXT WG charter apply.
>
> [Joe] This solution works well with the existing implementations.  It
> does not require major changes to the RADIUS protocol.  In particular it
> does not necessarily introduce new "session" state maintenance
> requirements on the server.
>
> Note that for the purposes of this work, the RADEXT WG charter
> Restriction against definition of "new security mechanisms" should be
> interpreted as prohibiting changes to the basic RADIUS packet format
> (e.g. headers), but permits new crypto-algorithms to be substituted For
> use in existing security mechanisms.
>
> [Joe] This is what the proposal does.  It is very close to existing
> RADIUS protection mechanisms requiring minimal change to existing
> implementations.
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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

Delivery-date: Wed, 01 Aug 2007 17:40:08 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635
Date: Wed, 1 Aug 2007 13:40:17 -0400
Organization: Elbrys Networks, Inc.

> Non-assert statements like this are widely used in the IETF,
> as they are believed to provide sufficient defensive protection
> for the owner, while still allowing implementers and users to 
> exercise the protected technology without a license and for 
> free, as long as they behave similarly nice...

It is true that "non-assert" IPR statements are frequently issued these
days.

> In that, non-asserts are believed to be compatible with most 
> open source licenses.

Compatible?  What does that mean?

A reciprocal non-assert is not quite the same thing as open source.  Open
source has to do with copyright IPR, not patent IPR.  Additionally,
reciprocal non-asserts would appear to apply to all patents that an
organization may hold, not only those that are related to standards.  In
that regard, it is tantamount to an implicit (and broad) cross-licensing
agreement, which would include patents covering proprietary technology as
well as open standards based technology.

Still, it is better than nothing, and very useful to companies that don't
intend to enforce _any_ of their patent portfolio against infringement by
the non-assert grantors.  Of course, it also works out fine for companies
that don't have patents to enforce.  :-)

Standard disclaimer: I am not a lawyer.

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

Delivery-date: Wed, 01 Aug 2007 17:32:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Wed, 1 Aug 2007 13:32:09 -0400
From: "Stephen Hanna" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

Thanks, Dan. I'm glad you did suggest that we consider the
RADSEC work. Now we can consider the alternatives on their
technical merits and set aside the charter or process questions
for the moment (to be revisited if necessary).

I have asked Juniper's RADIUS experts to join us for this
discussion. They should be here within a few hours. Sorry
for the delay.

Thanks,

Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, August 01, 2007 1:12 PM
To: Glen Zorn (gwz); David B. Nelson
Cc: [email-masked]
Subject: RE: Continued discussion of RADIUS Crypto-Agility

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Glen Zorn (gwz)
> Sent: Tuesday, July 31, 2007 10:08 PM
> To: David B. Nelson
> Cc: [email-masked]
> Subject: RE: Continued discussion of RADIUS Crypto-Agility
>=20
> David B. Nelson <> allegedly scribbled on Tuesday, July 31, 2007 11:25
> AM:
>=20
> > Glen Zorn writes...
> >=20
> >> To 1) ignore our charter (not to mention the (at best)=20
> disingenuous=20
> >> '?' regarding it in the presentation)...
> >=20
> > To be fair, the authors of this ID did indicate they knew=20
> it was out=20
> > of charter scope, and therefore not eligible for the Crypto-Agility=20
> > solution, at the time that they requested the presentation slot in=20
> > RADEXT.  The "?" apparently came about as a result of=20
> discussions in=20
> > the O&M Area WG earlier in the week.
>=20
> So can we appropriately blame this nonsense (surprise!) on the IESG?=20
>=20

If finding somebody to blame solves the problem or at least half of it,
I'll step ahead :-)

Seriously, I was the one to recommend the author to ask for a time slot
on the RADEXT agenda. I believe that the RADSEC work is if not within at
least related to the WG scope (but not necessarily as a crypto-agility
solution), although undertaking it would mean an extension of the
charter. I believe it was good for the working group to hear it and
discuss whether there is consensus to include it as a future work item.
This discussion is happening right now, and it's good.=20

Dan

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

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

Delivery-date: Wed, 01 Aug 2007 17:27:53 +0000
Date: Wed, 1 Aug 2007 13:27:20 -0400
From: Barney Wolff <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635

In the 1970s, Western Union's Infomaster message switch attached a
"Suspected Duplicate" tag to every retransmitted message.  I wonder
if this tidbit was known to the examiners as relevant prior art.

-- 
Barney Wolff         I never met a computer I didn't like.

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

Delivery-date: Wed, 01 Aug 2007 17:15:49 +0000
Content-class: urn:content-classes:message
Subject: FW: Nokia Patent discussion FW: [Dime] First results on Diameter vs. RadSec patent research:EP1147635
Date: Wed, 1 Aug 2007 12:15:02 -0500
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7D45F.8194DEFE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,
=20
I was asked to forward this to the DiME, RADext and OPSA WG mailing =
lists. =20
=20
Thanks,
John

	Dear Stefan,

	I asked John to forward this message as I'm not a regular on the DIME =
list.  I'm responsible for handling IETF related IPR cases in Nokia.

	As you suggested, Nokia believes EP1147635, and other members of the =
same patent family, are essential to practice RFC3588.

	However, I do suggest that you, and other folks interested, contact =
your respective legal folks regarding the implication of the existence =
of the patent, in conjunction with our patent declaration.  I do not =
believe that Stefan's claim is correct:

				Every implementation of the =20
				Diameter base protocol will use the patented technology and=20
				needs to either license it or will violate it.=20

	In order to help the group to understand our declaration, please allow =
me to provide a simplistic explanation.  As for the binding legal =
language, please see the declaration itself (cited correctly by Stefan =
in his original email):

			Nokia agrees not to assert those claims in Nokia above =20
			mentioned patents that apply to the RFC3588 and are=20
			technically necessary to implement this IETF standard=20
			specification against any other party in respect of its=20
			implementation of the specification, provided that the party=20
			relying on this commitment does not assert its patents against Nokia.

	Our licensing declaration is what is commonly known as a "non-assert" =
statement.  What it says is that if you don't come after Nokia with your =
patents, Nokia will not use its patents against your RFC 3588 =
implementation.
	 =20
	Non-assert statements like this are widely used in the IETF, as they =
are believed to provide sufficient defensive protection for the owner, =
while still allowing implementers and users to exercise the protected =
technology without a license and for free, as long as they behave =
similarly nice (i.e. not going after Nokia with their patents).  In =
that, non-asserts are believed to be compatible with most open source =
licenses.
=09
=09
	Feel free to contact me in private if you have more questions.
	=20
	Best regards,
	Stephan Wenger
	[email-masked]
	=20
	 -----Original Message-----

			From: ext Stefan Winter [mailto:[email-masked]]=20
			Sent: 01 August, 2007 15:28
			To: [email-masked]; [email-masked]
			Subject: [Dime] First results on Diameter vs. RadSec patent=20
			research:EP1147635

			Hello all,

			(sorry for cross-posting, this may also be of interest for dime)

			when presenting the RadSec draft in IETF69 Chicago, I=20
			mentioned the patent claims of Nokia concerning Diameter. As a=20
			reaction, some participants claimed that RadSec itself=20
			implements a subset of the Diameter features and may very well=20
			itself be subject to these patents. So I started an=20
			investigation in this respect.

			I started the research myself by grabbing a copy of patent=20
			EP1147635 by Nokia, which is claiming to affect Diameter. My=20
			focus of the patent's examination was whether this patent=20
			might also affect RadSec.

			The content of this patent is, in short, that packets on a=20
			network get tagged as "possible duplicate" on retransmission=20
			in order to make the endpoint aware that the received content=20
			may be a duplicate of a previous packet. It also provides a=20
			mechanism to correlate the multiple copies even when the=20
			packets took different paths through the network.

			Diameter does exactly that, described in section 5.5.4=20
			"Failover and Failback Procedures" of RFC3588: a bit in the=20
			Diameter header, the "T" bit, is set whenever a Diameter=20
			packet needed to be retransmitted. Also, Diameter packets=20
			carry an end-to-end identifier that makes it possible to=20
			identify duplicates.

			This means that at least from my point of view, Nokia's claim=20
			concerning Diameter is true. Every implementation of the=20
			Diameter base protocol will use the patented technology and=20
			needs to either license it or will violate it.=20
			(Note: I am not a lawyer. This is just my interpretation;=20
			consider my knowledge being "Slashdot-level").
			From the wording in this section 5.5.4 and the explanation of=20
			the T bit in chapter 3, it seems that setting the T bit is=20
			mandatory on retransmissions, so adhering to the protocol=20
			specification leaves no room for circumventing the content of=20
			the patent (e.g., by keeping it 0 at all times).

			Luckily, RadSec does not implement such a sophisticated=20
			duplicate packet detection algorithm. So, this particular=20
			patent appears not to be of any concern for implementors of RadSec.

			I will continue investigating the bunch of other patents and=20
			patent applications relating to Diameter as soon as I get=20
			copies of them. For reference, here is Nokia's claim statement=20
			concerning Diameter (as submitted to the IETF IPR tracker):

			----------

			Title: Nokia's Statement About IPR Claimed in RFC 3588
			Received: January 6, 2004
			From: [email-masked]

			This is to advise the IETF that Nokia believes the Nokia
			patents: EP1147635 and AU757984, and the related patent
			applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102,
			JP2000-595452 and US09/903863 may be relevant to Diameter Base=20
			Protocol RFC3588.

			Nokia agrees not to assert those claims in Nokia above=20
			mentioned patents that apply to the RFC3588 and are=20
			technically necessary to implement this IETF standard=20
			specification against any other party in respect of its=20
			implementation of the specification, provided that the party=20
			relying on this commitment does not assert its patents against Nokia.

			Regards,

			Harri Honkasalo

			Director of IPR, Standard Technology

			Nokia Corporation

			----------

			Greetings,

			Stefan Winter

			--
			Stefan WINTER

			RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education=20
			Nationale et de la Recherche R&D Engineer

			6, rue Richard Coudenhove-Kalergi
			L-1359 Luxembourg
			email: [email-masked]     Tel.:     +352 424409-1=20
			http://www.restena.lu               Fax:      +352 422473

		=09
			<signature.asc>

		_______________________________________________
		DiME mailing list
		[email-masked]
		https://www1.ietf.org/mailman/listinfo/dime

------_=_NextPart_001_01C7D45F.8194DEFE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3132" name=3DGENERATOR></HEAD>
<BODY=20
style=3D"WORD-WRAP: break-word; khtml-nbsp-mode: space; =
khtml-line-break: after-white-space">
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D336361217-01082007>Hi all,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D336361217-01082007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D336361217-01082007>I was asked to forward this to the&nbsp;DiME, =
RADext=20
and OPSA WG mailing lists.&nbsp;</SPAN><SPAN=20
class=3D336361217-01082007>&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D336361217-01082007></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D336361217-01082007>Thanks,</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D336361217-01082007>John</SPAN></FONT></FONT></FONT></DIV>
<DIV><BR class=3Dkhtml-block-placeholder></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV>Dear Stefan,</DIV>
  <DIV><BR class=3Dkhtml-block-placeholder></DIV>
  <DIV>I asked John to forward this message as I'm not a regular on the =
DIME=20
  list.&nbsp; I'm responsible for handling IETF related IPR cases in=20
Nokia.</DIV>
  <DIV><BR class=3Dkhtml-block-placeholder></DIV>
  <DIV>As you suggested, Nokia believes EP1147635, and other members of =
the same=20
  patent family, are essential to practice RFC3588.</DIV>
  <DIV><BR class=3Dkhtml-block-placeholder></DIV>
  <DIV>However, I do suggest that you, and other folks interested, =
contact your=20
  respective legal folks regarding the implication of the existence of =
the=20
  patent, in conjunction with our patent declaration.&nbsp; I do not =
believe=20
  that Stefan's claim&nbsp;is correct:</DIV>
  <BLOCKQUOTE type=3D"cite">
    <BLOCKQUOTE type=3D"cite">
      <BLOCKQUOTE type=3D"cite"><FONT class=3DApple-style-span =
color=3D#006312>Every=20
        implementation of the</FONT><FONT class=3DApple-style-span=20
        color=3D#006312>&nbsp;</FONT>
        <DIV style=3D"MARGIN: 0px"><FONT class=3DApple-style-span=20
        color=3D#006312>Diameter base protocol will use the patented =
technology=20
        and&nbsp;</FONT></DIV>
        <DIV style=3D"MARGIN: 0px"><FONT class=3DApple-style-span=20
        color=3D#006312>needs to either license it or will violate=20
        it.&nbsp;</FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE>
  <DIV><BR class=3Dkhtml-block-placeholder></DIV>
  <DIV>In order to help the group to understand our declaration, please =
allow me=20
  to provide a simplistic explanation.&nbsp; As for the binding legal =
language,=20
  please see the declaration itself (cited correctly by Stefan in his =
original=20
  email):</DIV>
  <DIV><BR class=3Dkhtml-block-placeholder></DIV>
  <BLOCKQUOTE type=3D"cite">
    <BLOCKQUOTE type=3D"cite">Nokia agrees not to assert those claims in =
Nokia=20
      above&nbsp;
      <DIV style=3D"MARGIN: 0px">mentioned patents that apply to the =
RFC3588 and=20
      are&nbsp;</DIV>
      <DIV style=3D"MARGIN: 0px">technically necessary to implement this =
IETF=20
      standard&nbsp;</DIV>
      <DIV style=3D"MARGIN: 0px">specification against any other party =
in respect=20
      of its&nbsp;</DIV>
      <DIV style=3D"MARGIN: 0px">implementation of the specification, =
provided=20
      that the party&nbsp;</DIV>
      <DIV style=3D"MARGIN: 0px">relying on this commitment does not =
assert its=20
      patents against Nokia.</DIV></BLOCKQUOTE></BLOCKQUOTE>
  <DIV><BR class=3Dkhtml-block-placeholder>
  <DIV>Our licensing declaration is what is commonly known as a =
"non-assert"=20
  statement.&nbsp; What it says is that if you don't come after Nokia =
with your=20
  patents, Nokia will not use its patents against your RFC 3588=20
  implementation.</DIV>
  <DIV>&nbsp;&nbsp;</DIV>
  <DIV>Non-assert statements like this are widely used in the IETF, as =
they are=20
  believed to provide sufficient defensive protection for the owner, =
while still=20
  allowing implementers and users to exercise the protected technology =
without a=20
  license and for free, as long as they behave similarly nice (i.e. not =
going=20
  after Nokia with their patents).&nbsp; In that, non-asserts are =
believed to be=20
  compatible with most open source licenses.</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR=20
  class=3Dkhtml-block-placeholder></DIV>
  <DIV>Feel free to contact me in private if you have more =
questions.</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Best regards,</DIV>
  <DIV>Stephan Wenger</DIV>
  <DIV><A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A></DI=
V>
  <DIV>
  <DIV><SPAN class=3D336361217-01082007><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D336361217-01082007>&nbsp;</SPAN>-----Original=20
  Message-----</DIV>
  <DIV>
  <DIV>
  <BLOCKQUOTE type=3D"cite">
    <BLOCKQUOTE type=3D"cite">
      <DIV style=3D"MARGIN: 0px">From: ext Stefan Winter [<A=20
      =
href=3D"mailto:[email-masked]">mailto:[email-masked]<=
/A>]<SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">Sent: 01 August, 2007 15:28</DIV>
      <DIV style=3D"MARGIN: 0px">To: <A=20
      href=3D"mailto:[email-masked]">[email-masked]</A>; =
<A=20
      href=3D"mailto:[email-masked]">[email-masked]</A></DIV>
      <DIV style=3D"MARGIN: 0px">Subject: [Dime] First results on =
Diameter vs.=20
      RadSec patent<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">research:EP1147635</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Hello all,</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">(sorry for cross-posting, this may also =
be of=20
      interest for dime)</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">when presenting the RadSec draft in =
IETF69=20
      Chicago, I<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">mentioned the patent claims of Nokia =
concerning=20
      Diameter. As a<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">reaction, some participants claimed =
that RadSec=20
      itself<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">implements a subset of the Diameter =
features and=20
      may very well<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">itself be subject to these patents. So =
I started=20
      an<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">investigation in this respect.</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">I started the research myself by =
grabbing a copy=20
      of patent<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">EP1147635 by Nokia, which is claiming =
to affect=20
      Diameter. My<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">focus of the patent's examination was =
whether=20
      this patent<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">might also affect RadSec.</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">The content of this patent is, in =
short, that=20
      packets on a<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">network get tagged as "possible =
duplicate" on=20
      retransmission<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">in order to make the endpoint aware =
that the=20
      received content<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">may be a duplicate of a previous =
packet. It also=20
      provides a<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">mechanism to correlate the multiple =
copies even=20
      when the<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">packets took different paths through =
the=20
      network.</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Diameter does exactly that, described =
in section=20
      5.5.4<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">"Failover and Failback Procedures" of =
RFC3588: a=20
      bit in the<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">Diameter header, the "T" bit, is set =
whenever a=20
      Diameter<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">packet needed to be retransmitted. =
Also, Diameter=20
      packets<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">carry an end-to-end identifier that =
makes it=20
      possible to<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">identify duplicates.</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">This means that at least from my point =
of view,=20
      Nokia's claim<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">concerning Diameter is true. Every =
implementation=20
      of the<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">Diameter base protocol will use the =
patented=20
      technology and<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">needs to either license it or will =
violate=20
      it.<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">(Note: I am not a lawyer. This is just =
my=20
      interpretation;<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">consider my knowledge being=20
      "Slashdot-level").</DIV>
      <DIV style=3D"MARGIN: 0px">From the wording in this section 5.5.4 =
and the=20
      explanation of<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">the T bit in chapter 3, it seems that =
setting the=20
      T bit is<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">mandatory on retransmissions, so =
adhering to the=20
      protocol<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">specification leaves no room for =
circumventing=20
      the content of<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">the patent (e.g., by keeping it 0 at =
all=20
      times).</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Luckily, RadSec does not implement such =
a=20
      sophisticated<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">duplicate packet detection algorithm. =
So, this=20
      particular<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">patent appears not to be of any concern =
for=20
      implementors of RadSec.</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">I will continue investigating the bunch =
of other=20
      patents and<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">patent applications relating to =
Diameter as soon=20
      as I get<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">copies of them. For reference, here is =
Nokia's=20
      claim statement<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">concerning Diameter (as submitted to =
the IETF IPR=20
      tracker):</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">----------</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Title: Nokia's Statement About IPR =
Claimed in RFC=20
      3588</DIV>
      <DIV style=3D"MARGIN: 0px">Received: January 6, 2004</DIV>
      <DIV style=3D"MARGIN: 0px">From: <A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</=
A></DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">This is to advise the IETF that Nokia =
believes=20
      the Nokia</DIV>
      <DIV style=3D"MARGIN: 0px">patents: EP1147635 and AU757984, and =
the related=20
      patent</DIV>
      <DIV style=3D"MARGIN: 0px">applications: BRPI0007603-1, CA2360093, =

      CN00804050.8, FI990102,</DIV>
      <DIV style=3D"MARGIN: 0px">JP2000-595452 and US09/903863 may be =
relevant to=20
      Diameter Base<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">Protocol RFC3588.</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Nokia agrees not to assert those claims =
in Nokia=20
      above<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">mentioned patents that apply to the =
RFC3588 and=20
      are<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">technically necessary to implement this =
IETF=20
      standard<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">specification against any other party =
in respect=20
      of its<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">implementation of the specification, =
provided=20
      that the party<SPAN =
class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">relying on this commitment does not =
assert its=20
      patents against Nokia.</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Regards,</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Harri Honkasalo</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Director of IPR, Standard =
Technology</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Nokia Corporation</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">----------</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Greetings,</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">Stefan Winter</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">--</DIV>
      <DIV style=3D"MARGIN: 0px">Stefan WINTER</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">RESTENA Foundation - R=E9seau =
T=E9l=E9informatique de=20
      l'Education<SPAN class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px">Nationale et de la Recherche R&amp;D=20
      Engineer</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
      <DIV style=3D"MARGIN: 0px">6, rue Richard Coudenhove-Kalergi</DIV>
      <DIV style=3D"MARGIN: 0px">L-1359 Luxembourg</DIV>
      <DIV style=3D"MARGIN: 0px">email: <A=20
      =
href=3D"mailto:[email-masked]">[email-masked]</A> =
&nbsp;=20
      &nbsp; Tel.: &nbsp; &nbsp;&nbsp;+352 424409-1<SPAN=20
      class=3DApple-converted-space>&nbsp;</SPAN></DIV>
      <DIV style=3D"MARGIN: 0px"><A=20
      href=3D"http://www.restena.lu">http://www.restena.lu</A> &nbsp; =
&nbsp;=20
      &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Fax: &nbsp; &nbsp; &nbsp;+352=20
      422473</DIV>
      <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR><SPAN>
      <DIV>&lt;signature.asc&gt;</DIV></SPAN></DIV></BLOCKQUOTE>
    <DIV=20
    style=3D"MARGIN: =
0px">_______________________________________________</DIV>
    <DIV style=3D"MARGIN: 0px">DiME mailing list</DIV>
    <DIV style=3D"MARGIN: 0px"><A=20
    href=3D"mailto:[email-masked]">[email-masked]</A></DIV>
    <DIV style=3D"MARGIN: 0px"><A=20
    =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A></DIV></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV=
></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C7D45F.8194DEFE--

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

Delivery-date: Wed, 01 Aug 2007 17:12:58 +0000
Content-class: urn:content-classes:message
Subject: RE: Continued discussion of RADIUS Crypto-Agility
Date: Wed, 1 Aug 2007 19:12:04 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>, "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>

=20
=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Glen Zorn (gwz)
> Sent: Tuesday, July 31, 2007 10:08 PM
> To: David B. Nelson
> Cc: [email-masked]
> Subject: RE: Continued discussion of RADIUS Crypto-Agility
>=20
> David B. Nelson <> allegedly scribbled on Tuesday, July 31, 2007 11:25
> AM:
>=20
> > Glen Zorn writes...
> >=20
> >> To 1) ignore our charter (not to mention the (at best)=20
> disingenuous=20
> >> '?' regarding it in the presentation)...
> >=20
> > To be fair, the authors of this ID did indicate they knew=20
> it was out=20
> > of charter scope, and therefore not eligible for the Crypto-Agility=20
> > solution, at the time that they requested the presentation slot in=20
> > RADEXT.  The "?" apparently came about as a result of=20
> discussions in=20
> > the O&M Area WG earlier in the week.
>=20
> So can we appropriately blame this nonsense (surprise!) on the IESG?=20
>=20

If finding somebody to blame solves the problem or at least half of it,
I'll step ahead :-)

Seriously, I was the one to recommend the author to ask for a time slot
on the RADEXT agenda. I believe that the RADSEC work is if not within at
least related to the WG scope (but not necessarily as a crypto-agility
solution), although undertaking it would mean an extension of the
charter. I believe it was good for the working group to hear it and
discuss whether there is consensus to include it as a future work item.
This discussion is happening right now, and it's good.=20

Dan

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

Delivery-date: Wed, 01 Aug 2007 12:28:10 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: [email-masked], [email-masked]
Subject: First results on Diameter vs. RadSec patent research: EP1147635
Date: Wed, 1 Aug 2007 14:28:01 +0200

--nextPart7300169.drvr3jyHbZ
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello all,

(sorry for cross-posting, this may also be of interest for dime)

when presenting the RadSec draft in IETF69 Chicago, I mentioned the patent=
=20
claims of Nokia concerning Diameter. As a reaction, some participants claim=
ed=20
that RadSec itself implements a subset of the Diameter features and may ver=
y=20
well itself be subject to these patents. So I started an investigation in=20
this respect.

I started the research myself by grabbing a copy of patent EP1147635 by Nok=
ia,=20
which is claiming to affect Diameter. My focus of the patent's examination=
=20
was whether this patent might also affect RadSec.

The content of this patent is, in short, that packets on a network get tagg=
ed=20
as "possible duplicate" on retransmission in order to make the endpoint awa=
re=20
that the received content may be a duplicate of a previous packet. It also=
=20
provides a mechanism to correlate the multiple copies even when the packets=
=20
took different paths through the network.

Diameter does exactly that, described in section 5.5.4 "Failover and Failba=
ck=20
Procedures" of RFC3588: a bit in the Diameter header, the "T" bit, is set=20
whenever a Diameter packet needed to be retransmitted. Also, Diameter packe=
ts=20
carry an end-to-end identifier that makes it possible to identify duplicate=
s.

This means that at least from my point of view, Nokia's claim concerning=20
Diameter is true. Every implementation of the Diameter base protocol will u=
se=20
the patented technology and needs to either license it or will violate it.=
=20
(Note: I am not a lawyer. This is just my interpretation; consider my=20
knowledge being "Slashdot-level").
=46rom the wording in this section 5.5.4 and the explanation of the T bit i=
n=20
chapter 3, it seems that setting the T bit is mandatory on retransmissions,=
=20
so adhering to the protocol specification leaves no room for circumventing=
=20
the content of the patent (e.g., by keeping it 0 at all times).

Luckily, RadSec does not implement such a sophisticated duplicate packet=20
detection algorithm. So, this particular patent appears not to be of any=20
concern for implementors of RadSec.

I will continue investigating the bunch of other patents and patent=20
applications relating to Diameter as soon as I get copies of them. For=20
reference, here is Nokia's claim statement concerning Diameter (as submitte=
d=20
to the IETF IPR tracker):

=2D---------

Title: Nokia's Statement About IPR Claimed in RFC 3588
Received: January 6, 2004
=46rom: [email-masked]

This is to advise the IETF that Nokia believes the Nokia=20
patents: EP1147635 and AU757984, and the related patent=20
applications: BRPI0007603-1, CA2360093, CN00804050.8, FI990102,=20
JP2000-595452 and US09/903863 may be relevant to Diameter Base=20
Protocol RFC3588.

Nokia agrees not to assert those claims in Nokia above mentioned=20
patents that apply to the RFC3588 and are technically necessary=20
to implement this IETF standard specification against any other=20
party in respect of its implementation of the specification, provided=20
that the party relying on this commitment does not assert its patents=20
against Nokia.

Regards,

Harri Honkasalo

Director of IPR, Standard Technology

Nokia Corporation

=2D---------

Greetings,

Stefan Winter

=2D-=20
Stefan WINTER

RESTENA Foundation - R=E9seau T=E9l=E9informatique de l'Education Nationale=
 et de=20
la Recherche
R&D Engineer

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
email: [email-masked] =A0 =A0 Tel.: =A0 =A0=A0+352 424409-1
http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 4224=
73

--nextPart7300169.drvr3jyHbZ
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart7300169.drvr3jyHbZ--

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

Delivery-date: Wed, 01 Aug 2007 11:05:41 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: Crypto-agility
Date: Wed, 1 Aug 2007 07:05:29 -0400

Hannes Tschofenig writes...

> Can someone explain me the scope and the planned timeframe
> of the work?

We discussed what crypto-agility meant, in general, terms at IETF-68.
Basically, it means that IETF protocols that use cryptography need to have a
reasonably modular way to substitute new algorithms and modes (new cipher
suites).  As one algorithm (e.g. MD5) weakens in the face of new attacks, it
can then be replaced without redesigning the protocol and without undue
difficulty of deployment.

Designing protocols with a cipher suite identifier and/or cipher suite
negotiation is one component of this effort.  Modular implementations, that
allow crypto-libraries to "plug in" to the base protocol module is another.

In terms of RADIUS specific issues, the goal is to define alternative
cryptographic primitives to replace the use of MD5 hashes and MD5-based
stream ciphers, for things like the Message Authenticator and the "hidden"
attributes, such as User-Password.  It also encompasses the MS-PPE VSAs that
are commonly used for solutions such as IEEE 802.11 WLANs.

In RADIUS today there is only one key, the shared secret.  In any new
scheme, we need to understand what key(s) replaces the legacy shared secret
and how those keys is distributed to all parties that need them.  The goal
is not to add general-purpose key management features to RADIUS, in the way
a Kerberos KDC manages keys, for example.  That would probably be going too
far.

The current RADEXT charter page says the timeframe is "done by December
2006", so we're quite late!  :-)  Hence the sense of urgency in our
discussions.

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

Delivery-date: Wed, 01 Aug 2007 08:15:15 +0000
Date: Wed, 01 Aug 2007 09:47:20 +0200
From: Hannes Tschofenig <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: Crypto-agility

Until the last meeting I thought that the goal was to address a quite 
limited scope, namely http://psg.com/lists/radiusext/2007/msg00053.html.

Key management, for example, has not been subject of discussions in the 
past and  I thought it would even be outside the scope.

Can someone explain me the scope and the planned timeframe of the work?

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

Delivery-date: Wed, 01 Aug 2007 08:15:08 +0000
Date: Wed, 01 Aug 2007 09:47:28 +0200
From: Hannes Tschofenig <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: Attributes for Filtering & Redirection

Based on my old mail I wonder if someone has had time to think about the 
extensibility story.

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

Delivery-date: Wed, 01 Aug 2007 07:01:56 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: Re: Continued discussion of RADIUS Crypto-Agility
Date: Wed, 1 Aug 2007 09:01:24 +0200
Cc: [email-masked]

--nextPart2372691.scbP7hd1D1
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

a few clarifications below.

> Not only is it out of scope of the charter, it directly violates a
> number of the restrictions placed on the crypto-agility submissions from
> the actual members of the WG.  I, for one, have at least been aware of
> the RADSEC activities for a couple of years now but for some reason they
> have not deigned to inform the radext WG of them until now.

Just to make this clear: I am in no way affiliated with the guys who=20
originally created the RadSec implementation (OSC). I'm not part of "them".

I don't know why OSC didn't report on their implementation here earlier.=20
Probably because there were no interoperable other implementations, and so=
=20
taking it to a *standardisation* organisation wasn't deemed urgent. Just=20
speculating though.

OTOH, you mentioned in the session that you read their whitepaper when it w=
as=20
new. You could have brought it to the attention of radiusext yourself, even=
=20
if only to rebut it.

> To 1) ignore our charter (not to mention the (at best) disingenuous '?'
> regarding it in the presentation) and=20

As David said already: the same presentation was held at the opsawg meeting=
,=20
and I received word there that it *may* be possible that radiusext might =20
interpret its charter more loosely in the future. That's why I added that=20
question mark after the opsawg discussion took place. I did not act=20
disingenuous in any way. And I think I even said this during the=20
presentation.

> 2) ignore the written requirements that every one else had to follow seems
> to me at the very least arrogant.

You mean the charter? I think I expressed myself quite clearly on audio dur=
ing=20
the presentation that the proposal is not in the charter, submitted=20
independently and for information of interested RADIUS experts only. See al=
so=20
my original post announcing the draft. I asked for presentation slots=20
sufficient time ahead of the meeting.

You mean formality-wise? I submitted -00 before the deadline.

If there are some other written requirements to follow, please enlighten me=
=2E=20
It was my first IETF meeting after all, I may have missed something.

> Note that I am _not_ 'hostile to the idea' -- I am, however,=20
> hostile toward arrogant academics proffering "new" schemes (that have
> been around for years in one form or another) in direct contradiction of
> the rules the rest of us (who actually participate in the WG, not just
> drop by with our works of genius ;-) must follow.

=46irst, I am not an academic. I work at an ISP that caters universities an=
d=20
schools, that's about it.
Second, I never said this was either new or genious. I hope I made clear th=
at=20
this is a writeup to despcribe interoperability between existing=20
implementations. Both OSC and Stig Venaas got their due credit, and I also=
=20
*did* mention that RadSec has been around for some years now.
Third, I didn't just drop by. I kept reading radiusext for quite some time,=
=20
since RADIUS is of vital relevance when operating a global-scale RADIUS wla=
n=20
proxy environment, and knowing what's up is important. It's just that I=20
didn't have anything incredibly urgent or genious to say yet.

> Therefore, I must=20
> insist that the RADSEC proposal be treated as only a an informative
> presentation (in the nature of an informative liaison)

Which is precisely what I wanted it to be in the first place.

> and not accepted as a candidate for the crypto-agility solution.

While it wasn't the intention of the draft to intersect with crypto-agility=
=20
work items (the dynamic discovery part is the reason why we found the conce=
pt=20
sexy), the number of people that consider it as worth investigating accordi=
ng=20
to the straw poll provides some obvious evidence that it is at least worth=
=20
discussing.

To add a bit of constructivity to this mail, and leverage it above the=20
flame-war barrier, there is one aspect that RadSec or DTLS don't solve (and=
=20
I'm not sure either if keywrap can do): in some situations, it might be=20
useful to have end-to-end security between the first RADIUS server in a pro=
xy=20
chain (the one that the NAS is directly attached to, let's call it A) and t=
he=20
last one (the home server which verifies the credentials, lets call it C),=
=20
while all intermediates can not (lets call the set of those B). Our use cas=
e=20
for this is when A receives an Access-Accept, but needs more info about the=
=20
user ("How old is the user?") to put him either in a porn-filter VLAN or no=
t,=20
and so asks C. AFAICT, none of the proposals can make sure that only A can=
=20
ask this question - a server in B can always pretend to have its upstream=20
connection directly connected as a NAS, not another proxy server, assuming=
=20
that the servers in B also have (other) NASes directly connected and so in=
=20
some situations *could* legitimately ask this question (i.e. in keywrap=20
terms: they also have keying material to legitimately query C).

A clean solution to this problem seems tough.

BTW, solving this particular age verification problem could technically als=
o=20
be solved without such an end-to-end assertion by pushing the info from C t=
o=20
A unconditionally in the Access-Accept, not caring about A's backchannel or=
=20
the presence of B in the middle. Unfortunately, this is personal data which=
=20
can easily be tied to a real-life person, and so probably unconditionally=20
advertising it violates privacy laws in many countries.

In other news, the IPR discussion about Diameter and a possible affection o=
f=20
the patents in question by RadSec will be investigated from the side of=20
eduroam operations; I will let the group know what came out of this=20
investigation when it's done. Given the swamp that international patent=20
regulations are, this may take some time though.

Greetings,

Stefan Winter

=2D-=20
Stefan WINTER

Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e=
t de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked] =A0 =A0 Tel.:  =A0 =A0+352 424409-1
http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0  =A0 Fax: =A0 =A0 =A0+352 422=
473

--nextPart2372691.scbP7hd1D1
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart2372691.scbP7hd1D1--

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