Subject: FW: [Isms] FW: RADEXT WG Last Call on NAS ManagementAuthorizationSpecification

From: "David B. Nelson" <[email-masked]>
Date: Mon, 31 Mar 2008 13:58:56 -0400

Forwarding for Dave Harrington.  The wrong address was used for the RADEXT
WG mailing list.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Harrington
> Sent: Saturday, March 29, 2008 11:53 AM
> To: 'David B. Nelson'; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isms] FW: RADEXT WG Last Call on NAS
> ManagementAuthorizationSpecification
> 
> Hi,
> 
> I have reviewed draft-ietf-radext-management-authorization-02.txt for
> the WGLC and have comments.
> 
> ---------------------May fix editorial-------------------
> Description of issue
> Submitter name: David Harrington
> Submitter email address: [email-masked]
> Date first submitted: 3-29-08
> Reference: URL to e-mail describing problem, if available
> Document: draft-ietf-radext-management-authorization
> Comment type: E
> Priority: '1' Should fix
> Section: various
> 
> Requested changes:
> throughout:
> "Note that" is usually unnecessary. Don't we want readers to note
> everything in the document, or we wouldn't have said it?
> section 3:
> OLD: "While remote management by interactive CLI
>    sessions is carried over protocols, such as Telnet, Rlogin, and
> SSH,
>    these protocols are primarily for the delivery of terminal, or
>    pseudo-TTY services.  Note that, in this context, "SSH" means the
>    remote terminal service of SSH, not the more general protected
>    transport service of SSH."
> NEW: While remote management by interactive CLI
>    sessions is carried over protocols, such as Telnet, Rlogin, and the
> 
>    remote terminal service of SSH, these protocols are used in this
> context
>    for the delivery of terminal, or pseudo-TTY services."
> 
> section 6:
> OLD: "To aid in understanding of this document, it"
> NEW: "It"
> 
> section 6:
>    It is expected that the additional features of this document with
>    respect to remote access to the CLI of a NAS will be used in
>    conjunction with the existing practice regarding the NAS-Port-Type
>    attribute described in this section.
> Should this also be expected of other management interfaces if this is
> existing practice for the vendor?
> 
> section 8.2
> s/The acronyms used/The names used/
> 
> I suggest the descriptions of the values should identify the threats
> and the mitigation provided, in a clear and unambiguous manner. For
> example,
> OLD: The management session requires
>       protection in a secure or protected transport, that is supported
>       by the management access protocol and implementation.  The
> secure
>       transport MUST provide Confidentiality Protection.
> NEW: The transport ptotocol MUST protect against unauthorized
> disclosure of information.  The secure transport MUST provide
> encryption.
> 
> 
> section 13:
> I have made it a practice to identify the specific registries to be
> modified, and the specific changes that need to be made to each
> registry. This is easier for IANA, and removes the chance of IANA
> misinterpreting what is needed. You say "RADIUS Attributes registry" -
> is that the RADIUS Attribute Types registry, or the RADIUS Attribute
> Values registry, or both?
> 
> Will IANA know just which TBA should be replaced with which assigned
> type or value?
> 
> section 14:
> this entions accounting, but accounting is explicitly out of scope for
> this document.
> 
> Author's Address:
> Greg has no address.
> 
> 
> ---------------------Should fix editorial-------------------
> Description of issue
> Submitter name: David Harrington
> Submitter email address: [email-masked]
> Date first submitted: 3-29-08
> Reference: URL to e-mail describing problem, if available
> Document: draft-ietf-radext-management-authorization
> Comment type: E
> Priority: '1' Should fix
> Section: various
> 
> Requested changes:
> Section 3:
> OLD: "NETCONF (XML over HTTP/BEEP/SOAP)"
> NEW: "NETCONF (XML over SSH/BEEP/SOAP)"
> 
> Section 4:
> VACM is composed of multiple tables
> OLD: (VACM) table [RFC3415],
> NEW: (VACM) [RFC3415],
> 
> 
> 
> ---------------------Technical Issues-------------------
> Description of issue
> Submitter name: David Harrington
> Submitter email address: [email-masked]
> Date first submitted: 3-29-08
> Reference:
> Document: draft-ietf-radext-management-authorization
> Comment type: T
> Priority: '1' Should fix
> Section: various
> 
> section 8.1 (and elsewhere)
> Shouldn't Framed-Managament-Protocol "Web-based" (2) be HTTP or
> HTML/HTTP? Isn't HTTPS Framed-Management-Protocol=HTTP plus
> Transport-Protocol=TLS?
> Should we develop acronymns NETCONFS and SNMPS and CLIS so we can just
> lump the non-secure and secure versions into Configuration-based, and
> Polling-based names and so on?
> 
> Should SFTP and SCP be listed separately or lumped together?
> 
> section 8.2
>    The same "No Protection"
>    semantics are conveyed by omitting this attribute from an Access-
>    Accept packet."
> Why is this the default behavior? Wouldn't it be better to default to
> full security if the attribute is not present?
> 
> section 8.3
> The first paragrapgh says zero or more, while the fourth paragraph
> says you should not send two or more.
> OLD" "Zero or more"
> NEW: "Zero or one"
> 
> Paragraph 3 says what to do if one is receiverd; and paragraph talks
> about receiving more than one. What if zero are received?
> 
> Paragraph 3 says if "the policy rules are incorrectly
>    formatted, the NAS MUST treat the packet as if it had been an
> Access-
>    Reject."
> Doesn't this potentially override what the management protocol says
> should be done if the rules are incorrectly formatted? If the mgmt
> protocol defines an error condition for incorrectly formatted rules,
> that error won't be sent because the session is rejected, right? What
> happens if it is considered incorrect formatting to have an empty
> table of rules, but the operator is trying to gain mgmt access to set
> the policy rules into the table? Would RADIUS even know whether the
> rules were incorrectly formatted?
> 
> section 8.4
> I don't understand why we need a special Management-Privilege-Level
> attribute. This should be able to specified as a named policy in the
> Management-Policy-ID, such as "Level 1" and "Level 2", or even "1" and
> "2" and "3". Implementations simply need to map between the policy
> name and their  privilege-level policy implementation.
> 
> Different implementations might handle priivilege levels differently -
> some might use integers internally, others might use a different range
> of values (0-15 vs 1-16). Using Management-Policy-ID makes this simply
> a mapping exercise. This is a great opportunity to suggest standard
> names for privilege levels, and then vendors can map those standard
> names to the internal routines. If vendors provide an API, operators
> could name the policies as they wanted and map them to the vendors'
> APIs for invoking different privilege levels.
> 
> I do not understand "Using the Management-
>    Privilege-Level attribute with a Service-Type attribute with a
> value
>    of NAS-Prompt will have the effect of increasing the minimum
>    privilege level.  Conversely, it is NOT RECOMMENDED to use this
>    attribute with a Service-Type of Administrative, which may require
>    decreasing the maximum privilege level."
> How does it increase the minimum privilege level or decrease the
> maximum security level? Wouldn't this simply be
> implementation-dependent?
> 
> section 9:
> I have a concern about protocol versions. What if I want SSHv2 because
> I don't think SSHv1 is adequate? Should I be able to make the
> distinction? or is that simply an operator-provisioning task to
> disallow SSHv1 to the device?
> 
> I would change Example #4 to use a Management-Policy-ID="Level 15"
> rather than a Management-Privilege-Level=15
> 
> Example #5 mentions SNMPv3, but the attribute says only SNMP. If the
> operator should be permitted to decide which SNMP version can be used,
> then we need these specified as different management protocols. I
> think it would be better to leave the message-version decision to the
> SNMP standard. So I would change the example from "SNMPv3 access" to
> simply "SNMP access".
> 
> I would change the paragraph in example #5:
> OLD:   Note that there is currently no standardized way of
> implementing
>        this management policy mapping within SNMPv3.  Such mechanisms
>        are implementation specific.
> NEW: "A standardized way of mapping from Management-Policy-ID to a
> particular access control policy in SNMP is under research."
> 
> Example #6 talks about using the Secure Shell Transport Model, but
> most existing SNMP implementations do not support this yet. The
> "transport model" approach supports a binding between the SSH
> authenticated identity and the SNMP database access controls. Some
> SNMP implementations support running SNMP (any version) over an SSH
> tunnel, but they provide no such binding. I think it is an SNMP
> internal matter for SNMP access controls to say "they must use
> transport model to get database access". So I would remove the mention
> of the Secure Shell Transport Model from the example:
> OLD:    6.  SNMP secure Transport Model access, using the Secure Shell
>        Transport Model:
> NEW:    6.  SNMP access, via a fully-protected secure tunnel of SSH,
> to an
>         undefined management access level:
> 
> Example#8 doesn't mention which transport protocol should be used to
> provide security services. Should it, or is it intentional to allow
> any transport protocol be used that can provide
> Confidentiality-Protection?
> 
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
> 
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

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

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 31 Mar 2008 16:50:28 -0400

David Harrington writes...

> My intent was to ask you to spell out in detail which changes you 
> want made to which registry, and then to this document, so IANA 
> doesn't have to figure it out.

Yes, I got that point.  Thanks.  That issue will be clarified in -03.

> RFCs 4742, 43, and 44 defines transports for SSH, SOAP, and BEEP
> respectively. There is no separate mapping for HTTP.

Separate mapping?  I guess I need to learn a bunch more about NTECONF...

> Transport-Protocol still shows up in section 9, and possibly elsewhere
> in -02-.

Yes, but I've indicated that is an error in -02, and I described in a
previous posting to the RADEXT list that it was being removed, and why it
was being removed.  For the sake of comments on -02, please assume it is
gone.

> I was being sarcastic.

Sorry, I couldn't tell.  :-(

> > > Why is this the default behavior? Wouldn't it be better to
> >  > default to full security if the attribute is not present?
> >
> > In the interest of backward compatibility, it seems like de
> > default should be no security.
> 
> I disagree.

You disagree that we should optimize for backward compatibility, or you
disagree that defaulting to fully secure would hinder backwards
compatibility?

> > In view of this, it may be better or omit the phrase "or the
> > policy rules are incorrectly formatted".
> 
> Yes. I believe it would be better to drop that clause.

OK.

> So the "mapping" would simply be to take privilege level policy name
> "1" or "Level 1" and run it through an asctoint() function as part of
> the processing of management-policy-id.

The content of Management-Policy-Id is intended to be a flat name of local
scope.  The only valid operators on this name are strncmp() or
strncasecmp().  That is to say, no transforms are anticipated, other than a
lookup using it as a search key.  Anything else is fraught with
interoperability perils, IMO.

> Actually, it is only defining a recommendation for how to "name" the
> policies for use with management-policy-id.

If we can't (and don't) make such recommendations for the content of
Filter-Id, how could we do so for Management-Policy-Id?

> So if I set a level of '0' to be exactly the same as NAS-Prompt, and a
> level of '16' to be the same as Administrative, how does my usage
> increase/decrease privileges?

For all values of the Management-Privilege-Level attribute (call it X),
where 0 < X < 16, using that attribute in conjunction with a Service-Type
value of NAS-Prompt will elevate the effective CLI privilege level, and
similarly using that attribute in conjunction with a Service-Type value of
Administrative will lower the effective CLI privilege. 
 
> Transport-Protocol is still in the official version of -02-. See
> section 8.2, section #3 and #6, and section 14.

See above.  This is an oversight.

> I have a concern with removing transport-protocol.

Ah, that we can discuss.

> IPSec can provide a fully-secured tunnel, but it never authenticates
> the principal that is used at the application layer. nor does TLS.
> SSH provides user-authentication at a level above transport.

The current proposal, as intended by the -02 draft, is to provision a
minimum security requirement, that the NAS is expected to check and enforce,
as to whether or not the management transport protocol is (a)
integrity-protected (cryptographically check-summed) and (b) confidentiality
protected (encrypted).  In order to implement this proposal, the NAS (not
just the RADIUS Client portion of the NAS) MUST be able to determine if the
required protection is present.  Authentication of the principal is handled
via the traditional authentication mechanisms of RADIUS, and therefore need
not be handled by the secure transport.  It is possible, of course, that the
secure transport participates in providing the principal's identity to the
RADIUS Client for the purpose of authentication.

> If we remove the operator choice of tunnel protocol, I fear we might 
> under-specify what is needed to secure a management protocol.

Let's pursue this a bit.  If we specify the tunnel protocol, then we also
need to specify other properties.  Bernard Aboba pointed that out in his
commentary on the -01 draft.  We then specify the authentication mechanism.
This could involve specification of optional cipher suites.  We could
specify certificates, types of certificates, and certificate authorities,
etc.  This can get very complicated, very fast.  Do we really want or need
to go there?  :-)

My answer to Bernard's commentary was to step back and try to discern what
problem we really needed to solve.  While specifying all the security
properties and options of the secure transport protocol and its support
ecosystem may be needed in some environments, I think it is not required in
the vast majority of environments.  Let's solve a simple problem that we can
solve well, and then see if further work is needed later on, once we have
some deployment experience.

Knowing that your principal has been authenticated (and authorized) and that
the management session is protected from tampering and disclosure is
probably all that the RADIUS Server, and the system administrator, need to
provision.  Additional details, such as a list of acceptable tunnel
protocols, cipher suites, certificate chains, etc, can be provisioned on the
NAS in an implementation-specific fashion.

Delivery-date: Mon, 31 Mar 2008 20:53:14 +0000
From: "David B. Nelson" <[email-masked]>
To: "'David Harrington'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RADEXT WG Last Call on NAS ManagementAuthorizationSpecification
Date: Mon, 31 Mar 2008 16:50:28 -0400
Organization: Elbrys Networks, Inc.

David Harrington writes...

> My intent was to ask you to spell out in detail which changes you 
> want made to which registry, and then to this document, so IANA 
> doesn't have to figure it out.

Yes, I got that point.  Thanks.  That issue will be clarified in -03.

> RFCs 4742, 43, and 44 defines transports for SSH, SOAP, and BEEP
> respectively. There is no separate mapping for HTTP.

Separate mapping?  I guess I need to learn a bunch more about NTECONF...

> Transport-Protocol still shows up in section 9, and possibly elsewhere
> in -02-.

Yes, but I've indicated that is an error in -02, and I described in a
previous posting to the RADEXT list that it was being removed, and why it
was being removed.  For the sake of comments on -02, please assume it is
gone.

> I was being sarcastic.

Sorry, I couldn't tell.  :-(

> > > Why is this the default behavior? Wouldn't it be better to
> >  > default to full security if the attribute is not present?
> >
> > In the interest of backward compatibility, it seems like de
> > default should be no security.
> 
> I disagree.

You disagree that we should optimize for backward compatibility, or you
disagree that defaulting to fully secure would hinder backwards
compatibility?

> > In view of this, it may be better or omit the phrase "or the
> > policy rules are incorrectly formatted".
> 
> Yes. I believe it would be better to drop that clause.

OK.

> So the "mapping" would simply be to take privilege level policy name
> "1" or "Level 1" and run it through an asctoint() function as part of
> the processing of management-policy-id.

The content of Management-Policy-Id is intended to be a flat name of local
scope.  The only valid operators on this name are strncmp() or
strncasecmp().  That is to say, no transforms are anticipated, other than a
lookup using it as a search key.  Anything else is fraught with
interoperability perils, IMO.

> Actually, it is only defining a recommendation for how to "name" the
> policies for use with management-policy-id.

If we can't (and don't) make such recommendations for the content of
Filter-Id, how could we do so for Management-Policy-Id?

> So if I set a level of '0' to be exactly the same as NAS-Prompt, and a
> level of '16' to be the same as Administrative, how does my usage
> increase/decrease privileges?

For all values of the Management-Privilege-Level attribute (call it X),
where 0 < X < 16, using that attribute in conjunction with a Service-Type
value of NAS-Prompt will elevate the effective CLI privilege level, and
similarly using that attribute in conjunction with a Service-Type value of
Administrative will lower the effective CLI privilege. 
 
> Transport-Protocol is still in the official version of -02-. See
> section 8.2, section #3 and #6, and section 14.

See above.  This is an oversight.

> I have a concern with removing transport-protocol.

Ah, that we can discuss.

> IPSec can provide a fully-secured tunnel, but it never authenticates
> the principal that is used at the application layer. nor does TLS.
> SSH provides user-authentication at a level above transport.

The current proposal, as intended by the -02 draft, is to provision a
minimum security requirement, that the NAS is expected to check and enforce,
as to whether or not the management transport protocol is (a)
integrity-protected (cryptographically check-summed) and (b) confidentiality
protected (encrypted).  In order to implement this proposal, the NAS (not
just the RADIUS Client portion of the NAS) MUST be able to determine if the
required protection is present.  Authentication of the principal is handled
via the traditional authentication mechanisms of RADIUS, and therefore need
not be handled by the secure transport.  It is possible, of course, that the
secure transport participates in providing the principal's identity to the
RADIUS Client for the purpose of authentication.

> If we remove the operator choice of tunnel protocol, I fear we might 
> under-specify what is needed to secure a management protocol.

Let's pursue this a bit.  If we specify the tunnel protocol, then we also
need to specify other properties.  Bernard Aboba pointed that out in his
commentary on the -01 draft.  We then specify the authentication mechanism.
This could involve specification of optional cipher suites.  We could
specify certificates, types of certificates, and certificate authorities,
etc.  This can get very complicated, very fast.  Do we really want or need
to go there?  :-)

My answer to Bernard's commentary was to step back and try to discern what
problem we really needed to solve.  While specifying all the security
properties and options of the secure transport protocol and its support
ecosystem may be needed in some environments, I think it is not required in
the vast majority of environments.  Let's solve a simple problem that we can
solve well, and then see if further work is needed later on, once we have
some deployment experience.

Knowing that your principal has been authenticated (and authorized) and that
the management session is protected from tampering and disclosure is
probably all that the RADIUS Server, and the system administrator, need to
provision.  Additional details, such as a list of acceptable tunnel
protocols, cipher suites, certificate chains, etc, can be provisioned on the
NAS in an implementation-specific fashion.

Delivery-date: Mon, 31 Mar 2008 18:02:46 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'David Harrington'" <[email-masked]>, <[email-masked]>
Subject: RE: RADEXT WG Last Call on NAS Management Authorization Specification
Date: Mon, 31 Mar 2008 14:00:30 -0400
Organization: Elbrys Networks, Inc.

David Harrington writes...

> I have reviewed draft-ietf-radext-management-authorization-02.txt
> for the WGLC and have comments.

Thanks you!

> "Note that" is usually unnecessary.

OK.  That's a bit of flowery writing that isn't needed.

>    sessions is carried over protocols, such as Telnet, Rlogin,
>    and SSH, these protocols are primarily for the delivery of 
>    terminal, or pseudo-TTY services.  Note that, in this context,
>    "SSH" means the remote terminal service of SSH, not the more 
>    general protected transport service of SSH."
> NEW: While remote management by interactive CLI sessions is 
>    carried over protocols, such as Telnet, Rlogin, and the
>    remote terminal service of SSH, these protocols are used 
>    in this context for the delivery of terminal, or pseudo-TTY
>    services."

OK.

> OLD: "To aid in understanding of this document, it"

Sure.  The point I was trying to convey here is that this document is not
creating the usage being described here, but simply reporting it.
 
> existing practice for the vendor?

I'm not sure what you are trying to ask.  We acknowledge an existing
practice and indicate that it is compatible with the usages defined in this
document.

> s/The acronyms used/The names used/

OK.
 
> OLD: The management session requires protection in a secure or
>     protected transport, that is supported by the management access
>     protocol and implementation.  The secure transport MUST provide
>     Confidentiality Protection.
> NEW: The transport protocol MUST protect against unauthorized

OK.  I think that confidentiality implies the use of encryption, unless the
medium of communication is physically secured, but I have no objection to
your suggested text.

> Values registry, or both?

Both, which one depending upon context.

> Will IANA know just which TBA should be replaced with which assigned

IANA gets to make up the numeric values, and hopefully can tell which is an
Attribute ID code and which is a value, but we could use a notation such as
TBA-A (for attribute IDs) and TBA-V (for values), if you think that would be
helpful.

> section 14:
> this mentions accounting, but accounting is explicitly out of 
> scope for this document.

Not entirely.  Section 12 indicates that some attributes may be included in
Accounting-Request packets.
 
> Greg has no address.

Well, he does have one -- he just hasn't provided it the current draft.
This omission will be corrected eventually -- certainly during AUTH84, if
not before.

> NEW: "NETCONF (XML over SSH/BEEP/SOAP)"

Well, OK, I guess.  Does NETCONF not have a profile for transport over HTTP?
I'm a bit confused on that point.

> OLD: (VACM) table [RFC3415],

OK.

> Shouldn't Framed-Management-Protocol "Web-based" (2) be HTTP or
> HTML/HTTP?

Uh, yes...

> Isn't HTTPS Framed-Management-Protocol=HTTP plus Transport-Protocol=TLS?

Yes, but in the -02 revision the Management-Transport-Protocol Attribute has
been removed, because it seemed like unnecessary over-specification, and
replaced with the Management-Transport-Protection Attribute.  For that
reason, your suggestion doesn't quite work.

> Should we develop acronyms NETCONFS and SNMPS and CLIS so we can just

Well, the tradition of RADIUS documents is that we describe how to provision
existing services using RADIUS Attributes.  We stay away from actually
defining the services being provisioned, and simply provide references as
appropriate.  In that light, I think it might be inappropriate to define new
acronyms for such services in this document.

> section 8.2
>    The same "No Protection" semantics are conveyed by omitting this 
>    attribute from an Access-Accept packet."

In the interest of backward compatibility, it seems like de default should
be no security.

> section 8.3
> The first paragraph says zero or more, while the fourth paragraph

OK.

> Paragraph 3 says what to do if one is received; and paragraph talks

If zero are received no management policy is applied to the provisioned
service.  That's universally true of RADIUS service provisioning Attributes.
The absence of an Attribute generally has no significance; it does not cause
any action at the NAS.

> Paragraph 3 says if "the policy rules are incorrectly formatted, the
> NAS MUST treat the packet as if it had been an Access-Reject."
> should be done if the rules are incorrectly formatted?

What management protocol?  Are you alluding to something like the SNMP VACM?

> If the mgmt protocol defines an error condition for incorrectly 
> formatted rules, that error won't be sent because the session is 
> rejected, right?

Well, this is a bit murky.  Traditionally, RADIUS Servers provision a
service to be delivered to the user at the NAS, and the NAS is responsible
for delivering that service, and not some other.  If the NAS cannot deliver
the service (and it knows what it is) then traditionally the NAS has been
required to reject access altogether.   The access protocol may or may not
have an error channel for the NAS to signal to the user that the service has
been denied.

> What happens if it is considered incorrect formatting to have an 
> empty table of rules, but the operator is trying to gain mgmt access
> to set the policy rules into the table?  Would RADIUS even know
> whether the rules were incorrectly formatted?

Probably not.  The NAS might know, because the term "NAS" describes the
entirety of the network device or host device that contains the RADIUS
Client.  The RADIUS Client would almost certainly not know.

In view of this, it may be better or omit the phrase "or the policy rules
are incorrectly formatted".

> name and their  privilege-level policy implementation.

Well, it's just that sort of "mapping" that this attribute was introduced to
avoid.  There are a significant number of currently deployed implementations
that provision CLI access control using an integer-valued parameter.  It is
what it is.  This is simply an attempt to recognize that practice and
provide a way to provision that type of access control via RADIUS.  We are
not attempting (not should we) to redefine how CLI access control works in
NASes, just how RADIUS can be use to provision it.

> This is a great opportunity to suggest standard names for privilege 
> levels, and then vendors can map those standard names to the internal 
> routines.

Hmmm...  I think that type of standardization crosses the line into
"defining the service" and would be out of scope for this document.  I'd
like to solicit some additional WG comment on this suggestion, before we go
down that path.

> I do not understand "Using the Management-Privilege-Level attribute 
> with a Service-Type attribute with a value of NAS-Prompt will have the
> effect of increasing the minimum  privilege level.  Conversely, it is 
> NOT RECOMMENDED to use this attribute with a Service-Type of
> Administrative, which may require decreasing the maximum privilege 
> level."
> maximum security level?

Well, NAS-Prompt is the non-privileged CLI service and Administrative is the
privileged CLI service.  While implementations may vary, my understanding is
that NAS-Prompt has no privileges and Administrative has all privileges
(like root).  Since there are only two choices, this is pretty much a binary
thing -- on or off.

> Wouldn't this simply be implementation-dependent?

It might be...
 
> disallow SSHv1 to the device?

The ability to specify particular transport protocols has been removed from
the -02 version, and thus there is no way to specify a particular version of
a particular transport protocol.  I think this comes down to what is
necessary and sufficient to solve the "80% problem", i.e. what will work
sufficiently well in 80% of the possible deployment scenarios and use cases.
I think we can easily fall into the trap of over-specifying the solution,
and adding way more complexity than anyone will ever actually use
(correctly).

> rather than a Management-Privilege-Level=15

This is dependent on resolution of a previous comment.

> SNMP standard. So I would change the example from "SNMPv3 access" to

I think that the "v3" is as editing artifact, left over from the -01 version
of the draft.

>        implementing this management policy mapping within SNMPv3.
>        Such mechanisms are implementation specific.

OK, that's fine.  We can use text along those lines.

>         to an undefined management access level:

Well, there's something else wrong with Example 6.  It still uses the
removed [Management-]Transport-Protocol attribute.  (There are several
examples with this problem.)  I think that this should be revised to
indicate SNMP access using a particular protection level (i.e.
Management-Transport-Protection).

I'll submit some suggested text in a separate message dealing with errata in
the examples.  Perhaps we can continue the discussion on that basis?
 
> provide security services.

Once again, the Management-Transport-Protocol attribute has been removed
from the -02 version of the draft.

> Should it, or is it intentional to allow any transport protocol to be 
> used that can provide Confidentiality-Protection?

It is intended that any transport protocol that can meet or exceed the
specified minimum security protection requirement (integrity or integrity
and confidentiality) can be used for the session.

Thanks, once again, for your thorough and insightful review comments.

Regards,

Dave Nelson

Delivery-date: Mon, 31 Mar 2008 18:02:26 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: FW: [Isms] FW: RADEXT WG Last Call on NAS ManagementAuthorizationSpecification
Date: Mon, 31 Mar 2008 13:58:56 -0400
Organization: Elbrys Networks, Inc.

Delivery-date: Fri, 28 Mar 2008 11:37:41 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: Reminder of RADEXT WG Last Call on NAS Management Authorization Specification
Date: Fri, 28 Mar 2008 07:36:42 -0400

This is a reminder of the ongoing RADEXT WG Last Call on the NAS =
Management
Authorization specification prior to its being sent on to the IESG for
consideration as a Proposed Standard.

WGLC on this document ends today.  Please take a moment in the next few =
days
to read the latest version of this document and send comments to the =
list.
Please report any errors or suggested corrections.  If you think the
document is OK as is, please report that, too.  Thanks!

-------------------------------------------------------------------------=
-
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Bernard Aboba
Sent: Tuesday, February 26, 2008 11:12 PM
To: [email-masked]
Subject: RADEXT WG Last Call on NAS Management Authorization =
Specification

This is to announce a RADEXT WG last call on the NAS Management
Authorization specification prior to its being sent on to the IESG for
consideration as a Proposed Standard.=A0 The document is available for
inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authoriz=
ati
on-02.txt
=A0
RADEXT WG last call will last until Friday, March 28, 2008.=A0=A0 Please =
respond
to this WG last call announcement indicating whether or not you approve =
of
the document, even if you have no comments to offer.=A0 If you have =
comments
to offer, please send them to the RADEXT WG mailing list in the format
described in the RADEXT WG Issues list:=A0=20
http://www.drizzle.com/~aboba/RADEXT/

Delivery-date: Thu, 27 Mar 2008 02:41:11 +0000
Date: Wed, 26 Mar 2008 22:40:53 -0400
To: [email-masked]
From: David Mitton <[email-masked]>
Subject: list test
Cc: [email-masked]

Fourth test:  (1 & 2 Failed)

Checking if I can post to the list from this machine and receive it back.
If this message does not appear on the list, I need to know who can 
help me troubleshoot the problem.

Dave.

Delivery-date: Tue, 25 Mar 2008 00:43:55 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 24 Mar 2008 20:43:09 -0400
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Accept-Language: en-US
acceptlanguage: en-US

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

I am okay with doing this work in RADEXT *but* we need to recharter RADEXT.=
  Since RADSEC introduces a new tranpsort and new security scheme which is =
against the current charter.

________________________________
From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of [email-masked]
Sent: Friday, March 14, 2008 11:10 AM
To: [email-masked]
Subject: RADEXT WG Consensus call on acceptance of RADSEC as a work item

This is a consensus call for acceptance of RADSEC (and the Status Update dr=
aft) as a RADEXT WG work item.   The
consensus call will last until March 28, 2008.  Please send email to the li=
st stating whether you are in favor or opposed
to accepting RADSEC as a RADEXT WG work item.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16608" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 name=3D"Compose message area=
"=20
CanvasTabStop=3D"true">
<DIV><SPAN class=3D742364100-25032008><FONT face=3DVerdana color=3D#0000ff =
size=3D2>I am=20
okay with doing this work in RADEXT *but* we need to recharter RADEXT.&nbsp=
;=20
Since RADSEC introduces a new tranpsort and new security scheme which is ag=
ainst=20
the current charter.</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px soli=
d; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of=20
  </B>[email-masked]<BR><B>Sent:</B> Friday, March 14, 2008 11:1=
0=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> RADEXT WG Cons=
ensus=20
  call on acceptance of RADSEC as a work item<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV><FONT face=3DArial size=3D2>This is a consensus call for acceptance =
of RADSEC=20
  (and the Status Update draft) as a RADEXT WG work item.&nbsp;&nbsp;=20
  The</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>consensus call will last until March 28,=
=20
  2008.&nbsp; Please send email to the list stating whether you are in favo=
r or=20
  opposed</FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>to accepting RADSEC as a RADEXT WG work =
item.=20
  </FONT></DIV></BLOCKQUOTE></BODY></HTML>

--_000_8A8CFE8F89C38B41A749C19328C76D6301E4BFDEF3exchange02bri_--

Delivery-date: Sun, 23 Mar 2008 18:42:43 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: Minutes from IETF 71
Date: Sun, 23 Mar 2008 11:41:44 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0194_01C88CDA.DE6E7840
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If you took minutes from IETF 71, please send them to Dave or myself. 
------=_NextPart_000_0194_01C88CDA.DE6E7840
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=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6001.18000" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true"=20
name=3D"Compose message area">
<DIV><FONT face=3DArial size=3D2>If you took minutes from IETF 71, =
please send them=20
to Dave or myself. </FONT></DIV></BODY></HTML>

------=_NextPart_000_0194_01C88CDA.DE6E7840--

Delivery-date: Thu, 20 Mar 2008 18:02:01 +0000
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 20 Mar 2008 18:00:55 +0000
Subject: FW: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item 
Accept-Language: en-US
acceptlanguage: en-US

--_004_C7B67062D31B9E459128006BAAD0DC3D0757D1BB90G6W0269americ_
Content-Type: multipart/alternative;
	boundary="_000_C7B67062D31B9E459128006BAAD0DC3D0757D1BB90G6W0269americ_"

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

Came to my attention that my previous email, shown below, was not readable =
my several people on list.  Resending.

MS

_____________________________________________
From: Sanchez, Mauricio (ProCurve)
Sent: Thursday, March 20, 2008 9:55 AM
To: [email-masked]
Cc: 'Bernard Aboba'
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work ite=
m

I am in favor of accepting RADSEC and the status update draft as RADEXT WG =
work items.

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Chief Security Architect

ProCurve Networking by HP
Hewlett Packard
8000 Foothills Boulevard, ms 5541
Roseville CA, 95747-5557
916.785.1910 Tel
916.785.1815 Fax
[email-masked]

--------------------------------------------

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

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style>.EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800=
000 2px solid; }</style>
</head>
<body>
<font face=3D"Calibri, sans-serif" size=3D"2">
<div><font color=3D"#1F497D">Came to my attention that my previous email, s=
hown below, was not readable my several people on list.&nbsp; Resending.</f=
ont></div>
<div><font color=3D"#1F497D">&nbsp;</font></div>
<div><font color=3D"#1F497D">MS</font></div>
<div><font face=3D"Calibri, sans-serif" color=3D"#1F497D">&nbsp;</font></di=
v>
<div><font face=3D"Tahoma, sans-serif" size=3D"2">_________________________=
____________________<br>

<b>From:</b> Sanchez, Mauricio (ProCurve) <br>

<b>Sent:</b> Thursday, March 20, 2008 9:55 AM<br>

<b>To:</b> [email-masked]<br>

<b>Cc:</b> 'Bernard Aboba'<br>

<b>Subject:</b> RE: RADEXT WG Consensus call on acceptance of RADSEC as a w=
ork item </font></div>
<div><font face=3D"Calibri, sans-serif">&nbsp;</font></div>
<div><font face=3D"Calibri, sans-serif">&nbsp;</font></div>
<div><font face=3D"Calibri, sans-serif">I am in favor of accepting RADSEC a=
nd the status update draft as RADEXT WG work items.</font></div>
<div><font face=3D"Calibri, sans-serif">&nbsp;</font></div>
<div><font face=3D"Calibri, sans-serif">Cheers,</font></div>
<div><font face=3D"Calibri, sans-serif">MS</font></div>
<div><font face=3D"Calibri, sans-serif">&nbsp;</font></div>
<div style=3D"margin-top: 5pt; margin-bottom: 5pt; "><font face=3D"Verdana,=
 sans-serif" size=3D"1">--------------------------------------------
<br>

<b>Mauricio Sanchez, CISSP</b> <br>

Chief Security Architect <br>

<br>

<b>ProCurve Networking by HP</b> <br>

Hewlett Packard <br>

8000 Foothills Boulevard, ms 5541<br>

Roseville CA, 95747-5557 <br>

916.785.1910 Tel <br>

916.785.1815 Fax <br>

[email-masked] <br>

<img src=3D"cid:f2d85012-245a-4aa7-8344-00595de4bd35"><font face=3D"Calibri=
, sans-serif" size=3D"2">
<br>

</font>--------------------------------------------</font></div>
<div><font face=3D"Calibri, sans-serif">&nbsp;</font></div>
<div><font face=3D"Calibri, sans-serif">&nbsp;</font></div>
<div><font face=3D"Calibri, sans-serif">&nbsp;</font></div>
</font>
</body>
</html>

--_000_C7B67062D31B9E459128006BAAD0DC3D0757D1BB90G6W0269americ_--

--_004_C7B67062D31B9E459128006BAAD0DC3D0757D1BB90G6W0269americ_
Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 1.jpg"
Content-Description: Picture (Device Independent Bitmap) 1.jpg
Content-Disposition: inline;
	filename="Picture (Device Independent Bitmap) 1.jpg";
	creation-date="Thu, 20 Mar 2008 18:00:56 GMT";
	modification-date="Thu, 20 Mar 2008 18:00:56 GMT"
Content-ID: <f2d85012-245a-4aa7-8344-00595de4bd35>
Content-Transfer-Encoding: base64

--_004_C7B67062D31B9E459128006BAAD0DC3D0757D1BB90G6W0269americ_--

Delivery-date: Thu, 20 Mar 2008 17:47:00 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 20 Mar 2008 13:44:49 -0400

[email-masked] <> scribbled on Thursday, March 20, 2008
12:39 PM:

> Stefan Winter writes....
> 
>> could you give a short reminder on why this particular approval
>> (NIST) is of crucial importance?
> 
> I invite others who are more directly involved to add their
> thoughts, but as I understand it, use of NIST certified
> cryptographic algorithms and modes is a prerequisite to
> obtaining FIPS 140-2 certification, which is a requirement for
> selling certain networking products to certain US Federal Government
> departments. 
> 
> There may be collateral benefit in marketing such products to
> security-sensitive private sector markets, such as banking, finance
> or healthcare. 

And other governmental entities...

> 
> 
> 
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in
> a single line as the message text body.

Delivery-date: Thu, 20 Mar 2008 17:38:02 +0000
From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: Bernard Aboba <[email-masked]>
Date: Thu, 20 Mar 2008 17:36:36 +0000
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item 
Accept-Language: en-US
acceptlanguage: en-US

Delivery-date: Thu, 20 Mar 2008 16:40:55 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 20 Mar 2008 12:38:36 -0400
Organization: Elbrys Networks, Inc.

Stefan Winter writes....

> could you give a short reminder on why this particular approval (NIST)
> is of crucial importance?

I invite others who are more directly involved to add their thoughts, but as
I understand it, use of NIST certified cryptographic algorithms and modes is
a prerequisite to obtaining FIPS 140-2 certification, which is a requirement
for selling certain networking products to certain US Federal Government
departments.

There may be collateral benefit in marketing such products to
security-sensitive private sector markets, such as banking, finance or
healthcare. 

Delivery-date: Thu, 20 Mar 2008 15:28:30 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: [email-masked]
Subject: Re: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 20 Mar 2008 16:27:26 +0100

--nextPart1702924.Uq3jKHCrxv
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

> There are really two questions -- (a) "is the algorithm and mode suitably
> strong?" and (b) "is it NIST-approved?"  The former is easier to satisfy.

could you give a short reminder on why this particular approval (NIST) is o=
f=20
crucial importance?

Thanks,

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

--nextPart1702924.Uq3jKHCrxv
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart1702924.Uq3jKHCrxv--

Delivery-date: Thu, 20 Mar 2008 06:06:13 +0000
From: Mudit Goel <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 19 Mar 2008 23:05:29 -0700
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item 
Accept-Language: en-US
acceptlanguage: en-US

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

I am in favor of accepting RADSEC and the status update draft as part of th=
e RADEXT WG workitem.

This specification will help solve some of the key problems faced today by =
our RADIUS customers.

Regards,
Mudit Goel
Principal Development Manager
Enterprise Networking Group
Microsoft.

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.w3.org/TR/REC-html40" xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope=
/" xmlns:D=3D"DAV:" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas=
.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.or=
g/2001/04/xmlenc#" xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xm=
lns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http=
://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf=3D"http://schemas.micros=
oft.com/data/udc/xmlfile" xmlns:wf=3D"http://schemas.microsoft.com/sharepoi=
nt/soap/workflow/" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-c=
ompatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/o=
mml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relation=
ships" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/t=
ypes" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/me=
ssages" xmlns=3D"http://www.w3.org/TR/REC-html40">

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

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

<div class=3DSection1>

<p class=3DMsoNormal>I am in favor of accepting RADSEC and the status updat=
e
draft as part of the RADEXT WG workitem. <o:p></o:p></p>

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

<p class=3DMsoNormal>This specification will help solve some of the key pro=
blems
faced today by our RADIUS customers.<o:p></o:p></p>

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

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

<p class=3DMsoNormal>Mudit Goel<o:p></o:p></p>

<p class=3DMsoNormal>Principal Development Manager<o:p></o:p></p>

<p class=3DMsoNormal>Enterprise Networking Group<o:p></o:p></p>

<p class=3DMsoNormal>Microsoft.<o:p></o:p></p>

</div>

</body>

</html>

--_000_456A5146F9319946A179B523B9FC91D60D9E28CBC5NAEXMSGC114re_--

Delivery-date: Wed, 19 Mar 2008 17:06:44 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Wed, 19 Mar 2008 10:04:32 -0700
From: "Matthew Gast" <[email-masked]>
To: <[email-masked]>

+1

Matthew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Mike McCauley
Sent: Tuesday, March 18, 2008 6:17 AM
To: [email-masked]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work
item

I support taking on RADSEC as a WG work item.

--=20
Mike McCauley                               [email-masked]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia
http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

Delivery-date: Tue, 18 Mar 2008 13:18:49 +0000
From: Mike McCauley <[email-masked]>
To: [email-masked]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Tue, 18 Mar 2008 23:17:27 +1000

I support taking on RADSEC as a WG work item.

-- 
Mike McCauley                               [email-masked]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

Delivery-date: Mon, 17 Mar 2008 19:17:34 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: Consensus at IETF 71 on RADIUS Extended Attributes
Date: Mon, 17 Mar 2008 12:17:05 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_00CB_01C88828.D08AB600
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

llAt IETF 71, we had a WG consensus call on the changes made in the =
Extended Attributes -01 draft:

1. Do you support the increase in the Extended Attribute space from one =
to two octets?
2. Do you support enabling existing RADIUS attributes to be encoded =
within the Extended Attribute format?=20

On Issue #1, the consensus of the people in the room was IN FAVOR. =20
On Issue #2, the consensus of the people in the room was AGAINST. =20

We will continue to run this same consensus call on the RADEXT WG list.=20

------=_NextPart_000_00CB_01C88828.D08AB600
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=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6001.18000" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true"=20
name=3D"Compose message area"><FONT face=3DArial size=3D2>
<DIV><SPAN=20
style=3D"MARGIN-TOP: 0px; DISPLAY: inline; FONT-SIZE: 70%; Z-INDEX: 2; =
MARGIN-LEFT: 5px; COLOR: #330066; FONT-FAMILY: Wingdings; POSITION: =
absolute; mso-special-format: bullet; mso-color-index: 3">l</SPAN><SPAN=20
style=3D"MARGIN-TOP: -15px; DISPLAY: inline; FONT-SIZE: 70%; Z-INDEX: 1; =
MARGIN-LEFT: -10px; COLOR: #330066; FONT-FAMILY: Wingdings; POSITION: =
absolute; mso-special-format: bullet; mso-color-index: 3">l</SPAN>At=20
IETF 71, we had a WG consensus call on the changes made in the Extended=20
Attributes -01 draft:</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. Do you support the increase in the Extended Attribute space from =
one to=20
two octets?</DIV>
<DIV>2. Do you support enabling existing RADIUS attributes to be encoded =
within=20
the Extended Attribute format? </DIV>
<DIV>&nbsp;</DIV>
<DIV>On Issue #1, the consensus of the people in the room was IN =
FAVOR.&nbsp;=20
</DIV>
<DIV>On Issue #2, the consensus of the people in the room was =
AGAINST.&nbsp;=20
</DIV>
<DIV>&nbsp;</DIV>
<DIV>We will continue to run this same consensus call on the RADEXT WG =
list.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00CB_01C88828.D08AB600--

Delivery-date: Mon, 17 Mar 2008 14:41:57 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Mon, 17 Mar 2008 07:41:18 -0700

I support taking on RADSEC as a WG work item.

--------------------------------------------------
From: "Clint Chaplin" <[email-masked]>
Sent: Sunday, March 16, 2008 6:21 PM
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item

 I support this.

--------------------------------------------------------------------------------
From: "Klaas Wierenga" <[email-masked]>
Sent: Saturday, March 15, 2008 7:55 AM
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item

  I support having RADSEC as a WG item.

 Klaas

--------------------------------------------------------------------------------
From: Stephen Hanna
Sent: Sunday, March 16, 2008 4:35 PM
To: [email-masked] ; [email-masked]
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item

I am in favor of having RADSEC as a RADEXT WG work item. This specification 
clearly meets the needs of an important group of RADIUS users.

Thanks,

Steve

--------------------------------------------------------------------------------
From: [email-masked] [mailto:[email-masked]] On 
Behalf Of [email-masked]
Sent: Friday, March 14, 2008 11:10 AM
To: [email-masked]
Subject: RADEXT WG Consensus call on acceptance of RADSEC as a work item

This is a consensus call for acceptance of RADSEC (and the Status Update 
draft) as a RADEXT WG work item.   The
consensus call will last until March 28, 2008.  Please send email to the 
list stating whether you are in favor or opposed
to accepting RADSEC as a RADEXT WG work item. 

Delivery-date: Mon, 17 Mar 2008 13:46:39 +0000
Date: Mon, 17 Mar 2008 13:45:42 +0000 (GMT)
From: David Mitton <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: List test

Third attempt to post to list  (0 for 2)
If found in a reject folder, please return with error or diag
Dave.

Delivery-date: Mon, 17 Mar 2008 07:24:43 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: [email-masked]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Mon, 17 Mar 2008 08:23:46 +0100

--nextPart1233012.Pi5lrI9jgL
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

> This is a consensus call for acceptance of RADSEC (and the Status Update
> draft) as a RADEXT WG work item.   The consensus call will last until Mar=
ch
> 28, 2008.  Please send email to the list stating whether you are in favor
> or opposed to accepting RADSEC as a RADEXT WG work item.

Probably needless to say: I support acceptance :-)

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

--nextPart1233012.Pi5lrI9jgL
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart1233012.Pi5lrI9jgL--

Delivery-date: Mon, 17 Mar 2008 06:06:00 +0000
Date: Mon, 17 Mar 2008 07:01:44 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item

Glen Zorn wrote:
> Actually, it meets the needs of _no_ group of RADIUS users, since it is
> not RADIUS. 

  You're very clear on what RADIUS is.  One of the points of feedback
was that the guidelines document needed to state the key assumptions
behind RADIUS.  It looks like you could help here.

  Alan DeKok.

Delivery-date: Mon, 17 Mar 2008 01:21:57 +0000
Date: Sun, 16 Mar 2008 18:21:17 -0700
From: "Clint Chaplin" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Cc: [email-masked]

I support this.

On 3/14/08, [email-masked] <[email-masked]> wrote:
>
>
> This is a consensus call for acceptance of RADSEC (and the Status Update
> draft) as a RADEXT WG work item.   The
> consensus call will last until March 28, 2008.  Please send email to the
> list stating whether you are in favor or opposed
> to accepting RADSEC as a RADEXT WG work item.

-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA

Delivery-date: Sun, 16 Mar 2008 23:53:52 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Stephen Hanna'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Sun, 16 Mar 2008 19:53:09 -0400

[email-masked] <> scribbled on Sunday, March 16, 2008 7:36
PM:

> I am in favor of having RADSEC as a RADEXT WG work item. This
> specification clearly meets the needs of an important group of RADIUS
> users. 

Actually, it meets the needs of _no_ group of RADIUS users, since it is
not RADIUS.  It does appear that RADSEC (not the current draft, which is
ill-specified at best) is useful to quite a few AAA users but that is an
entirely different thing.

...

Delivery-date: Sun, 16 Mar 2008 23:41:36 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Sun, 16 Mar 2008 19:35:57 -0400
From: "Stephen Hanna" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C887BE.33BB65C2
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am in favor of having RADSEC as a RADEXT WG work item. This
specification clearly meets the needs of an important group of RADIUS
users.
=20
Thanks,
=20
Steve

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Friday, March 14, 2008 11:10 AM
To: [email-masked]
Subject: RADEXT WG Consensus call on acceptance of RADSEC as a work item

This is a consensus call for acceptance of RADSEC (and the Status Update
draft) as a RADEXT WG work item.   The
consensus call will last until March 28, 2008.  Please send email to the
list stating whether you are in favor or opposed
to accepting RADSEC as a RADEXT WG work item.=20

------_=_NextPart_001_01C887BE.33BB65C2
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3268" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 name=3D"Compose message =
area"=20
CanvasTabStop=3D"true">
<DIV dir=3Dltr align=3Dleft><SPAN class=3D750463423-16032008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I am in favor of having RADSEC as a RADEXT WG =
work item.=20
This specification clearly meets the needs of an important group of =
RADIUS=20
users.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D750463423-16032008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D750463423-16032008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D750463423-16032008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D750463423-16032008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Steve</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of=20
</B>[email-masked]<BR><B>Sent:</B> Friday, March 14, 2008 =
11:10=20
AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> RADEXT WG =
Consensus=20
call on acceptance of RADSEC as a work item<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT face=3DArial size=3D2>This is a consensus call for acceptance =
of RADSEC=20
(and the Status Update draft) as a RADEXT WG work item.&nbsp;&nbsp;=20
The</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>consensus call will last until March =
28,=20
2008.&nbsp; Please send email to the list stating whether you are in =
favor or=20
opposed</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to accepting RADSEC as a RADEXT WG work =
item.=20
</FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C887BE.33BB65C2--

Delivery-date: Sat, 15 Mar 2008 19:58:08 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-radext-extended-attributes-03.txt 
Date: Sat, 15 Mar 2008 13:00:02 -0700 (PDT)

--NextPart

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

	Title           : Extended Remote Authentication Dial In User Service (RADIUS) Attributes
	Author(s)       : Y. Li, et al.
	Filename        : draft-ietf-radext-extended-attributes-03.txt
	Pages           : 13
	Date            : 2008-03-15

For the Remote Authentication Dial In User Service (RADIUS) protocol
to continue to support new applications the RADIUS attribute type
space must be extended beyond the current limit of 255 possible
attribute types while maintaining backwards compatibility with the
existing protocol.  This document defines a mechanism to accomplish
that task, along with standard methods to group together related
attributes and to encode values that don't fit into 253 octets.

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

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

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

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

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

--NextPart--

Delivery-date: Sat, 15 Mar 2008 19:28:28 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-radext-extended-attributes-02.txt 
Date: Sat, 15 Mar 2008 12:30:01 -0700 (PDT)

--NextPart

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

	Title           : Extended Remote Authentication Dial In User Service (RADIUS) Attributes
	Author(s)       : Y. Li, et al.
	Filename        : draft-ietf-radext-extended-attributes-02.txt
	Pages           : 13
	Date            : 2008-03-15

For the Remote Authentication Dial In User Service (RADIUS) protocol
to continue to support new applications the RADIUS attribute type
space must be extended beyond the current limit of 255 possible
attribute types while maintaining backwards compatibility with the
existing protocol.  This document defines a mechanism to accomplish
that task, along with standard methods to group together related
attributes and to encode values that don't fit into 253 octets.

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

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

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

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

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

--NextPart--

Delivery-date: Sat, 15 Mar 2008 14:56:27 +0000
Date: Sat, 15 Mar 2008 15:55:49 +0100
From: Klaas Wierenga <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item

[email-masked] wrote:
> This is a consensus call for acceptance of RADSEC (and the Status Update 
> draft) as a RADEXT WG work item.   The
> consensus call will last until March 28, 2008.  Please send email to the 
> list stating whether you are in favor or opposed
> to accepting RADSEC as a RADEXT WG work item.

I support having RADSEC as a WG item.

Klaas

Delivery-date: Sat, 15 Mar 2008 09:44:27 +0000
Date: Sat, 15 Mar 2008 10:39:56 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item

[email-masked] wrote:
> This is a consensus call for acceptance of RADSEC (and the Status Update
> draft) as a RADEXT WG work item.   The
> consensus call will last until March 28, 2008.  Please send email to the
> list stating whether you are in favor or opposed
> to accepting RADSEC as a RADEXT WG work item.

  I am in favor.

  I also have no object to it going to another BoF/WG.

  Alan DeKok.

Delivery-date: Sat, 15 Mar 2008 05:02:43 +0000
From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Sat, 15 Mar 2008 01:01:20 -0400

[email-masked] <> scribbled on Friday, March 14, 2008
11:10 AM:

> This is a consensus call for acceptance of RADSEC (and the
> Status Update draft) as a RADEXT WG work item.   The
> consensus call will last until March 28, 2008.  Please send
> email to the list stating whether you are in favor or opposed
> to accepting RADSEC as a RADEXT WG work item.

Opposed.

Delivery-date: Fri, 14 Mar 2008 16:13:37 +0000
Date: Fri, 14 Mar 2008 12:12:42 -0400
From: Yoshihiro Ohba <[email-masked]>
To: Lakshminath Dondeti <[email-masked]>
Cc: [email-masked], Tim Polk <[email-masked]>, [email-masked], [email-masked], "'eap-WG'" <[email-masked]>
Subject: Re: [eap] [HOKEY] ERX fraud issue

On Wed, Mar 12, 2008 at 10:47:44PM -0700, Lakshminath Dondeti wrote:
> Hi Bernard,
> 
> Thank you for clearly explaining the problem.  I appreciate it.  I have 
> even read Acct-Multi-Session-Id thing now and I wonder perhaps it makes 
> sense to tie the "domain" definition to that attribute.

I am not sure how this can solve the problem.  How this provides an
evidence that the peer has requested DSRK? 

Yoshihiro Ohba

> 
> Let me try to respond to your notes below:
> 
> On 3/12/2008 2:43 PM, [email-masked] wrote:
> > During the HOKEY WG meeting today we got into a discussion of
> > fraud protection and potential issues relating to that within ERX.
> >  
> > Since I mentioned the fraud issue in my O&M review, and
> > since this issue has been brought up by other reviewers
> > as well as in Sam's DISCUSS, I thought I'd send a more
> > detailed description of my perception of the problem to the list,
> > in order to fully describe what I think the issue is, and how
> > it has been introduced.
> >  
> > At its core, I believe that the problem has been created
> > by the introduction of a short cut that in practice will
> > provide little in the way of handoff latency reduction,
> > namely the piggybacking of DSRK provisioning on the initial
> > EAP authentication (e.g. EAP boostrapping).
> 
> Again, thanks for pointing out the specific issue here.  It is very helpful.
> 
> >  
> > The shortcut is immaterial to performance because the additional
> > latency involved in providing proper peer authorization
> > for DSRK provisioning would be amortized across the
> > user's connection time within the new domain and thus
> > would not constitute a burden.
> 
> The shortcut helps.  After full EAP authentication, the next AP the peer 
> attaches to (we don't know how fast the handover happens) would have to 
> run ERP bootstrapping exchange instead of ERP with the local ER server. 
>   We should avoid that when possible.  Implicit bootstrapping is a 
> SHOULD.  Implicit bootstrapping is also possible only if the peer can 
> learn the domain name from the authenticator.  Thus, there is a way for 
> the peer and the server to establish that they are communicating with 
> entities that advertise the same domain name.  Now as long as we require 
> all acct records from the same domain to use the Acct-Multi-Session-Id, 
> we would have mitigated the fraud.
> 
> thanks,
> Lakshminath
> 
> >  
> > This optimization is problematic from
> > a security perspective because it not only enables new
> > avenues for fraud when ERX is used, but it also negatively
> > affects the security of EAP as it is currently deployed, by
> > providing keying material to an entity that the EAP peer
> > has not authorized, and may not even be familiar with,
> > even when the peer does not support ERX.
> >  
> > How has the use of EAP boostrapping within the ERX design
> > introduced new avenues for fraud?
> >  
> > There are several properties of AAA protocols that are very
> > useful for automated anti-fraud protection:
> >  
> > 1. Correlation of Accounting Records to a corresponding
> > authentication record;
> >  
> > 2. Linkage of authentication records to a user whose
> > authentication can be verified (and is immune to replay).
> >  
> > Property 1 is provided by the Class Attribute, which can
> > be provided within an Access-Accept and subsequently echoed
> > to an Accounting-Start, as well as via the Acct-Multi-Session
> > Attribute, which can be used to correlate Accounting-Start
> > packets issued within a single session of a user handing
> > off between access points.
> >  
> > Property 2 is provided by the requirement that a RADIUS
> > Access-Request provide either a State Attribute, 
> > user authentication attributes or other evidence
> > that demonstrates that the Access-Request
> > represents an interaction with a user that at one
> > point was demonstrated to be live (e.g. not a replay).
> >  
> > Properties 1 and 2 together limit the opportunities
> > for fraud.  While it is possible for an operator to
> > "imbelish" accounting records for valid sessions,
> > potentially expanding the charges, it is typically not
> > possible to invent sessions to which fictious
> > charges can then be attached.
> >  
> > The difference may seem subtle, but in practice, it
> > is important.  As an analogy, it is the
> > difference between being overcharged for a purchase
> > that you did make, and having an unknown item show up on
> > your credit card that was purchased at an unfamiliar
> > location.
> >  
> > To date, fast handoff proposals (such as 11r) have
> > stretched, but not broken the anti-fraud protections
> > provided by AAA protocols:
> >  
> > 1. While the user may move between authenticators,
> > migration of the authorization parameters between
> > authenticators has enabled correlation of accounting
> > records both with each other (e.g. same
> > Multi-Session-Id) and with the corresponding
> > authentication record (via the Class Attribute).
> >  
> > 2. While the fast handoffs do not generate
> > authentication attempts for each new authenticator,
> > accounting records can only originate from the
> > administrative domain within which the original
> > authentication attempt occurred. 
> >  
> > For example, within IEEE 802.11r, the user may
> > only successfully complete a fast BSS transition
> > within the Mobility Domain.  As a result, if
> > the home accounting server were to receive an
> > Accounting-Start from a different Mobility Domain
> > that did not correspond to an authentication attempt
> > originating from within that Mobility Domain, then the
> > Accounting-Start can be flagged as fraudulent.
> >  
> > What has ERX done with EAP boostrapping that is so
> > different from existing schemes?
> >  
> > As I see it, the fundamental problem is that EAP
> > boostrapping changes the AAA protocol model in a
> > fundamental way by allowing an ERX server on the
> > path to request a key, without providing proof
> > that the user authorized that key request, thereby
> > bypassing AAA protocol anti-fraud protections.
> >  
> > As it stands, the ERX-13 document does not specify
> > checks that the AAA server should perform before
> > issuing the requested DSRK.  For example, the
> > ERX server need not necessarily be only a single
> > hop from the AAA server, and thus may not be
> > authenticated to the AAA server, violating
> > the requirements of RFC 4962.  If the ERX
> > server is allowed to exist multiple hops from
> > the AAA server, this also implies that the ERX
> > server need not necessarily exist within
> > the local domain which the user has connected
> > to.
> >  
> > The result of this is that a home AAA server
> > providing a DSRK to an ERX server via EAP
> > boostrapping will not necessarily be able
> > to link accounting records received from
> > that server to the original EAP authentication,
> > or to a subsequent ERX authentication
> > terminating at the home server.
> >  
> > What can be done to address the problems?
> > The most satisfying solution from a security
> > perspective would be to eliminate the piggybacking
> > of DSRK provisioning on top of legacy EAP
> > exchanges.  Providing an explicit request
> > from the peer to the server for provisioning
> > of the DSRK would provide the server with
> > proof of client liveness within the domain
> > which subsequently will issue accounting
> > records, closing the fraud loophole, as well as
> > removing the RFC 4962 "authenicate all
> > parties" problem, and any security impact
> > on legacy EAP deployments.
> >  
> > Another potential approach would be to
> > introduce authorization checks on the
> > AAA server.  For example, the AAA server
> > could require that the ERX server be
> > only one hop away, thereby addressing
> > the "authenticate the parties" issue.
> > Also, the ERX server could now be
> > guaranteed to be in the same domain
> > as the user, limiting the potential
> > for fraud to roughly the same magnitude
> > as existing fast handoff proposals
> > such as 11r.
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > HOKEY mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/hokey
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 

Delivery-date: Fri, 14 Mar 2008 15:10:07 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Fri, 14 Mar 2008 08:09:31 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0118_01C885AA.BB6852D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This is a consensus call for acceptance of RADSEC (and the Status Update =
draft) as a RADEXT WG work item.   The
consensus call will last until March 28, 2008.  Please send email to the =
list stating whether you are in favor or opposed
to accepting RADSEC as a RADEXT WG work item. 
------=_NextPart_000_0118_01C885AA.BB6852D0
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=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6001.18000" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true"=20
name=3D"Compose message area">
<DIV><FONT face=3DArial size=3D2>This is a consensus call for acceptance =
of RADSEC=20
(and the Status Update draft) as a RADEXT WG work item.&nbsp;&nbsp;=20
The</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>consensus call will last until March =
28,=20
2008.&nbsp; Please send email to the list stating whether you are in =
favor or=20
opposed</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to accepting RADSEC as a RADEXT WG work =
item.=20
</FONT></DIV></BODY></HTML>

------=_NextPart_000_0118_01C885AA.BB6852D0--

Delivery-date: Fri, 14 Mar 2008 12:32:33 +0000
Date: Fri, 14 Mar 2008 13:28:43 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: 'eap-WG' <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [HOKEY] ERX fraud issue

Bernard Aboba wrote:
> [BA] By a "stream" you mean Accounting-Requests from a single NAS, right?

  Yes and no.  From the point of view of the home server, there is *one*
user login.  This *should* translate into one accounting stream.  Which
NAS(es) generate that stream is a separate issue.

> As the user moves between NASes, Accounting-Requests will be generated,
> with Start/Stop to mark the beginning and end of a session on a particular
> NAS.

  Yes.  These packets go through the visited AAA server, which talks to
the visited ERX server.  That visited AAA server SHOULD be made
responsible for reconciling accounting streams from disparate NASes in
it's local network.

> [BA]  So with ERX it is necessary to do a full EAP authentication every time
> a peer enters a new domain? I guess that this is a consequence of not
> being able to assume EMSK caching within the AAA server.

  That's my interpretation of what was said in Hokey.

>> The accounting stream is tied to the original EAP authentication,
>> which must carry information about the visited domain.
> 
> [BA] How is information about the visited domain encoded by the NAS? 

  It doesn't need to be.  The proxy knows about the visited domain, and
can add that information to the AAA packet stream.  This may require
policy changes on those proxies, and maybe a new AAA attribute.  But it
won't require code changes.

> Looking at the document, it appears that the DSRK can be requested
> by any ERX proxy along the path.

  Yes.  I'm not sure I understand that part.  If the visited domain
implements ERX, it can terminate the ERX requests.  If it doesn't
implement ERX, then it can't proxy those requests.

  i.e. the only thing that makes sense to me is that the ERX proxies (if
any) are all within the visited domain.

>  Does the AAA server assume that
> whatever ERX proxy has submitted the request is valid before delivering
> the key? Or is there information provided by the NAS that it is supposed
> to check against?  For example, does it do a reverse PTR RR query
> on the NAS-IP-Address Attribute and check that the proxy submitting
> the DSRK request is within the same domain?

  Not really sure...

  Alan DeKok.

Delivery-date: Fri, 14 Mar 2008 11:58:18 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: 'eap-WG' <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [HOKEY] ERX fraud issue
Date: Fri, 14 Mar 2008 04:57:33 -0700

--_87a1e66f-8fdd-4385-a35c-fcdc94aa87da_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   Since we assume only one accounting stream from visited AAA to home
> AAA, the fraud issue is limited.  Most networks bill on the basis of
> time, and one stream can't have multiple start/stop times.  Other
> networks bill on the basis of data usage, and visited networks can
> already claim inflated numbers.  (i.e. it isn't a problem.)

[BA] By a "stream" you mean Accounting-Requests from a single NAS, right?
As the user moves between NASes, Accounting-Requests will be generated,
with Start/Stop to mark the beginning and end of a session on a particular
NAS.=20

>   Since ERX is not for intra-domain handovers, I think it's best to
> leave this as a requirement on the visited AAA server, as below:

[BA]  So with ERX it is necessary to do a full EAP authentication every tim=
e
a peer enters a new domain? I guess that this is a consequence of not
being able to assume EMSK caching within the AAA server.=20
=20
>   The accounting stream is tied to the original EAP authentication,
> which must carry information about the visited domain. =20

[BA] How is information about the visited domain encoded by the NAS? =20
Looking at the document, it appears that the DSRK can be requested
by any ERX proxy along the path.  Does the AAA server assume that
whatever ERX proxy has submitted the request is valid before delivering
the key? Or is there information provided by the NAS that it is supposed
to check against?  For example, does it do a reverse PTR RR query
on the NAS-IP-Address Attribute and check that the proxy submitting
the DSRK request is within the same domain?=20

--_87a1e66f-8fdd-4385-a35c-fcdc94aa87da_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
&gt;   Since we assume only one accounting stream from visited AAA to home<=
br>&gt; AAA, the fraud issue is limited.  Most networks bill on the basis o=
f<br>&gt; time, and one stream can't have multiple start/stop times.  Other=
<br>&gt; networks bill on the basis of data usage, and visited networks can=
<br>&gt; already claim inflated numbers.  (i.e. it isn't a problem.)<br><br=
>[BA] By a "stream" you mean Accounting-Requests from a single NAS, right?<=
br>As the user moves between NASes, Accounting-Requests will be generated,<=
br>with Start/Stop to mark the beginning and end of a session on a particul=
ar<br>NAS. <br><br>&gt;   Since ERX is not for intra-domain handovers, I th=
ink it's best to<br>&gt; leave this as a requirement on the visited AAA ser=
ver, as below:<br><br>[BA]&nbsp; So with ERX it is necessary to do a full E=
AP authentication every time<br>a peer enters a new domain? I guess that th=
is is a consequence of not<br>being able to assume EMSK caching within the =
AAA server. <br>&nbsp;<br>&gt;   The accounting stream is tied to the origi=
nal EAP authentication,<br>&gt; which must carry information about the visi=
ted domain.  <br><br>[BA] How is information about the visited domain encod=
ed by the NAS?&nbsp; <br>Looking at the document, it appears that the DSRK =
can be requested<br>by any ERX proxy along the path.&nbsp; Does the AAA ser=
ver assume that<br>whatever ERX proxy has submitted the request is valid be=
fore delivering<br>the key? Or is there information provided by the NAS tha=
t it is supposed<br>to check against?&nbsp; For example, does it do a rever=
se PTR RR query<br>on the NAS-IP-Address Attribute and check that the proxy=
 submitting<br>the DSRK request is within the same domain? <br></body>
</html>=

--_87a1e66f-8fdd-4385-a35c-fcdc94aa87da_--

Delivery-date: Fri, 14 Mar 2008 09:57:12 +0000
Date: Fri, 14 Mar 2008 10:52:37 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
CC: 'eap-WG' <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [HOKEY] ERX fraud issue

[email-masked] wrote:
> [BA] Ah... so you are saying that the forgery can be detected by looking
> for overlap in the time sequence of user activity?  This seems like a
> fairly intensive check, though.

  I'm saying that the home AAA server can detect multiple accounting
streams for one user, and conclude that fraud is involved.  The visited
network is therefore required (somewhat logically) to generate only one
accounting stream for a user, independent of how many times ERX is used.

  i.e. if the visited network permits the user to move between AP's, it
should be required to bear the burden of ensuring that the accounting
stream it generates is sane.

  Since we assume only one accounting stream from visited AAA to home
AAA, the fraud issue is limited.  Most networks bill on the basis of
time, and one stream can't have multiple start/stop times.  Other
networks bill on the basis of data usage, and visited networks can
already claim inflated numbers.  (i.e. it isn't a problem.)

> [BA] I was looking for something simpler, such as a mechanism that
> would enable checking of a ERX auth exchange with the home server
> against subsequent accounting records sent by the local ERX server.
> For example, if the peer were to use ERX to tell the home server what
> local domain it is in, then the home server could ensure that it only
> accepts accounting records from that domain, and no other ones.

  Since ERX is not for intra-domain handovers, I think it's best to
leave this as a requirement on the visited AAA server, as below:

> [BA] That would be fine too, as long as the home server knows what
> visited network the accounting data is supposed to come from.

  The accounting stream is tied to the original EAP authentication,
which must carry information about the visited domain.  This information
doesn't have to be generated by the NAS.  It can be generated by the
visited domain, or by server (proxy/home) that accepts AAA traffic from
the visited domain.

  Alan DeKok.

Delivery-date: Thu, 13 Mar 2008 23:35:27 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>, "'Lakshminath Dondeti'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Charles Clancy'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 13 Mar 2008 19:33:48 -0400
Organization: Elbrys Networks, Inc.

> > There is a desire to use NIST-approved key-wrap
> > algorithms for wrapping keys, and those algorithms are inappropriate for
> > general-purpose data encryption.
> 
> I'm not sure why this is a problem.   The encrypted attribute
> container can include an algorithm field, so that it would be possible to
> encrypt one bag of attributes (not keys) with one algorithm, while using
> a keywrap algorithm for another bag (which represent keys).

In our hallway discussion of this afternoon, Joe Salowey indicated that his
preference is to make it harder for an implementer to make the mistake of
using the incorrect class of cipher-suite, e.g. to protect general data with
a key-wrap (too weak) or protect a key with a non-NIST-approved algorithm.
Otherwise, we could do as you suggest.  I had made the same point during our
discussion.
 
> * Are general encryption algorithms suitable for use in encrypting keys?

There are really two questions -- (a) "is the algorithm and mode suitably
strong?" and (b) "is it NIST-approved?"  The former is easier to satisfy.

Delivery-date: Thu, 13 Mar 2008 23:20:39 +0000
From: <[email-masked]>
To: "David B. Nelson" <[email-masked]>, "'Lakshminath Dondeti'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, "'Charles Clancy'" <[email-masked]>, <[email-masked]>
Subject: Re: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 13 Mar 2008 16:20:27 -0700

> There is a desire to use NIST-approved key-wrap
> algorithms for wrapping keys, and those algorithms are inappropriate for
> general-purpose data encryption.

I'm not sure why this is a problem.   The encrypted attribute
container can include an algorithm field, so that it would be possible to 
encrypt one bag of attributes (not keys) with one algorithm, while using
a keywrap algorithm for another bag (which represent keys).

A (perhaps silly) question:

* Are general encryption algorithms suitable for use in encrypting keys? 
The Diameter EAP application has always assumed that they were. 

* Is there a pointer to a the limitations of keywrap algorithms? 

Delivery-date: Thu, 13 Mar 2008 23:03:48 +0000
From: <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "'eap-WG'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [HOKEY] ERX fraud issue
Date: Thu, 13 Mar 2008 16:03:28 -0700

>  A proxy inserting a DSRK for the purposes of faking authentication
> would presumably do so without the cooperation of the visited network.
> The proxy would then have to filter the accounting traffic from the
> visited network.

[BA] Ah... so you are saying that the forgery can be detected by looking
for overlap in the time sequence of user activity?  This seems like a
fairly intensive check, though.

>  This is where a 3 party *reconciliation* protocol would be beneficial.
> If the visited network, proxies, and home network all share their
> accounting data, fraud is easier to detect.

[BA] I was looking for something simpler, such as a mechanism that
would enable checking of a ERX auth exchange with the home server
against subsequent accounting records sent by the local ERX server.
For example, if the peer were to use ERX to tell the home server what
local domain it is in, then the home server could ensure that it only
accepts accounting records from that domain, and no other ones.

>> [BA] It would certainly help for the subsequent ERX accounting records to
>> be tied to the original EAP session (e.g. via use of the same
>> Multi-Session-Id).
>
>  Not many systems implement Multi-Session-Id.  It may be simpler just
> to require the accounting records for the visited network to be
> consistent.  i.e. when a user moves to a new NAS, the records could be
> sent through the visited network AAA server, which could do the
> necessary data massaging to create a canonical accounting stream.

[BA] That would be fine too, as long as the home server knows what
visited network the accounting data is supposed to come from. 

Delivery-date: Thu, 13 Mar 2008 19:11:14 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RADEXT session materials
Date: Thu, 13 Mar 2008 15:09:33 -0400
Organization: Elbrys Networks, Inc.

Slides for the RADEXT WG session tomorrow at 9 AM EDT may be found at:

https://datatracker.ietf.org/meeting/71/materials.html

Check back just prior to the meeting for last-minute up-loads.

Streaming audio will be available at: 

http://videolab.uoregon.edu/events/ietf/ietf713.m3u

The jabber room is at:

[email-masked]

Delivery-date: Thu, 13 Mar 2008 18:54:50 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RADEXT WG session agenda for IETF-71 (final)
Date: Thu, 13 Mar 2008 14:52:31 -0400
Organization: Elbrys Networks, Inc.

This RADEXT WG session agenda is final (subject to agenda bashing at the
outset of the meeting).

IETF 71 RADEXT WG Agenda
Friday March 14, 2008
9:00 AM - 11:30 AM, Franklin 5
 
9:00 AM - 9:10 AM Preliminaries
   Blue Sheets
   Note Takers
   Jabber Scribe
   Agenda bashing
   Document status
 
Documents having completed RADEXT WG last call (20 minutes)
 
9:10 - 9:20 AM  RADIUS Design Guidelines (Alan DeKok -- remotely)
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

9:20 - 9:30 Extended RADIUS Attributes (Glen Zorn)
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-01
.txt
 
Documents in RADEXT WG last call (10 minutes)

9:30 - 9:40 AM  RADIUS Authorization for NAS Management (David Nelson)
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati
on-02.txt

WG Work items

(none)
 
Pre-WG Work Item Review (20 Minutes) 
 
9:40- 9:50 AM  IEEE 802 Attributes (Bernard Aboba)
http://www.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt
 
9:50 - 10:00 AM  RADIUS support for EAP Re-authentication (Lakshminath
Dondeti)
http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-03.txt

RADIUS Crypto-Agility (40 minutes)
 
10:00 - 10:15 AM  RADEXT Crypto-agility Requirements (David Nelson)

-- Should the WG publish the RADEXT Crypto Agility Requirements document as
an Informational RFC?
 
10:15 - 10:40 AM  Discussion

-- What progress is being made on the candidate submissions?

-- Recommended next steps.

RADSEC and Re-Chartering Discussion (30 Minutes)

10:40 - 11:10 AM  RADSEC (Stefan Winter)
http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt

-- Should RADSEC become a RADEXT WG work item, with an accompanying charter
revision?

Miscellaneous (20 minutes)

11:10 - 11:20  AM RADIUS Message Fragmentation when using EAP methods
(Stefan Winter)
                  RADIUS Proxy Failures when using EAP methods (Stefan
Winter)

11:20 - 11:30 AM  Roaming Extensions for Radius Server (Vamsi Krishna GONDI)
http://www.ietf.org/internet-drafts/draft-gondi-radext-radius-roaming-01.txt

                  Radius Mobility Extensions (Vamsi Krishna GONDI)
http://www.ietf.org/internet-drafts/draft-gondi-radext-radius-mobility-00.tx
t

Delivery-date: Thu, 13 Mar 2008 15:04:15 +0000
Date: Thu, 13 Mar 2008 15:59:54 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: 'eap-WG' <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [HOKEY] ERX fraud issue

Bernard Aboba wrote:
> [BA] This is where I get confused.  As far as I can tell, the DSRK request
> can be inserted by *any* proxy on the path.  So I'm not sure how the
> restrictions is implemented in practice.

  A proxy inserting a DSRK for the purposes of faking authentication
would presumably do so without the cooperation of the visited network.
The proxy would then have to filter the accounting traffic from the
visited network.

  This is where a 3 party *reconciliation* protocol would be beneficial.
 If the visitied network, proxies, and home network all share their
accounting data, fraud is easier to detect.

> [BA] It would certainly help for the subsequent ERX accounting records to
> be tied to the original EAP session (e.g. via use of the same
> Multi-Session-Id).

  Not many systems implement Multi-Session-Id.  It may be simpler just
to require the accounting records for the visited network to be
consistent.  i.e. when a user moves to a new NAS, the records could be
sent through the visited network AAA server, which could do the
necessary data massaging to create a canonical accounting stream.

> [BA] If the ERX server and AAA server are both in the visited domain,
> why refer
> to a "local" ERX server and a "home" ERX server?  I thought that the
> applicability statement proposed refers to inter-domain use.

  I think the "home" ERX server just complicates the issue.

> [BA] I agree that the restrictions you describe would address the issue,
> but I'm still confused as to whether the solution scope includes those
> restrictions or not.

  Reviews && feedback are being solicited...

  Alan DeKok.

Delivery-date: Thu, 13 Mar 2008 14:21:54 +0000
From: Bernard Aboba <[email-masked]>
To: Alan DeKok <[email-masked]>
CC: 'eap-WG' <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [HOKEY] ERX fraud issue
Date: Thu, 13 Mar 2008 07:20:25 -0700

--_c8d6ec3d-b615-4b60-b3f3-7eafd34ca75b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>   For hotspot or dial-up, the passwords are sent in clear-text.  This
> gives the visited operators the ability to invent sessions.

[BA] Fair enough.=20
=20
>   Hokey restricts ERX to within one domain (I think Glen said that in
> the meeting), so the above restriction will apply to Hokey, too.  This
> means that the only vulnerability Hokey has to fraudulent operators is
> their ability to use ERX to generate *multiple* authentications for the
> same user.

[BA] This is where I get confused.  As far as I can tell, the DSRK request
can be inserted by *any* proxy on the path.  So I'm not sure how the
restrictions is implemented in practice.=20

>   This fraud can be detected and prevented if Hokey ties each ERX
> session to the original EAP session.  (It's not immediately obvious from
> a scan of ERX-13 how this happens).  i.e. Any accounting stream from an
> ERX authentication should be tied to the original EAP authentication.
> The home server can then validate that it is receiving one, and only
> one, accounting stream that results from an EAP authentication.

[BA] It would certainly help for the subsequent ERX accounting records to
be tied to the original EAP session (e.g. via use of the same Multi-Session=
-Id).=20
But it would still be necessary to tie the ERX accounting records to
an authentication that terminates at the home ERX server, not just
the local ERX server.=20

>   I think that the ERX server MUST be within the same domain as the AAA
> server: the visited domain.

[BA] If the ERX server and AAA server are both in the visited domain, why r=
efer
to a "local" ERX server and a "home" ERX server?  I thought that the=20
applicability statement proposed refers to inter-domain use.=20

>   That would be best, I think.

[BA] I agree that the restrictions you describe would address the issue,
but I'm still confused as to whether the solution scope includes those
restrictions or not.=20

--_c8d6ec3d-b615-4b60-b3f3-7eafd34ca75b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
&gt;   For hotspot or dial-up, the passwords are sent in clear-text.  This<=
br>&gt; gives the visited operators the ability to invent sessions.<br><br>=
[BA] Fair enough. <br>&nbsp;<br>&gt;   Hokey restricts ERX to within one do=
main (I think Glen said that in<br>&gt; the meeting), so the above restrict=
ion will apply to Hokey, too.  This<br>&gt; means that the only vulnerabili=
ty Hokey has to fraudulent operators is<br>&gt; their ability to use ERX to=
 generate *multiple* authentications for the<br>&gt; same user.<br><br>[BA]=
 This is where I get confused.&nbsp; As far as I can tell, the DSRK request=
<br>can be inserted by *any* proxy on the path.&nbsp; So I'm not sure how t=
he<br>restrictions is implemented in practice. <br><br>&gt;   This fraud ca=
n be detected and prevented if Hokey ties each ERX<br>&gt; session to the o=
riginal EAP session.  (It's not immediately obvious from<br>&gt; a scan of =
ERX-13 how this happens).  i.e. Any accounting stream from an<br>&gt; ERX a=
uthentication should be tied to the original EAP authentication.<br>&gt; Th=
e home server can then validate that it is receiving one, and only<br>&gt; =
one, accounting stream that results from an EAP authentication.<br><br>[BA]=
 It would certainly help for the subsequent ERX accounting records to<br>be=
 tied to the original EAP session (e.g. via use of the same Multi-Session-I=
d). <br>But it would still be necessary to tie the ERX accounting records t=
o<br>an authentication that terminates at the home ERX server, not just<br>=
the local ERX server. <br><br>&gt;   I think that the ERX server MUST be wi=
thin the same domain as the AAA<br>&gt; server: the visited domain.<br><br>=
[BA] If the ERX server and AAA server are both in the visited domain, why r=
efer<br>to a "local" ERX server and a "home" ERX server?&nbsp; I thought th=
at the <br>applicability statement proposed refers to inter-domain use. <br=
><br>&gt;   That would be best, I think.<br><br>[BA] I agree that the restr=
ictions you describe would address the issue,<br>but I'm still confused as =
to whether the solution scope includes those<br>restrictions or not. <br></=
body>
</html>=

--_c8d6ec3d-b615-4b60-b3f3-7eafd34ca75b_--

Delivery-date: Thu, 13 Mar 2008 09:06:34 +0000
Date: Thu, 13 Mar 2008 10:02:02 +0100
From: Alan DeKok <[email-masked]>
To: [email-masked]
CC: 'eap-WG' <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [HOKEY] ERX fraud issue

[email-masked] wrote:
> Properties 1 and 2 together limit the opportunities
> for fraud.  While it is possible for an operator to
> "imbelish" accounting records for valid sessions,
> potentially expanding the charges, it is typically not
> possible to invent sessions to which fictious
> charges can then be attached.

  One caveat: Yes, for EAP sessions.

  For hotspot or dial-up, the passwords are sent in clear-text.  This
gives the visited operators the ability to invent sessions.

> 2. While the fast handoffs do not generate
> authentication attempts for each new authenticator,
> accounting records can only originate from the
> administrative domain within which the original
> authentication attempt occurred. 

  Hokey restricts ERX to within one domain (I think Glen said that in
the meeting), so the above restriction will apply to Hokey, too.  This
means that the only vulnerability Hokey has to fraudulent operators is
their ability to use ERX to generate *multiple* authentications for the
same user.

  This fraud can be detected and prevented if Hokey ties each ERX
session to the original EAP session.  (It's not immediately obvious from
a scan of ERX-13 how this happens).  i.e. Any accounting stream from an
ERX authentication should be tied to the original EAP authentication.
The home server can then validate that it is receiving one, and only
one, accounting stream that results from an EAP authentication.

> As I see it, the fundamental problem is that EAP
> boostrapping changes the AAA protocol model in a
> fundamental way by allowing an ERX server on the
> path to request a key, without providing proof
> that the user authorized that key request, thereby
> bypassing AAA protocol anti-fraud protections.

  Largely, yes.  The above analysis does some risk mitigation on
subsequent activity.

> As it stands, the ERX-13 document does not specify
> checks that the AAA server should perform before
> issuing the requested DSRK. ...  If the ERX
> server is allowed to exist multiple hops from
> the AAA server, this also implies that the ERX
> server need not necessarily exist within
> the local domain which the user has connected
> to.

  I think that the ERX server MUST be within the same domain as the AAA
server: the visited domain.

> Also, the ERX server could now be
> guaranteed to be in the same domain
> as the user, limiting the potential
> for fraud to roughly the same magnitude
> as existing fast handoff proposals
> such as 11r.

  That would be best, I think.

  Alan DeKok.

Delivery-date: Thu, 13 Mar 2008 03:34:15 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: New ID on Crypto-Agility Requirements
Date: Wed, 12 Mar 2008 23:31:56 -0400
Organization: Elbrys Networks, Inc.

At the suggestion of my co-chair, Bernard, I've written an ID that presents
in a formal fashion the RADEXT requirements for RADIUS Crypto-Agility. In
the past we have captured these requirements in a series of e-mails on the
RADEXT WG mailing list and in the proceedings of our sessions at various
IETF meetings.  It was suggested that we might want to formalize this
documentation, in an effort to smooth the path for acceptance for our work
items in the IESG.  There has been some degree of "flux" in the requirements
and expectations, especially from the Security Area Directorate.  This
draft, intended as an Informational RFC, is intended to "drive a stake in
the ground".

It would be helpful of folks had some time to read this draft prior to the
RADEXT session on Friday morning.

http://www.ietf.org/internet-drafts/draft-nelson-radext-crypto-agility-requi
rements-00.txt

Delivery-date: Wed, 12 Mar 2008 21:43:05 +0000
From: <[email-masked]>
To: "'eap-WG'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: ERX fraud issue
Date: Wed, 12 Mar 2008 14:43:03 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0142_01C8844F.60346B30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

During the HOKEY WG meeting today we got into a discussion of
fraud protection and potential issues relating to that within ERX.=20

Since I mentioned the fraud issue in my O&M review, and
since this issue has been brought up by other reviewers
as well as in Sam's DISCUSS, I thought I'd send a more=20
detailed description of my perception of the problem to the list,
in order to fully describe what I think the issue is, and how
it has been introduced.=20

At its core, I believe that the problem has been created
by the introduction of a short cut that in practice will
provide little in the way of handoff latency reduction,=20
namely the piggybacking of DSRK provisioning on the initial
EAP authentication (e.g. EAP boostrapping).=20

The shortcut is immaterial to performance because the additional=20
latency involved in providing proper peer authorization
for DSRK provisioning would be amortized across the=20
user's connection time within the new domain and thus
would not constitute a burden.

This optimization is problematic from
a security perspective because it not only enables new
avenues for fraud when ERX is used, but it also negatively
affects the security of EAP as it is currently deployed, by
providing keying material to an entity that the EAP peer=20
has not authorized, and may not even be familiar with,=20
even when the peer does not support ERX.=20

How has the use of EAP boostrapping within the ERX design=20
introduced new avenues for fraud?=20

There are several properties of AAA protocols that are very
useful for automated anti-fraud protection:=20

1. Correlation of Accounting Records to a corresponding
authentication record;=20

2. Linkage of authentication records to a user whose
authentication can be verified (and is immune to replay).=20

Property 1 is provided by the Class Attribute, which can
be provided within an Access-Accept and subsequently echoed
to an Accounting-Start, as well as via the Acct-Multi-Session
Attribute, which can be used to correlate Accounting-Start
packets issued within a single session of a user handing
off between access points.=20

Property 2 is provided by the requirement that a RADIUS
Access-Request provide either a State Attribute, =20
user authentication attributes or other evidence
that demonstrates that the Access-Request
represents an interaction with a user that at one
point was demonstrated to be live (e.g. not a replay).=20

Properties 1 and 2 together limit the opportunities
for fraud.  While it is possible for an operator to
"imbelish" accounting records for valid sessions,=20
potentially expanding the charges, it is typically not
possible to invent sessions to which fictious
charges can then be attached.=20

The difference may seem subtle, but in practice, it
is important.  As an analogy, it is the
difference between being overcharged for a purchase
that you did make, and having an unknown item show up on
your credit card that was purchased at an unfamiliar
location.=20

To date, fast handoff proposals (such as 11r) have
stretched, but not broken the anti-fraud protections
provided by AAA protocols:

1. While the user may move between authenticators,
migration of the authorization parameters between
authenticators has enabled correlation of accounting
records both with each other (e.g. same
Multi-Session-Id) and with the corresponding
authentication record (via the Class Attribute).=20

2. While the fast handoffs do not generate=20
authentication attempts for each new authenticator,
accounting records can only originate from the
administrative domain within which the original
authentication attempt occurred. =20

For example, within IEEE 802.11r, the user may
only successfully complete a fast BSS transition
within the Mobility Domain.  As a result, if
the home accounting server were to receive an
Accounting-Start from a different Mobility Domain
that did not correspond to an authentication attempt
originating from within that Mobility Domain, then the
Accounting-Start can be flagged as fraudulent.

What has ERX done with EAP boostrapping that is so=20
different from existing schemes?=20

As I see it, the fundamental problem is that EAP
boostrapping changes the AAA protocol model in a=20
fundamental way by allowing an ERX server on the=20
path to request a key, without providing proof=20
that the user authorized that key request, thereby=20
bypassing AAA protocol anti-fraud protections.=20

As it stands, the ERX-13 document does not specify
checks that the AAA server should perform before
issuing the requested DSRK.  For example, the
ERX server need not necessarily be only a single
hop from the AAA server, and thus may not be
authenticated to the AAA server, violating
the requirements of RFC 4962.  If the ERX
server is allowed to exist multiple hops from
the AAA server, this also implies that the ERX
server need not necessarily exist within
the local domain which the user has connected
to.=20

The result of this is that a home AAA server=20
providing a DSRK to an ERX server via EAP
boostrapping will not necessarily be able=20
to link accounting records received from=20
that server to the original EAP authentication,=20
or to a subsequent ERX authentication=20
terminating at the home server.=20
=20
What can be done to address the problems?
The most satisfying solution from a security
perspective would be to eliminate the piggybacking
of DSRK provisioning on top of legacy EAP
exchanges.  Providing an explicit request
from the peer to the server for provisioning
of the DSRK would provide the server with
proof of client liveness within the domain
which subsequently will issue accounting
records, closing the fraud loophole, as well as
removing the RFC 4962 "authenicate all
parties" problem, and any security impact
on legacy EAP deployments.=20

Another potential approach would be to=20
introduce authorization checks on the
AAA server.  For example, the AAA server
could require that the ERX server be
only one hop away, thereby addressing
the "authenticate the parties" issue.=20
Also, the ERX server could now be=20
guaranteed to be in the same domain
as the user, limiting the potential
for fraud to roughly the same magnitude
as existing fast handoff proposals
such as 11r.
------=_NextPart_000_0142_01C8844F.60346B30
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=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6001.18000" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true"=20
name=3D"Compose message area">
<DIV><FONT face=3DArial size=3D2>During the HOKEY WG meeting today we =
got into a=20
discussion of<BR>fraud protection&nbsp;and potential issues relating to =
that=20
within ERX. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Since I mentioned the fraud issue in my =
O&amp;M=20
review, and<BR>since this issue has been brought up by other =
reviewers<BR>as=20
well as in Sam's DISCUSS, I thought I'd send a more <BR>detailed =
description of=20
my perception of the problem to the list,<BR>in order to fully describe =
what I=20
think the issue is, and how</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>it has been introduced. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>At its core, I believe that the problem =
has been=20
created</FONT><FONT face=3DArial size=3D2><BR>by the introduction of a =
short cut=20
that in practice will<BR>provide little in the way of handoff latency =
reduction,=20
<BR>namely the piggybacking of DSRK provisioning on the initial<BR>EAP=20
authentication (e.g. EAP boostrapping). </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The shortcut is immaterial to =
performance because=20
the additional <BR>latency involved in providing proper peer=20
authorization<BR>for DSRK provisioning would be amortized across the =
<BR>user's=20
connection time within the new domain and thus<BR>would not constitute a =

burden.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This optimization is problematic =
from<BR>a security=20
perspective because it not only enables new<BR>avenues for fraud when =
ERX is=20
used, but it also negatively<BR>affects the security of EAP as it is =
currently=20
deployed, by<BR>providing keying material to an entity that the EAP peer =
<BR>has=20
not authorized, and may not even be familiar with, <BR>even when the =
peer does=20
not support ERX. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>How has the use of EAP boostrapping =
within the ERX=20
design <BR>introduced new avenues for fraud? </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>There are several properties of AAA =
protocols that=20
are very<BR>useful for automated anti-fraud protection: </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. Correlation of Accounting Records to =
a=20
corresponding<BR>authentication record; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2. Linkage of authentication records to =
a user=20
whose<BR>authentication can be verified (and is immune to replay). =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Property 1 is provided by the Class =
Attribute,=20
which can<BR>be provided within an Access-Accept and subsequently =
echoed<BR>to=20
an Accounting-Start, as well as via the Acct-Multi-Session<BR>Attribute, =
which=20
can be used to correlate Accounting-Start<BR>packets issued within a =
single=20
session of a user handing<BR>off between access points. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Property 2 is provided by the =
requirement that a=20
RADIUS<BR>Access-Request provide either a State Attribute,&nbsp; =
<BR>user=20
authentication attributes or other evidence<BR>that demonstrates that =
the=20
Access-Request<BR>represents an interaction with a user that at =
one<BR>point was=20
demonstrated to be live (e.g. not a replay). </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Properties 1 and 2 together limit the=20
opportunities<BR>for fraud.&nbsp; While it is possible for an operator=20
to<BR>"imbelish" accounting records for valid sessions, <BR>potentially=20
expanding the charges, it is typically not<BR>possible to invent =
sessions to=20
which fictious<BR>charges can then be attached. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The difference may seem subtle, but in =
practice,=20
it<BR>is important.&nbsp; As an analogy, it is the<BR>difference between =
being=20
overcharged for a purchase<BR>that you did make, and having an unknown =
item show=20
up on<BR>your credit card that was purchased at an =
unfamiliar<BR>location.=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>To date, fast handoff proposals (such =
as 11r)=20
have<BR>stretched, but not broken the anti-fraud protections<BR>provided =
by AAA=20
protocols:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. While the user may move between=20
authenticators,<BR>migration of the authorization parameters=20
between<BR>authenticators has enabled correlation of =
accounting<BR>records both=20
with each other (e.g. same<BR>Multi-Session-Id) and with the=20
corresponding<BR>authentication record (via the Class Attribute). =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2. While the fast handoffs do not =
generate=20
<BR>authentication attempts for each new authenticator,<BR>accounting =
records=20
can only originate from the<BR>administrative domain within which the=20
original<BR>authentication attempt occurred.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>For example, within IEEE 802.11r, the =
user=20
may<BR>only successfully complete a fast BSS transition<BR>within the =
Mobility=20
Domain.&nbsp; As a result, if<BR>the home accounting server were to =
receive=20
an<BR>Accounting-Start from a different Mobility Domain<BR>that did not=20
correspond to an authentication attempt<BR>originating from within that =
Mobility=20
Domain, then the<BR>Accounting-Start can be flagged as =
fraudulent.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>What has ERX done with EAP boostrapping =
that is so=20
<BR>different from existing schemes? </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>As I see it, the fundamental problem is =
that=20
EAP<BR>boostrapping changes the AAA protocol model in a <BR>fundamental =
way by=20
allowing an ERX server on the <BR>path to request a key, without =
providing proof=20
<BR>that the user authorized that key request, thereby <BR>bypassing AAA =

protocol anti-fraud protections. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>As it stands, the ERX-13 document does =
not=20
specify<BR>checks that the AAA server should perform before<BR>issuing =
the=20
requested DSRK.&nbsp; For example, the<BR>ERX server need not =
necessarily be=20
only a single<BR>hop from the AAA server, and thus may not =
be<BR>authenticated=20
to the AAA server, violating<BR>the requirements of RFC 4962.&nbsp; If =
the=20
ERX<BR>server is allowed to exist multiple hops from<BR>the AAA server, =
this=20
also implies that the ERX<BR>server need not necessarily exist =
within<BR>the=20
local domain which the user has connected<BR>to. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The result of this is that a home AAA =
server=20
<BR>providing a DSRK to an ERX server via EAP<BR>boostrapping will not=20
necessarily be able <BR>to link accounting records received from =
<BR>that server=20
to the original EAP authentication, <BR>or to a subsequent ERX =
authentication=20
<BR>terminating at the home server. <BR>&nbsp;<BR>What can be done to =
address=20
the problems?<BR>The most satisfying solution from a =
security<BR>perspective=20
would be to eliminate the piggybacking<BR>of DSRK provisioning on top of =
legacy=20
EAP<BR>exchanges.&nbsp; Providing an explicit request<BR>from the peer =
to the=20
server for provisioning<BR>of the DSRK would provide the server =
with<BR>proof of=20
client liveness within the domain<BR>which subsequently will issue=20
accounting<BR>records, closing the fraud loophole, as well =
as<BR>removing the=20
RFC 4962 "authenicate all<BR>parties" problem, and any security =
impact<BR>on=20
legacy EAP deployments. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Another potential approach would be to=20
<BR>introduce authorization checks on the<BR>AAA server.&nbsp; For =
example, the=20
AAA server<BR>could require that the ERX server be<BR>only one hop away, =
thereby=20
addressing<BR>the "authenticate the parties" issue. <BR>Also, the ERX =
server=20
could now be <BR>guaranteed to be in the same domain<BR>as the user, =
limiting=20
the potential<BR>for fraud to roughly the same magnitude<BR>as existing =
fast=20
handoff proposals<BR>such as 11r.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0142_01C8844F.60346B30--

Delivery-date: Wed, 12 Mar 2008 21:36:59 +0000
From: <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>, "Jari Arkko" <[email-masked]>, "Dondeti, Lakshminath" <[email-masked]>, <[email-masked]>, "[email-masked]" <[email-masked]>, "Sam Hartman" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, "'eap-WG'" <[email-masked]>, <[email-masked]>
Subject: Re: [eap] Re-review of draft-ietf-hokey-erx-13.txt
Date: Wed, 12 Mar 2008 14:36:32 -0700

> Note that since the DSRK is only handed out as part of an EAP or
> ERP exchange in which the peer is involved, there is no question of a
> random local ER server receiving a DSRK and generating bogus accounting
> records.  

[BA] I'm going to post a message to the HOKEY WG list trying to provide
more detail so that we can discuss this whether there is a problem here,
and if so, why. 

>The domain name is communicated in an authenticated ERP
> bootstrapping exchange to the peer, so that the peer and the home AAA
> server have the same idea about the domain. 

[BA] Would the same security properties be provided in the EAP 
bootstrapping case?  

> This is a reference just saying that in cases like IEEE 802.1x, where
> the peer may send an EAPoL-Start message to start EAP, there is no need
> for the authenticator to wait to receive a response for ERP - when it
> receives the EAPoL-Start, it knows that the peer is interested in
> starting EAP.  

[BA] Sure.  But given the current state of ERP compatibility with IEEE 802,
the reference is confusing. 

> Also, ERP may be network initiated and so, while the
> peer-initiated mode does not work for 802.1x as written, the network
> initiated mode will work fine, as long as codes greater than 4 are
> allowed. 

[BA] The problem is that IEEE 802.1X (2001, at least) doesn't support
that. 

> We seem to have different directions on this - Jari seems to want to
> place MUSTs on lower layers, while you seem to not want that.  

[BA] I'm just asking what "break the connection" means, especially
for a connectionless link layer. 

>> [BA] Do you really mean that the authenticator is using the 
>> realm to determine the IP address of the ER server?  Or is 
>> the keyname-NAI field just copied into the User-Name 
>> attribute so that routing happens normally?  
>>  
> 
> The latter. 

[BA] Can you clarify that in the document?

>> [BA] Since the local ER server does not determine whether it 
>> is on the path how is "path pinning" to be achieved? How does 
>> the AAA server know whether an ER server is on the path or not? 
>> What does it do if it is not on the path?  In other words, 
>> what does the MUST imply?  
>>  
> Deployments that wish to run ERP must place the local ER server in the
> path.  Those that do not cannot run this protocol in the local domain.
> So, there is no behavior to define when the server is not in the path. 

[BA] If the MUST doesn't imply anything in terms of behavior, can we
drop it? 
 
> This is part of the ERP exchange and hence, carried in a AAA attribute.
> The domain name is used to route the message just like any other regular
> AAA routed message.  

[BA] The issue is that AAA routing is typically not implemented on the
authenticator, only in the AAA infrastructure.   Is ERX requiring that the
authenticator implement a realm routing table?
  
>> [BA] Which "original NAI" are we talking about?  The NAI used 
>> in the EAP-Response/Identity in the original EAP 
>> conversation?  The NAI in the Peer-Id?  The NAI in the ERX 
>> conversation?
>>   
> The first one. 

[BA] Can you state that in the draft? 
 
>> [BA] Transport of the MSK is already specified in existing 
>> AAA documents, such as RFC 4072 (Diameter EAP).  Why is 
>> reference 12 being given here rather than those existing 
>> documents?  This document does not update those specifications. 
>>  
> Reference [12] is an example from the RADIUS side.  For Diameter, we do
> reuse RFC4072.  There still needs to be a document that describes
> encapsulation of ERP messages - that is what reference 15 does, for
> instance.

[BA] The problem is that reference [12] is not used by existing RADIUS/
EAP implementations, and the ERP document should not be updating
or obsoleting legacy EAP or RADIUS/EAP behavior. 

>> [BA] I think you mean "ERX" not "EAP re-authentication" or 
>> ERP, right? 
>> One thing that is left out here is authentication between the 
>> ERX local server and the ERX home server.  This exists if 
>> they are one hop apart, but otherwise not.  So I think there 
>> is an assumption that the ERX server is only willing to 
>> provide keys to domains that it is explicitly authorized to 
>> deal with. 
> 
> The authorization text that I pointed out earlier covers this. 

[BA] OK.  I'll take a look at this. 

> I thought that the intent was clear, but, if you prefer this wording, we
> can change it as you suggest. 

[BA] I prefer the suggested text since RADIUS application layer security is
also being considered. 
 
>> [BA] The rest of the spec does not talk about use of the 
>> Peer-Id.  Since not all EAP method deriving keys have a 
>> Peer-Id, do you really want this mentioned here? 
>>  
> The peer-id is a remnant that should be deleted.  We will delete that in
> the next revision. 

[BA] Great. 
   
> This is a note to lower layers and is obviously not binding.  It is
> ultimately the lower layer that will define the authorization state. 

[BA] You might say that in the document.  

Delivery-date: Wed, 12 Mar 2008 18:56:39 +0000
Date: Thu, 13 Mar 2008 03:58:24 +0900
From: Hiroaki Sato <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Request for review of "AAA Framework for Multicasting"

Hi all,

I'm resending the previous response to RADEXT comments for our 
draft,draft-ietf-mboned-multiaaa-framework-xx, because it may be dropped.

Thank you,
Hiroaki

> Mr Dekok,
> 
> Thank you for your detailed feedback on the "AAA Framework for 
> Multicasting" draft.  Last week we submitted a revised version of the 
> draft reflecting many of your suggestions.
> http://www.ietf.org/internet-drafts/draft-ietf-mboned-multiaaa-framework-05.txt 
> 
> 
> A summary of changes:
> * In section 4.1 we broke explanations down into the different use cases 
> of multiple CP - multiple NSPs, single to multiple, etc.   The most 
> general case multiple CPs to mulitple  NSPs was described as a time 
> sequence and the other cases where compared to this most general case.
> 
> * Section 4.2 elaboration of NSP assigned userID vs CP assigned userID 
> was added.
> 
> * In sections 4.3, 4.4 and 4.5 were largely rewritten to clarify AAA 
> characteristics specific to multicasting
> 
> Below we respond to your feedback inline:
> 
>  > (1)  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?
> 
> Indeed, the intent is to give multicast-inferred examples so we have 
> decided to leave these definitions.
> 
>  > (2)  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.
>  >
> Agreed.  We propose to rename the section "AAA Framework in 
> Multicast-Enabled Envrionments" in a future revision.
> 
>  > (3)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.
>  >
> We removed the label "multicast data" as suggested.
> 
>  >
>  > (4)  Perhaps a time-sequence diagram would be useful, to replace the
>  > diagram in Section 4.1.
>  > (4)  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.
>  >
> 
> 4.1 was reorganized and rewritten to describe the following cases: 
> multiple CPs connected multiple NSPS, multiple CPs to a single NSP, 
> single CP to multiple NSPs and single CP to multiple NSPs. The most 
> general case multiple CPs to mulitple  NSPs was described as a time 
> sequence. Then the other cases were compared to the general case.
> 
> 
>  > (5)  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.
>  >
> 
> We revised this section to better explain what we mean by multiple UIDs 
> and distinguish between NSP assigned userIDs and CP assigned userIDs. 
> Security considerations about handling the IDs are also addressed.
> 
>  > (6)  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.
>  >
> 
> We added separate sections for each use case to section 4.1 to better 
> describe the relationships.
> 
>  > (7)  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.
>  > (8)  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.
>  >
> where appropriate we used the term userID
> furthermore we elaborated on CP-assigned user ID and NSP-assigned user 
> ID in section 4.2
> 
>  > (9)...
>  >    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.
>  >
> 
> Agreed.  We removed mention of the API from the framework in section 4.2
> 
>  >
>  > (10)
>  >   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.
>  >
> 
> Agreed, we deleted any definitions of the log format from section 4.3 
> and instead further clarified the contents of the messages themselves.
> 
>  > (11)...
>  >    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.
> 
> As indicated above 4.3 was rewritten.  The section now specifies 
> accounting issues specific to multicasting such as recording multicast 
> join and leave.
> 
>  > (12)
>  > ...
>  >    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.
>  >
> 
> this text was deleted.
> 
>  >
>  > (13)...
>  > 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?
>  >
> This section was revised to mention CP selection as a responsiblity of 
> the NSP.
> 
>  > (14)
>  > ...
>  > 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.
>  >
> 
> This section was greatly revised.  Mention of an API was removed.  More 
> detailed discussion of multicast-inferred bandwidth management was added 
> including traffic parameters of a multicast channel for admission 
> control which the NSP needs to know and the case of multicast and 
> unicast being provided on the same network.
> 
>  >
>  > (15)
>  > ...
>  >    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.
> 
> The text referred to above was deleted. Instead elaboration of 
> establishment of the connection conditioned on network resources and 
> channel requirements was added to section 4.5.
> 
>  > (16)
>  >   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.
>  >
> 
> We agree that such info needs to be provided but not necessarily in this 
> draft as it is not a Requirements document.
> 
> 
>  > (17)...
>  > 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?
>  >
> This does not introduce additional requirement for the AAA server.
> 
>  >
>  > (18)...
>  > 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.
>  >
> 
> We changed "caching" terminology to proxy terminology throughout the 
> document.
> 
>  > (19)
>  > ...
>  >    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.
>  >
> Agreed. We changed to "re-authenticate"
> 
> Thank you
> Hiroaki
> 

-- 
************************************
NTT Network Service Systems Lab.
Hiroaki Sato
TEL:0422-59-4683 (+81-422-59-4683)
FAX:0422-59-5636 (+81-422-59-5636)
************************************

Delivery-date: Wed, 12 Mar 2008 17:13:25 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RADEXT WG session agenda for IETF-71 (take two)
Date: Wed, 12 Mar 2008 13:11:17 -0400
Organization: Elbrys Networks, Inc.

IETF 71 RADEXT WG Agenda
Friday March 14, 2008
9 AM - 11:30 AM, Franklin 5
 
9 AM - 9:10 AM Preliminaries
   Blue Sheets
   Note Takers
   Jabber Scribe
   Agenda bashing
   Document status
 
Documents having completed RADEXT WG last call (20 minutes)
 
9:20 - 9:30 AM  RADIUS Design Guidelines (Alan DeKok -- remotely)
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

9:30 - 9:40 Extended RADIUS Attributes (Glen Zorn)
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-01
.txt
 
Documents in RADEXT WG last call (10 minutes)

9:40 - 9:50 AM  RADIUS Authorization for NAS Management (David Nelson)
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati
on-02.txt

WG Work items

(none)
 
Pre-WG Work Item Review (20 Minutes) 
 
9:50- 10:00 AM  IEEE 802 Attributes (Bernard Aboba)
http://www.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt
 
10:00 - 10:10 AM  RADIUS support for EAP Re-authentication (Lakshminath
Dondeti)
http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-03.txt

RADIUS Crypto-Agility (40 minutes)
 
10:10 - 10:15 AM  RADEXT Crypto-agility Requirements and Selection Process
(David Nelson)

-- Should the WG publish the RADEXT Crypto Agility Requirements document as
an Informational RFC?

-- What progress is being made on the candidate submissions?
 
10:15 - 10:25 AM  RADIUS over DTLS (Alan DeKok -- remotely)
http://www.watersprings.org/pub/id/draft-dekok-radext-dtls-00.txt
 
10:25 - 10:40 AM  RADIUS Crypto-agility (Joe Salowey / Glen Zorn)
http://www.watersprings.org/pub/id/draft-zorn-radius-keywrap-13.txt
http://www.watersprings.org/pub/id/draft-zorn-radius-encattr-06.txt
 
10:40 - 10:50 AM  Discussion
 
Miscellaneous (40 minutes)

10:50 - 10:57 AM  Roaming Extensions for Radius Server (Vamsi Krishna GONDI)
http://www.ietf.org/internet-drafts/draft-gondi-radext-radius-roaming-01.txt

10:57 - 11:05 AM  Radius Mobility Extensions (Vamsi Krishna GONDI)
http://www.ietf.org/internet-drafts/draft-gondi-radext-radius-mobility-00.tx
t

11:05 - 11:30 AM  RADSEC (Stefan Winter)
http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt

-- Should RADSEC become a RADEXT WG work item, with an accompanying charter
revision?

Delivery-date: Wed, 12 Mar 2008 15:03:56 +0000
Date: Wed, 12 Mar 2008 17:03:03 +0200
From: Hannes Tschofenig <[email-masked]>
To: Hiroaki Sato <[email-masked]>
CC: [email-masked], [email-masked],  "Romascanu, Dan \(Dan\)" <[email-masked]>, [email-masked], [email-masked],  [email-masked], [email-masked]
Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review

Are you subscribed to DIME or RADEXT?
If not, then it might have just disappeared with the rest of the spam

Hiroaki Sato wrote:
> Hi Bernard and Hannes,
>
> Our response is listed in the mboned archive but I don't see it 
> RADEXT:it may be rejected.
> Please see 
> http://www.ietf.org/mail-archive/web/mboned/current/msg00375.html
> I'll resend it to RADEXT ML.
> Should I send it to Diameter ML, too?
>
> Thank you,
> Hiroaki
>
>> Thank you for telling me.
>> We reflected RADEXT comments recieved from Alan. It seems like 
>> http://ops.ietf.org/lists/radiusext/2007/msg00659.html.
>> And I replied to [email-masked] on 2007/11/26.
>> Actually, most of comments were reflected to -05 version.
>> I'll check it once more.
>>
>> Hiroaki
>>
>>> I agree with Hannes.
>>>
>>> So far I have not seen any response on the RADEXT WG mailing list to 
>>> the review of this document:
>>> http://ops.ietf.org/lists/radiusext/2007/msg00659.html
>>>
>>> --------------------------------------------------
>>> From: "Hannes Tschofenig" <[email-masked]>
>>> Sent: Tuesday, March 11, 2008 3:30 PM
>>> To: <[email-masked]>
>>> Cc: "Hiroaki Sato" <[email-masked]>; "Romascanu, Dan 
>>> (Dan)" <[email-masked]>; <[email-masked]>; 
>>> <[email-masked]>; 
>>> <[email-masked]>; <[email-masked]>
>>> Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp 
>>> framework draft, request for review
>>>
>>>> Scott Bradner asked us a while ago to review your AAA framework draft.
>>>> http://www.ops.ietf.org/lists/radiusext/2007/msg00528.html
>>>>
>>>> We at DIME did an initial review. You can find it here:
>>>> http://www.ietf.org/mail-archive/web/dime/current/msg02007.html
>>>> http://www.ietf.org/mail-archive/web/dime/current/msg01912.html
>>>> http://www.ietf.org/mail-archive/web/dime/current/msg01899.html
>>>>
>>>> I recall that there were also reviews from the RADEXT working group.
>>>>
>>>> I don't see these reviews being addressed.
>>>>
>>>> I am also puzzled why the DIME and the RADEXT working group aren't 
>>>> get consulted more involved given that this is clearly about the 
>>>> AAA interworking.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>>
>>>> Hiroaki Sato wrote:
>>>>> Hi all,
>>>>>
>>>>> We, the authors of draft-ietf-mboned-multiaaa-framework-06.txt, 
>>>>> revised
>>>>> our draft and some items refer to the ancp framework draft.
>>>>> So, we'd like to request for you to review our draft and please 
>>>>> comment
>>>>> on it.
>>>>>
>>>>> Major changes include:
>>>>> -two levels of accounting information (start/stop only and plus 
>>>>> volume)
>>>>> -acconting for fast channel change (information merging)
>>>>> -QoS downgrade (admission control)
>>>>>
>>>>> thank you,
>>>>> Hiroaki
>>>>>
>>>>> ---
>>>>> ************************************
>>>>> NTT Network Service Systems Lab.
>>>>> Hiroaki Sato
>>>>> TEL:0422-59-4683 (+81-422-59-4683)
>>>>> FAX:0422-59-5636 (+81-422-59-5636)
>>>>> ************************************
>>>>>
>>>>> ANCP mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/ancp
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Delivery-date: Wed, 12 Mar 2008 14:48:16 +0000
From: <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "'eap-WG'" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "[email-masked]" <[email-masked]>, "Sam Hartman" <[email-masked]>, <[email-masked]>
Subject: Re-review of draft-ietf-hokey-erx-13.txt
Date: Wed, 12 Mar 2008 07:47:23 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C88415.4ED969B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re-Review of draft-ietf-hokey-erx-13.txt

I went through the draft again.  Note that these comments only reflect
my own review;  the author still needs to follow up with other =
reviewers.=20

Here are some overall comments:

1.  I think you need to deal with the potential fraud issues in the
document.  This would involve describing the precautions that a AAA
server should take in authorizing domains to receive DSRKs, and=20
validating subsequent accounting records.=20

2. I think you need to specify the applicability of this specification.
I'm still somewhat uncertain about whether we're talking about
intra-media, inter-media, inter-domain (with some meaning of=20
domain), etc.  Please clear this up.=20

Some details:

   Note that this may introduce some delay in starting EAP.  In some
   lower layers, the delay can be minimized or even avoided by the peer
   initiating EAP by sending messages such as EAPoL-Start in the IEEE
   802.1X specification [10].

[BA] Since ERX is not compatible with IEEE 802.1X (whose state machine
doesn't support peer-initiated messages) I don't see how this is=20
possible.  It might be better to omit the reference.=20

   When the EAP-Request/Identity times out, the authenticator
   MUST NOT close connection if an ERP exchange is in progress or has
   already succeeded in establishing a reauthentication MSK.

[BA] What does "close connection" mean?  Is the document making
normative statements about link layers specified outside the IETF?=20

   The authenticator uses the realm in the keyName-NAI [4] field to send
   the message to the appropriate ER server.

[BA] Do you really mean that the authenticator is using the realm to=20
determine the IP address of the ER server?  Or is the keyname-NAI field=20
just copied into the User-Name attribute so that routing happens
normally? =20

   The local ER server SHALL request
   the home AAA server for the DSRK by sending the domain name in the
   AAA message that carries the EAP-Initiate/Reauth bootstrap message.
   The local ER server MUST be in the path from the peer to the home ER
   server.  If it is not, it cannot request the DSRK.

[BA] Since the local ER server does not determine
whether it is on the path how is "path pinning" to be achieved? How
does the AAA server know whether an ER server is on the path or not?=20
What does it do if it is not on the path?  In other words, what does
the MUST imply? =20

Also, how is the mapping from domain name to IP address
to be achieved?  Is this via an A/AAAA RR?  A SRV RR lookup?=20

Section 4.3

   In case of ERP with the
   home ER server, the peer uses the realm from its original NAI; in
   case of a local ER server, the peer uses the domain name received at
   the lower layer or through a ERP bootstrapping exchange.

[BA] Which "original NAI" are we talking about?  The NAI used in the
EAP-Response/Identity in the original EAP conversation?  The NAI
in the Peer-Id?  The NAI in the ERX conversation?

Section 5.1

   o  In addition, the rMSK is sent along with the EAP-Finish/Re-auth
      message, in a AAA attribute [12].

[BA] Transport of the MSK is already specified in existing AAA =
documents,
such as RFC 4072 (Diameter EAP).  Why is reference 12 being given here
rather than those existing documents?  This document does not update
those specifications.=20

Section 8

      Authenticate all parties

         The EAP Re-auth protocol provides mutual authentication of the
         peer and the server.  Both parties need to possess the keying
         material that resulted from a previous EAP exchange in order to
         successfully derive the required keys.  Also, both the EAP re-
         authentication Response and the EAP re-authentication
         Information messages are integrity protected so that the peer
         and the server can verify each other.  When the ERP exchange is
         executed with a local ER server, the peer and the local server
         mutually authenticate each other via that exchange in the same
         manner.  The peer and the authenticator authenticate each other
         in the secure association protocol executed by the lower layer
         just as in the case of a regular EAP exchange.

[BA] I think you mean "ERX" not "EAP re-authentication" or ERP, right?=20
One thing that is left out here is authentication between the ERX local
server and the ERX home server.  This exists if they are one hop apart,
but otherwise not.  So I think there is an assumption that the ERX =
server
is only willing to provide keys to domains that it is explicitly
authorized to deal with.=20

         It is RECOMMENDED that the AAA protocol be protected using
         IPsec or TLS so that the keys are protected in transit.  Note
         however that keys may be exposed to AAA proxies along the way
         and compromise of any of those proxies may result in compromise
         of keys being transported through them.

[BA] I think you just want to say "It is RECOMMENDED that the AAA =
protocol
protect the keys in transit.  This can be accomplished via transmission
layer security (IPsec or TLS), or via an application-layer mechanism."

      Confidentiality of identity

         Deployments where privacy is a concern may find the use of
         rIKname-NAI to route ERP messages serves their privacy
         requirements.  Note that it is plausible to associate multiple
         runs of ERP messages since the rIKname is not changed as part
         of the ERP protocol.  There was no consensus for that
         requirement at the time of development of this specification.
         If the rIKname is not used and the Peer-ID is used instead, the
         ERP exchange will reveal the Peer-ID over the wire.

[BA] The rest of the spec does not talk about use of the Peer-Id.  Since
not all EAP method deriving keys have a Peer-Id, do you really want this
mentioned here?=20

   To prevent such DoS attacks, an ERP failure should not result in
   deletion of any authorization state established by a full EAP
   exchange. =20

[BA] Is this purely up to this specification to determine?  Typically
the lower layer defines the authorization state and how it is =
installed/removed.
This may not necessarily involve EAP (e.g. 802.11 4-way handshake).=20

------=_NextPart_000_0028_01C88415.4ED969B0
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=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6001.18000" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true"=20
name=3D"Compose message area">
<DIV><FONT face=3DArial size=3D2>Re-Review of=20
draft-ietf-hokey-erx-13.txt</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I went through the draft again.&nbsp; =
Note that=20
these comments only reflect<BR>my own review;&nbsp; the author still =
needs to=20
follow up with other reviewers. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Here are some overall =
comments:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1.&nbsp; I think you need to deal with =
the=20
potential fraud issues in the<BR>document.&nbsp; This would involve =
describing=20
the precautions that a AAA<BR>server should take in authorizing domains =
to=20
receive DSRKs, and <BR>validating subsequent accounting records. =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2. I think you need to specify the =
applicability of=20
this specification.<BR>I'm still somewhat uncertain about whether we're =
talking=20
about<BR>intra-media, inter-media, inter-domain (with some meaning of=20
<BR>domain), etc.&nbsp; Please clear this up. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Some details:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; Note that this may =
introduce some=20
delay in starting EAP.&nbsp; In some<BR>&nbsp;&nbsp; lower layers, the =
delay can=20
be minimized or even avoided by the peer<BR>&nbsp;&nbsp; initiating EAP =
by=20
sending messages such as EAPoL-Start in the IEEE<BR>&nbsp;&nbsp; 802.1X=20
specification [10].</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Since ERX is not compatible with =
IEEE 802.1X=20
(whose state machine<BR>doesn't support peer-initiated messages) I don't =
see how=20
this is <BR>possible.&nbsp; It might be better to omit the reference.=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; When the =
EAP-Request/Identity times=20
out, the authenticator<BR>&nbsp;&nbsp; MUST NOT close connection if an =
ERP=20
exchange is in progress or has<BR>&nbsp;&nbsp; already succeeded in =
establishing=20
a reauthentication MSK.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] What does "close connection" =
mean?&nbsp; Is=20
the document making<BR>normative statements about link layers specified =
outside=20
the IETF? </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; The authenticator uses the =
realm in=20
the keyName-NAI [4] field to send<BR>&nbsp;&nbsp; the message to the =
appropriate=20
ER server.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Do you really mean that the =
authenticator is=20
using the realm to <BR>determine the IP address of the ER server?&nbsp; =
Or is=20
the keyname-NAI field <BR>just copied into the User-Name attribute so =
that=20
routing happens<BR>normally?&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; The local ER server SHALL=20
request<BR>&nbsp;&nbsp; the home AAA server for the DSRK by sending the =
domain=20
name in the<BR>&nbsp;&nbsp; AAA message that carries the =
EAP-Initiate/Reauth=20
bootstrap message.<BR>&nbsp;&nbsp; The local ER server MUST be in the =
path from=20
the peer to the home ER<BR>&nbsp;&nbsp; server.&nbsp; If it is not, it =
cannot=20
request the DSRK.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Since the local ER server does not =

determine<BR>whether it is on the path how is "path pinning" to be =
achieved?=20
How<BR>does the AAA server know whether an ER server is on the path or =
not?=20
<BR>What does it do if it is not on the path?&nbsp; In other words, what =

does<BR>the MUST imply?&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Also, how is the mapping from domain =
name to IP=20
address<BR>to be achieved?&nbsp; Is this via an A/AAAA RR?&nbsp; A SRV =
RR=20
lookup? </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 4.3</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; In case of ERP with=20
the<BR>&nbsp;&nbsp; home ER server, the peer uses the realm from its =
original=20
NAI; in<BR>&nbsp;&nbsp; case of a local ER server, the peer uses the =
domain name=20
received at<BR>&nbsp;&nbsp; the lower layer or through a ERP =
bootstrapping=20
exchange.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Which "original NAI" are we =
talking=20
about?&nbsp; The NAI used in the<BR>EAP-Response/Identity in the =
original EAP=20
conversation?&nbsp; The NAI<BR>in the Peer-Id?&nbsp; The NAI in the ERX=20
conversation?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 5.1</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; o&nbsp; In addition, the =
rMSK is sent=20
along with the EAP-Finish/Re-auth<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
message, in=20
a AAA attribute [12].</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Transport of the MSK is already =
specified in=20
existing AAA documents,<BR>such as RFC 4072 (Diameter EAP).&nbsp; Why is =

reference 12 being given here<BR>rather than those existing =
documents?&nbsp;=20
This document does not update<BR>those specifications. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 8</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Authenticate all=20
parties</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
The EAP Re-auth protocol provides mutual authentication of=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; peer and the=20
server.&nbsp; Both parties need to possess the=20
keying<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; material that =

resulted from a previous EAP exchange in order=20
to<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; successfully =
derive the=20
required keys.&nbsp; Also, both the EAP=20
re-<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; authentication =
Response=20
and the EAP=20
re-authentication<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Information messages are integrity protected so that the=20
peer<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and the server =
can=20
verify each other.&nbsp; When the ERP exchange=20
is<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; executed with a =
local ER=20
server, the peer and the local=20
server<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mutually =
authenticate=20
each other via that exchange in the=20
same<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; manner.&nbsp; =
The peer=20
and the authenticator authenticate each=20
other<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in the secure=20
association protocol executed by the lower=20
layer<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; just as in the =
case of=20
a regular EAP exchange.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] I think you mean "ERX" not "EAP=20
re-authentication" or ERP, right? <BR>One thing that is left out here is =

authentication between the ERX local<BR>server and the ERX home =
server.&nbsp;=20
This exists if they are one hop apart,<BR>but otherwise not.&nbsp; So I =
think=20
there is an assumption that the ERX server<BR>is only willing to provide =
keys to=20
domains that it is explicitly<BR>authorized to deal with. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It=20
is RECOMMENDED that the AAA protocol be protected=20
using<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IPsec or TLS =
so that=20
the keys are protected in transit.&nbsp;=20
Note<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; however that =
keys may=20
be exposed to AAA proxies along the=20
way<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and compromise =
of any of=20
those proxies may result in=20
compromise<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of keys =
being=20
transported through them.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] I think you just want to say "It =
is=20
RECOMMENDED that the AAA protocol<BR>protect the keys in transit.&nbsp; =
This can=20
be accomplished via transmission<BR>layer security (IPsec or TLS), or =
via an=20
application-layer mechanism."</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Confidentiality of=20
identity</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Deployments where privacy is a concern may find the use=20
of<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; rIKname-NAI to =
route ERP=20
messages serves their=20
privacy<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
requirements.&nbsp;=20
Note that it is plausible to associate=20
multiple<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; runs of ERP =

messages since the rIKname is not changed as=20
part<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of the ERP=20
protocol.&nbsp; There was no consensus for=20
that<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; requirement at =
the time=20
of development of this=20
specification.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If =
the=20
rIKname is not used and the Peer-ID is used instead,=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ERP exchange =
will reveal=20
the Peer-ID over the wire.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] The rest of the spec does not talk =
about use=20
of the Peer-Id.&nbsp; Since<BR>not all EAP method deriving keys have a =
Peer-Id,=20
do you really want this<BR>mentioned here? </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; To prevent such DoS =
attacks, an ERP=20
failure should not result in<BR>&nbsp;&nbsp; deletion of any =
authorization state=20
established by a full EAP<BR>&nbsp;&nbsp; exchange.&nbsp; </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Is this purely up to this =
specification to=20
determine?&nbsp; Typically<BR>the lower layer defines the authorization =
state=20
and how it is installed/removed.<BR>This may not necessarily involve EAP =
(e.g.=20
802.11 4-way handshake). </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0028_01C88415.4ED969B0--

Delivery-date: Tue, 11 Mar 2008 23:48:08 +0000
From: <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>
Cc: "Hiroaki Sato" <[email-masked]>, "Romascanu, Dan \(Dan\)" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review
Date: Tue, 11 Mar 2008 16:47:23 -0700

I agree with Hannes.

So far I have not seen any response on the RADEXT WG mailing list to the 
review of this document:
http://ops.ietf.org/lists/radiusext/2007/msg00659.html

--------------------------------------------------
From: "Hannes Tschofenig" <[email-masked]>
Sent: Tuesday, March 11, 2008 3:30 PM
To: <[email-masked]>
Cc: "Hiroaki Sato" <[email-masked]>; "Romascanu, Dan (Dan)" 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>
Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp framework 
draft, request for review

> Scott Bradner asked us a while ago to review your AAA framework draft.
> http://www.ops.ietf.org/lists/radiusext/2007/msg00528.html
>
> We at DIME did an initial review. You can find it here:
> http://www.ietf.org/mail-archive/web/dime/current/msg02007.html
> http://www.ietf.org/mail-archive/web/dime/current/msg01912.html
> http://www.ietf.org/mail-archive/web/dime/current/msg01899.html
>
> I recall that there were also reviews from the RADEXT working group.
>
> I don't see these reviews being addressed.
>
> I am also puzzled why the DIME and the RADEXT working group aren't get 
> consulted more involved given that this is clearly about the AAA 
> interworking.
>
> Ciao
> Hannes
>
>
> Hiroaki Sato wrote:
>> Hi all,
>>
>> We, the authors of draft-ietf-mboned-multiaaa-framework-06.txt, revised
>> our draft and some items refer to the ancp framework draft.
>> So, we'd like to request for you to review our draft and please comment
>> on it.
>>
>> Major changes include:
>> -two levels of accounting information (start/stop only and plus volume)
>> -acconting for fast channel change (information merging)
>> -QoS downgrade (admission control)
>>
>> thank you,
>> Hiroaki
>>
>> ---
>> ************************************
>> NTT Network Service Systems Lab.
>> Hiroaki Sato
>> TEL:0422-59-4683 (+81-422-59-4683)
>> FAX:0422-59-5636 (+81-422-59-5636)
>> ************************************
>>
>> ANCP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ancp
>>
>
> 

Delivery-date: Tue, 11 Mar 2008 13:34:36 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RADEXT WG session agenda for IETF-71 (first take)
Date: Tue, 11 Mar 2008 09:32:08 -0400
Organization: Elbrys Networks, Inc.

Please review and comment upon the attached WG agenda.  We are meeting on
Friday morning.

IETF 71 RADEXT WG Agenda
Friday March 14, 2008
9 AM - 11:30 AM, Franklin 5
 
9 AM - 9:10 AM Preliminaries
   Blue Sheets
   Note Takers
   Jabber Scribe
   Agenda bashing
   Document status
 
Documents having completed RADEXT WG last call (20 minutes)
 
9:20 - 9:30 AM  RADIUS Design Guidelines (Alan DeKok)
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

9:30 - 9:40 Extended RADIUS Attributes (Glen Zorn)
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-01
.txt
 
Documents in RADEXT WG last call (10 minutes)

9:40 - 9:50 AM  RADIUS Authorization for NAS Management (David Nelson)
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorizati
on-02.txt

WG Work items

(none)
 
Pre-WG Work Item Review (20 Minutes) 
 
9:50- 10:00 AM  IEEE 802 Attributes (Bernard Aboba)
http://www.watersprings.org/pub/id/draft-aboba-radext-wlan-04.txt
 
10:00 - 10:10 AM  RADIUS support for EAP Re-authentication (K. Gaonkar)
http://www.ietf.org/internet-drafts/draft-gaonkar-radext-erp-attrs-03.txt

RADIUS Crypto-Agility (40 minutes)
 
10:10 - 10:15 AM  RADEXT Crypto-agility Requirements and Selection Process
(David Nelson)

-- Should the WG publish the RADEXT Crypto Agility Requirements document as
an Informational RFC?

-- What progress is being made on the candidate submissions?
 
10:15 - 10:25 AM  RADIUS over DTLS (Alan DeKok)
http://www.watersprings.org/pub/id/draft-dekok-radext-dtls-00.txt
 
10:25 - 10:40 AM  RADIUS Crypto-agility (Joe Salowey)
http://www.watersprings.org/pub/id/draft-zorn-radius-keywrap-13.txt
http://www.watersprings.org/pub/id/draft-zorn-radius-encattr-06.txt
 
10:40 - 10:50 AM  Discussion
 
Miscellaneous (40 minutes)

10:50 - 10:57 AM  Roaming Extensions for Radius Server (Vamsi Krishna GONDI)
http://www.ietf.org/internet-drafts/draft-gondi-radext-radius-roaming-01.txt

10:57 - 11:05 AM  Radius Mobility Extensions (Vamsi Krishna GONDI)
http://www.ietf.org/internet-drafts/draft-gondi-radext-radius-mobility-00.tx
t

11:05 - 11:30 AM  RADSEC (Stefan Winter)
http://www.ietf.org/internet-drafts/draft-winter-radsec-01.txt

-- Should RADSEC become a RADEXT WG work item, with an accompanying charter
revision?

Delivery-date: Mon, 10 Mar 2008 15:48:36 +0000
From: <[email-masked]>
To: <[email-masked]>
Subject: Review of draft-ietf-radext-management-authorization-02.txt
Date: Mon, 10 Mar 2008 08:46:19 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_0075_01C8828B.35D95640
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Abstract

The current text is a bit wordy.  How about this?=20

   This document describes Remote Authentication Dial-In User Service
   (RADIUS) attributes for the authorization and service provisioning of
   Network Access Servers (NASes).  Both local and remote management
   are supported, with granular access rights and management privileges. =

   Specific provisions are made for remote management via framed
   management protocols, and for specification of a protected transport
   protocol.

Section 7.1

I don't think you need to repeat much of Section 5.6 of RFC 2865.  Why
not just reference it instead?  Here is some recommended text for this
section:

7.1.  Service-Type

   The Service-Type attribute is defined in Section 5.6 of RFC 2865
   [RFC2865].   This document defines a new value of the Service-Type
   Attribute:

      (TBA)     Framed-Management

      The semantics of the Framed-Management service are as follows:

      Framed-Management   A framed management protocol session should
                          be started on the NAS.

Section 8.1

   The Framed-Management-Protocol attribute indicates the application-
   layer management protocol to be used for framed management access.
   It MAY be used in both Access-Request and Access-Accept packets.

[BA] Please add a sentence explaining the semantics in this usage.  For
example, in the Access-Request I assume that this Attribute describes =
the
protocol that the client is using for remote administration.  What does =
it mean
in an Access-Accept?  For example, what does the NAS do if the value in =
the
Access-Accept is different from the protocol that is being used?  Does =
it
disconnect?

  The acronyms used in the above table expand as follows:

   o  SNMP: Simple Network Management Protocol.

[BA] Please add a reference.=20

   o  Web-based: Use of an embedded web server in the NAS for management
      via a generic web browser client.  The interface presented to the
      administrator may be graphical, tabular or textual.  The protocol
      is HTML over HTTP.  The protocol may optionally be HTML over
      HTTPS, i.e. using HTTP over TLS.

[BA] Please add a reference to the HTTP and HTTPS specifications.

   o  NETCONF: Management via the NETCONF protocol using XML over
      supported transports (e.g.  HTTP, BEEP, SOAP).  As secure
      transport profiles are defined for NETCONF, the list of transport
      options may expand.

[BA] Please add a reference to NETCONF specification.

   o  FTP: File Transfer Protocol, used to transfer configuration files
      to and from the NAS.

[BA] Please add a reference to the FTP specification.

   o  TFTP: Trivial File Transfer Protocol, used to transfer
      configuration files to and from the NAS.

[BA] Please add a reference to TFTP specification.

   o  CP: CP (file copy) protocol, used to transfer configuration files
      to and from the NAS.

[BA] What is the CP protocol?  Do you mean RCP?  Please add a reference.

Section 8.2

[BA] What packets can this attribute be included in?  Access-Request & =
Access-Accept?
What are the semantics in each case?  For example, in an Access-Request =
is this the
level of protection that is being used?  What if the value in an =
Access-Accept is different
(e.g. higher) than that in use?  For example, if confidentiality  & =
integrity is being requested,
but the session is protected with TLS and an integrity-only ciphersuite? =
 Is the session
dropped?

   o  Confidentiality-Protection: The management session requires
      protection in a secure or protected transport, that is supported
      by the management access protocol and implementation.  The secure
      transport MUST provide Confidentiality Protection.

Does this option really make sense?  When would you want Confidentiality =
but not integrity?=20
Isn't this dangerous?

Section 8.3

Therefore, two or more occurrences of this attribute
 SHOULD NOT be included in a single service provisioning message, such
 as Access-Accept or CoA.

[BA] I think you mean Change-of-Authorization Request (CoA-Request) =
here.=20

Section 8.4

It MAY be used in both Access-Request and Access-Accept packets.

[BA] The table indicates that it can only be included in Access-Accept =
packets.

Section 9

The examples use the Transport-Protocol Attribute, which is not defined =
in this
document any more.  Also, please include the value of NAS-Port-Type in =
the examples.=20

Section 11

I'd recommend moving this to a sub-section under Security =
Considerations.=20

Section 13

This section needs to be rewritten to list the new attribute for which =
numbers being=20
requested, as well as the new value for Service-Type. 
------=_NextPart_000_0075_01C8828B.35D95640
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=3Dtext/html;charset=3Diso-8859-1>
<META content=3D"MSHTML 6.00.6001.18000" name=3DGENERATOR></HEAD>
<BODY id=3DMailContainerBody=20
style=3D"PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"=20
bgColor=3D#ffffff leftMargin=3D0 topMargin=3D0 CanvasTabStop=3D"true"=20
name=3D"Compose message area">
<DIV><FONT face=3DArial size=3D2>Abstract</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The current text is a bit wordy.&nbsp; =
How about=20
this? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; This document describes Remote Authentication Dial-In =
User=20
Service<BR>&nbsp;&nbsp; (RADIUS) attributes for the authorization and =
service=20
provisioning of<BR>&nbsp;&nbsp; Network Access Servers (NASes).&nbsp; =
Both local=20
and remote management</DIV>
<DIV>&nbsp;&nbsp; are supported, with granular&nbsp;access rights and =
management=20
privileges. <BR>&nbsp;&nbsp; Specific provisions are made for remote =
management=20
via framed<BR>&nbsp;&nbsp; management protocols, and for specification =
of a=20
protected transport<BR>&nbsp;&nbsp; protocol.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 7.1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I don't think you need to repeat much =
of Section=20
5.6 of RFC 2865.&nbsp; Why</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>not just reference it instead?&nbsp; =
Here is some=20
recommended text for this</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>section:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>7.1.&nbsp; Service-Type<BR><BR>&nbsp;&nbsp; The Service-Type =
attribute is=20
defined in Section 5.6 of RFC 2865<BR>&nbsp;&nbsp; =
[RFC2865].&nbsp;&nbsp; This=20
document defines&nbsp;a new value of&nbsp;the Service-Type</DIV>
<DIV>&nbsp;&nbsp; Attribute:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
(TBA)&nbsp;&nbsp;&nbsp;&nbsp;=20
Framed-Management<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The semantics of =
the=20
Framed-Management service are as =
follows:<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Framed-Management&nbsp;&nbsp; A framed management protocol session=20
should<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
be started on the NAS.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 8.1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>&nbsp;&nbsp; The Framed-Management-Protocol =
attribute=20
indicates the application-<BR>&nbsp;&nbsp; layer management protocol to =
be used=20
for framed management access.<BR>&nbsp;&nbsp; It MAY be used in both=20
Access-Request and Access-Accept packets.<BR></FONT></DIV>
<DIV><FONT face=3DArial>[BA] Please add a sentence explaining the =
semantics in=20
this usage.&nbsp; For</FONT></DIV>
<DIV><FONT face=3DArial>example, in the Access-Request I assume that =
this=20
Attribute describes the</FONT></DIV>
<DIV><FONT face=3DArial>protocol that the client is using for remote=20
administration.&nbsp; What does it mean</FONT></DIV>
<DIV><FONT face=3DArial>in an Access-Accept?&nbsp; For example, what =
does the NAS=20
do if the value in the</FONT></DIV>
<DIV><FONT face=3DArial>Access-Accept is different from the protocol =
that is being=20
used?&nbsp; Does it</FONT></DIV>
<DIV><FONT face=3DArial>disconnect?</DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp; The acronyms used in the above table expand as=20
follows:<BR><BR>&nbsp;&nbsp; o&nbsp; SNMP: Simple Network Management=20
Protocol.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Please add a reference.=20
</FONT><BR><BR>&nbsp;&nbsp; o&nbsp; Web-based: Use of an embedded web =
server in=20
the NAS for management<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; via a generic =
web=20
browser client.&nbsp; The interface presented to=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; administrator may be graphical, =
tabular or=20
textual.&nbsp; The protocol<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is HTML =
over=20
HTTP.&nbsp; The protocol may optionally be HTML=20
over<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; HTTPS, i.e. using HTTP over =
TLS.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Please add a reference to the HTTP =
and HTTPS=20
specifications.</FONT><BR><BR>&nbsp;&nbsp; o&nbsp; NETCONF: Management =
via the=20
NETCONF protocol using XML over<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
supported=20
transports (e.g.&nbsp; HTTP, BEEP, SOAP).&nbsp; As=20
secure<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transport profiles are defined =
for=20
NETCONF, the list of transport<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; options =
may=20
expand.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Please add a reference to=20
NETCONF&nbsp;specification.</FONT><BR><BR>&nbsp;&nbsp; o&nbsp; FTP: File =

Transfer Protocol, used to transfer configuration=20
files<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to and from the NAS.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] Please add a reference to the=20
FTP&nbsp;specification.</FONT><BR><BR>&nbsp;&nbsp; o&nbsp; TFTP: Trivial =
File=20
Transfer Protocol, used to transfer<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
configuration files to and from the NAS.</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR><FONT face=3DArial =
size=3D2>[BA] Please add=20
a reference to&nbsp;TFTP&nbsp;specification.</FONT></DIV><FONT =
face=3DArial=20
size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT>
<DIV><BR>&nbsp;&nbsp; o&nbsp; CP: CP (file copy) protocol, used to =
transfer=20
configuration files<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to and from the=20
NAS.<BR><BR><FONT face=3DArial size=3D2>[BA] What is the CP =
protocol?&nbsp; Do you=20
mean RCP?&nbsp; Please add a reference.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 8.2</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[BA] What packets can this attribute be =
included=20
in?&nbsp; Access-Request &amp; Access-Accept?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>What are the semantics in each =
case?&nbsp; For=20
example, in an Access-Request is this the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>level of protection that is being =
used?&nbsp; What=20
if the value in an Access-Accept is different</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(e.g. higher) than that in use?&nbsp; =
For example,=20
if confidentiality&nbsp; &amp; integrity is being =
requested,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>but the session is protected with TLS =
and an=20
integrity-only ciphersuite?&nbsp; Is the session</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>dropped?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; o&nbsp; Confidentiality-Protection: The management =
session=20
requires<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; protection in a secure or =
protected=20
transport, that is supported<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by the =
management=20
access protocol and implementation.&nbsp; The=20
secure<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transport MUST provide =
Confidentiality=20
Protection.<BR><BR><FONT face=3DArial size=3D2>Does this option really =
make=20
sense?&nbsp; When would you want Confidentiality but not integrity?=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Isn't this dangerous?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 8.3</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>Therefore, two or more occurrences of this =
attribute<BR>&nbsp;SHOULD NOT be=20
included in a single service provisioning message, such<BR>&nbsp;as=20
Access-Accept or CoA.<BR></DIV>
<DIV><FONT face=3DArial size=3D2>[BA] I think you mean =
Change-of-Authorization=20
Request (CoA-Request) here. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 8.4</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>It MAY be used in both Access-Request and=20
Access-Accept&nbsp;packets.<BR></DIV>
<DIV><FONT face=3DArial size=3D2>[BA] The table indicates that it can =
only be=20
included in Access-Accept packets.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 9</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The examples use the Transport-Protocol =
Attribute,=20
which is not defined in this</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>document any more.&nbsp; Also, =
p</FONT><FONT=20
face=3DArial size=3D2>lease include the value of NAS-Port-Type in the =
examples.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 11</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I'd recommend moving this to a =
sub-section under=20
Security Considerations. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Section 13</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>This section needs to be rewritten to =
list the new=20
attribute for which numbers being </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>requested, as well </FONT><FONT =
face=3DArial=20
size=3D2>as the new value for Service-Type. </FONT></DIV></BODY></HTML>

------=_NextPart_000_0075_01C8828B.35D95640--

Delivery-date: Sun, 09 Mar 2008 19:56:10 +0000
Date: Sun, 09 Mar 2008 20:51:45 +0100
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Alan DeKok' <[email-masked]>,  'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: Re: Consensus call and conclusion of RADEXT WG last call on draft-ietf-radext-extended-attributes-00.txt

Glen Zorn wrote:
> Alan, I really wish that you could say something about this w/o frothing
> at the mouth.  In fact, this paragraph was just left in _by mistake_

  I'm sorry I can't tell intent from the content of the draft.

> from my changes that introduced the (obviously excellent to me,
> apparently akin to heretical to you) idea of allowing the extended and
> legacy typespaces to overlap.

  I have no objection to them overlapping.  It's a *good* idea for them
to overlap.  I just don't know what it means to allow old-style
attributes in a new-style format.

>  If that was the case, one would obviously
> need to be able to determine if type 29 was legacy type 29 or new type
> 29.  In any case, I gave up the battle for sanity in this WG some time
> ago, so you can stop: one will never be able to group legacy RADIUS
> attributes, nor have more than one instance > 255 octets in length in a
> single message.  Happy?

  Never.  RADIUS is a horrible protocol with huge amounts of legacy
cruft.  I am very wary of breaking existing systems, no matter how
appealing the idea may seem.

  Alan DeKok.

Delivery-date: Sun, 09 Mar 2008 18:23:30 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Consensus call and conclusion of RADEXT WG last call on draft-ietf-radext-extended-attributes-00.txt
Date: Sun, 9 Mar 2008 14:21:04 -0400

[email-masked] <> scribbled on Saturday, March 08, 2008
10:12 AM:

> Bernard Aboba wrote:
>> Two comments were received:
>> http://ops.ietf.org/lists/radiusext/2008/msg00095.html
>> http://ops.ietf.org/lists/radiusext/2008/msg00096.html
> 
>  I have a review pending, too.  But I'll add a few comments here.
> 
>>    o  The first bit is the Standard or 'S' flag.  The Standard flag
>>       is set (1) if the TLV is a standard RADIUS attribute (as
>>       defined in RFC 2865, for example), otherwise it is clear (0).
> 
>  That's just bad practice.  With a 16-bit format, there's
> plenty of room to leave the first 256 attributes as
> "old-style".  A separate bit to indicate this does nothing
> more than complicate things.

Alan, I really wish that you could say something about this w/o frothing
at the mouth.  In fact, this paragraph was just left in _by mistake_
from my changes that introduced the (obviously excellent to me,
apparently akin to heretical to you) idea of allowing the extended and
legacy typespaces to overlap.  If that was the case, one would obviously
need to be able to determine if type 29 was legacy type 29 or new type
29.  In any case, I gave up the battle for sanity in this WG some time
ago, so you can stop: one will never be able to group legacy RADIUS
attributes, nor have more than one instance > 255 octets in length in a
single message.  Happy?

...

Delivery-date: Sat, 08 Mar 2008 21:49:34 +0000
From: Avi Lior <[email-masked]>
To: Bernard Aboba <[email-masked]>, Alper Yegin <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 8 Mar 2008 16:49:02 -0500
Subject: RE: Re-auth failure
Accept-Language: en-US
acceptlanguage: en-US

This is exactly true in the case you specify.
But consider the case where the NAS or the Device itself decides to reauthe=
nticate OR for that matter in Diameter where we do have an Authorization Li=
feTime and a Session time.

NASREQ has text that covers this scenario and IMO is correct:

2.2.  Diameter Session Reauthentication or Reauthorization

Snip

   A Diameter server informs the NAS of the maximum time allowed before
   reauthentication or reauthorization via the Authorization-Lifetime
   AVP [BASE].  A NAS MAY reauthenticate and/or reauthorize before the
   end, but A NAS MUST reauthenticate and/or reauthorize at the end of
   the period provided by the Authorization-Lifetime AVP.  The failure
   of a reauthentication exchange will terminate the service.

Cant be clearer then this.

The business reasons are clearer.

A HAAA server authorizes a service and by doing so is willing to pay the NA=
S to deliver that service.  If reauthentication fails, then the HAAA can no=
t be on the hook for paying for service.  OR from the user's perspective, i=
f reauthentication fails you cant expect the user to pay for the service si=
nce upon presntation of a bill the user will claim it wasn't him.

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, March 07, 2008 2:38 PM
> To: Alper Yegin; [email-masked]
> Subject: Re: Re-auth failure
>
> If we are talking about EAP, then Re-authentication is driven
> by the authenticator.
> RFC 3579 states that this occurs on expiration of the
> Session-Timeout value, so that the maximum session time has
> already been utilized by the time it occurs.
>
> Therefore if the user fails authentication, they have no
> remaining time left on the session.
>
> --------------------------------------------------
> From: "Alper Yegin" <[email-masked]>
> Sent: Friday, March 07, 2008 7:48 AM
> To: <[email-masked]>
> Subject: Re-auth failure
>
> > RFC 3579 says:
> >
> >   Reception of a RADIUS Access-Reject packet MUST result in the NAS
> > denying
> >   access to the authenticating peer.
> >
> >
> > Consider a host that is already authenticated and authorized for
> > network access. If it performs re-authentication say 1 hour
> before the
> > session timeout and fails authentication (EAP-Failure),
> should the NAS
> > disconnect the host from the network immediately? According
> to the RFC
> > 3579 text, it MUST eject the host immediately.
> >
> > Shouldn't the network have the option to let the host stay
> connected
> > until the expiration of the currently granted session, if
> it chooses
> > to? If so, is there a different interpretation of the above
> text, or a
> > different message (Access-Accept with EAP-Failure?) recommended?
> >
> > Thanks.
> >
> > Alper
> >
> >
> >
> > --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in
> a single line as the message text body.

Delivery-date: Sat, 08 Mar 2008 21:38:57 +0000
From: Avi Lior <[email-masked]>
To: Alper Yegin <[email-masked]>, "'David B. Nelson'" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 8 Mar 2008 16:37:55 -0500
Subject: RE: Re-auth failure
Accept-Language: en-US
acceptlanguage: en-US

> For example, if the user is on a pre-paid account and his
> credit has reached 0 yet still has 1 more hour to go with the
> current session, that left-over time shall not be taken away
> from him just because his "request to extend"
> the session was not granted. [I don't know pre-paid support
> well enough to say whether this is already taken care of by
> some means.]

In this case we dont send a reject but rather an accept indicating that the=
re is no more quota allowing the NAS to let the user finish off his quota.

Delivery-date: Sat, 08 Mar 2008 18:16:23 +0000
Date: Sat, 08 Mar 2008 19:12:27 +0100
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Consensus call and conclusion of RADEXT WG last call on draft-ietf-radext-extended-attributes-00.txt

Bernard Aboba wrote:
> Two comments were received:
> http://ops.ietf.org/lists/radiusext/2008/msg00095.html
> http://ops.ietf.org/lists/radiusext/2008/msg00096.html

  I have a review pending, too.  But I'll add a few comments here.

>    o  The first bit is the Standard or 'S' flag.  The Standard flag is
>       set (1) if the TLV is a standard RADIUS attribute (as defined in
>       RFC 2865, for example), otherwise it is clear (0).

  That's just bad practice.  With a 16-bit format, there's plenty of
room to leave the first 256 attributes as "old-style".  A separate bit
to indicate this does nothing more than complicate things.

>    o  The next 2 octets are the Ext-Type field

  See my earlier comments.  If we're going to a 2-byte Ext-Type field,
then the Diameter AVP format is more flexible, powerful, and takes up
just as much space as this format.

> a. Do you support increasing the size of the Extended-Type field to two
> octets,
> from one octet?

  No.

> b. Do you support use of the RADIUS Extended Type VSAs to encode standard
> RADIUS attributes?

  No.

  My preferences for the format, in order of priority, are:

  1) Extended format as in -00 of the draft
  2) Diameter AVP format as in draft-wolff-radext-ext-attribute
  3) anything else

  Alan DeKok.

Delivery-date: Sat, 08 Mar 2008 17:43:23 +0000
From: Bernard Aboba <[email-masked]>
To: <[email-masked]>
Subject: Consensus call and conclusion of RADEXT WG last call on draft-ietf-radext-extended-attributes-00.txt
Date: Sat, 8 Mar 2008 09:41:28 -0800

--_e1323898-a6cc-47ef-bad6-0b9acc05171f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RADEXT WG last call has concluded on draft-ietf-radext-extended-attributes-=
00.txt.=20

Two comments were received:
http://ops.ietf.org/lists/radiusext/2008/msg00095.html
http://ops.ietf.org/lists/radiusext/2008/msg00096.html

This leaves three open issues on the document (225, 250 and 251):
http://www.drizzle.com/~aboba/RADEXT/

A new version of the document has been posted to the archive:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-0=
1.txt

The major difference between version -00 and -01 appears to be a change to =
the TLV format:=20

In -00, Section 4 stated:

"   TLVs are encoded as follows:

   o  The first octet is the Ext-Type field

   o  The second octet is the Ext-Length field, representing of the
      entire TLV, including the length of the Ext-Type field (1 octet),
      the length of the Ext-Length field itself (1 octet) and the length
      of the Value field (1 or more octets)"

-01 Section 4 now states:

"   TLVs are encoded as follows:

   o  The first bit is the Standard or 'S' flag.  The Standard flag is
      set (1) if the TLV is a standard RADIUS attribute (as defined in
      RFC 2865, for example), otherwise it is clear (0).

   o  The next 2 octets are the Ext-Type field

   o  The next octet is the Ext-Length field, representing of the entire
      TLV, including the length of the Ext-Type field (2 octets), the
      length of the Ext-Length field itself (1 octet) and the length of
      the Value field (1 or more octets)

   o  The Value field consists of one or more octets comprising the
      actual data."

Since previous discussion of these changes on the RADEXT WG mailing list
was inconclusive (see http://ops.ietf.org/lists/radiusext/2008/msg00000.htm=
l)
the Chairs would like to determine whether RADEXT WG consensus exists for
the changes or not.=20

We are requesting RADEXT WG participants to review the -01 Extended Attribu=
tes
draft and to post a note the RADEXT WG mailing list indicating their suppor=
t=20
(or opposition) to the changes.  Specifically:

a. Do you support increasing the size of the Extended-Type field to two oct=
ets,
from one octet?=20

b. Do you support use of the RADIUS Extended Type VSAs to encode standard
RADIUS attributes?=20

The Consensus call will last until March 29, 2008. =20

--_e1323898-a6cc-47ef-bad6-0b9acc05171f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
RADEXT WG last call has concluded on draft-ietf-radext-extended-attributes-=
00.txt. <br><br>Two comments were received:<br>http://ops.ietf.org/lists/ra=
diusext/2008/msg00095.html<br>http://ops.ietf.org/lists/radiusext/2008/msg0=
0096.html<br><br>This leaves three open issues on the document (225, 250 an=
d 251):<br>http://www.drizzle.com/~aboba/RADEXT/<br><br>A new version of th=
e document has been posted to the archive:<br>http://www.ietf.org/internet-=
drafts/draft-ietf-radext-extended-attributes-01.txt<br><br>The major differ=
ence between version -00 and -01 appears to be a change to the TLV format: =
<br><br>In -00, Section 4 stated:<br><br>"&nbsp;&nbsp; TLVs are encoded as =
follows:<br><br>&nbsp;&nbsp; o&nbsp; The first octet is the Ext-Type field<=
br><br>&nbsp;&nbsp; o&nbsp; The second octet is the Ext-Length field, repre=
senting of the<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; entire TLV, including the =
length of the Ext-Type field (1 octet),<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t=
he length of the Ext-Length field itself (1 octet) and the length<br>&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; of the Value field (1 or more octets)"<br><br>-01 =
Section 4 now states:<br><br>"&nbsp;&nbsp; TLVs are encoded as follows:<br>=
<br>&nbsp;&nbsp; o&nbsp; The first bit is the Standard or 'S' flag.&nbsp; T=
he Standard flag is<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set (1) if the TLV is=
 a standard RADIUS attribute (as defined in<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; RFC 2865, for example), otherwise it is clear (0).<br><br>&nbsp;&nbsp; o=
&nbsp; The next 2 octets are the Ext-Type field<br><br>&nbsp;&nbsp; o&nbsp;=
 The next octet is the Ext-Length field, representing of the entire<br>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; TLV, including the length of the Ext-Type field =
(2 octets), the<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; length of the Ext-Length =
field itself (1 octet) and the length of<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
the Value field (1 or more octets)<br><br>&nbsp;&nbsp; o&nbsp; The Value fi=
eld consists of one or more octets comprising the<br>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; actual data."<br><br>Since previous discussion of these changes on=
 the RADEXT WG mailing list<br>was inconclusive (see http://ops.ietf.org/li=
sts/radiusext/2008/msg00000.html)<br>the Chairs would like to determine whe=
ther RADEXT WG consensus exists for<br>the changes or not. <br><br>We are r=
equesting RADEXT WG participants to review the -01 Extended Attributes<br>d=
raft and to post a note the RADEXT WG mailing list indicating their support=
 <br>(or opposition) to the changes.&nbsp; Specifically:<br><br>a. Do you s=
upport increasing the size of the Extended-Type field to two octets,<br>fro=
m one octet? <br><br>b. Do you support use of the RADIUS Extended Type VSAs=
 to encode standard<br>RADIUS attributes? <br><br>The Consensus call will l=
ast until March 29, 2008.&nbsp; <br><br><br><br></body>
</html>=

--_e1323898-a6cc-47ef-bad6-0b9acc05171f_--

Delivery-date: Fri, 07 Mar 2008 19:38:39 +0000
From: "Bernard Aboba" <[email-masked]>
To: "Alper Yegin" <[email-masked]>, <[email-masked]>
Subject: Re: Re-auth failure
Date: Fri, 7 Mar 2008 11:37:53 -0800

If we are talking about EAP, then Re-authentication is driven by the 
authenticator.
RFC 3579 states that this occurs on expiration of the Session-Timeout value,
so that the maximum session time has already been utilized by the time it 
occurs.

Therefore if the user fails authentication, they have no remaining time left 
on
the session.

--------------------------------------------------
From: "Alper Yegin" <[email-masked]>
Sent: Friday, March 07, 2008 7:48 AM
To: <[email-masked]>
Subject: Re-auth failure

> RFC 3579 says:
>
>   Reception of a RADIUS Access-Reject packet MUST result in the NAS 
> denying
>   access to the authenticating peer.
>
>
> Consider a host that is already authenticated and authorized for network
> access. If it performs re-authentication say 1 hour before the session
> timeout and fails authentication (EAP-Failure), should the NAS disconnect
> the host from the network immediately? According to the RFC 3579 text, it
> MUST eject the host immediately.
>
> Shouldn't the network have the option to let the host stay connected until
> the expiration of the currently granted session, if it chooses to? If so, 
> is
> there a different interpretation of the above text, or a different message
> (Access-Accept with EAP-Failure?) recommended?
>
> Thanks.
>
> Alper
>
>
>
> --

Delivery-date: Fri, 07 Mar 2008 19:17:44 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 14:16:00 -0500
Organization: Elbrys Networks, Inc.

Alper Yegin writes...

> For that reason and others, I think it's not RADIUS "protocol"
> specification's role to dictate what a NAS should be doing with
> the output of this protocol's execution.

Since RADIUS is all about authorization and service provisioning, you would
not be able to get multi-vendor interoperability at a behavioral level if
every NAS interpreted the standardized RADIUS messages in an implementation
dependent fashion.

The *semantics* of the messages, in terms of what they dictate for NAS
behavior is all part of the RADIUS specification.

> I think the reaction to a RADIUS state is an "architectural" decision,
> and belongs to the users of this protocol.

If you want to re-use RADIUS messaging formats in an implementation
featuring user customized actions for each message, then feel free to do so,
but please don't call it RADIUS.  :-)

Delivery-date: Fri, 07 Mar 2008 18:34:09 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alper Yegin'" <[email-masked]>, "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 10:33:48 -0800

[email-masked] <> scribbled on Friday, March 07, 2008 9:03
AM:

> Hi Alan,
> 
>>> Shouldn't the network have the option to let the host stay
>>> connected until the expiration of the currently granted session, if
>>> it chooses to? If
>> so, is
>>> there a different interpretation of the above text, or a different
>>> message (Access-Accept with EAP-Failure?) recommended?
>> 
>>   I tend to agree with David here.  RADIUS servers have traditionally
>> been authoritative, so the user has to be rejected here.
>> 
>>   Much of the confusion comes about because RADIUS has traditionally
>> had no definition of what a "session" is.  In this case, the server
>> *is* authoritative for a session.  However, it's unclear whether or
>> not the second session is related to the first, if at all.
> 
> For that reason and others, I think it's not RADIUS "protocol"
> specification's role to dictate what a NAS should be doing
> with the output of this protocol's execution. 

So the semantics of RADIUS messages are not in the scope of the protocol
definition?  Sounds like COPS ;-)

> I think the
> reaction to a RADIUS state is an "architectural" decision, and
> belongs to the users of this protocol. An architecture spec
> can determine when and how to use the protocol, and how to
> react to this protocol's output.

How would different "architectures" interoperate?  How would the rules
be expressed?  How could multiple architectures be reasonably supported
in a single network?  It seems like this idea is fine for walled gardens
(WiMAX?), not so good for the Internet.  OTOH, if you have a walled
garden you can make up any rules you like anyway, so why worry about it?

> 
> I wonder if this view is shared and ever used in
> deployments/implementations, or if practically everybody is
> following the interpretation described by Alan/David.

AFAIK, your viewpoint is unique :-).

> 
> Alper
> 
> 
> 
> 
>> 
>>   NASes have traditionally made fail-safe decisions: If they receive
>> an Access-Reject for a authentication tied to one MAC address, that
>> MAC address is denied access.  This happens even if there are other
>> "sessions" tied to that MAC which may still have access rights.
>> 
>>   Alan DeKok.
>> 
>> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in
> a single line as the message text body.

Delivery-date: Fri, 07 Mar 2008 18:27:39 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alper Yegin'" <[email-masked]>, "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 10:26:26 -0800

[email-masked] <> scribbled on Friday, March 07, 2008 8:54
AM:

> Thank you for the response.
> 
>>> Shouldn't the network have the option to let the host stay connected
>>> until the expiration of the currently granted session, if it chooses
>>> to?
>> 
>> I suppose that depends on whether one considers the responses of the
>> RADIUS Server to be authoritative or merely advisory.  One can
>> construct reasonable use cases to support either notion,
> 
> For example, if the user is on a pre-paid account and his
> credit has reached 0 yet still has 1 more hour to go with the
> current session, that left-over time shall not be taken away
> from him just because his "request to extend"
> the session was not granted. [I don't know pre-paid support
> well enough to say whether this is already taken care of by some
> means.] 

I think that in this case the problem arises from trying to overload the
Access-Request & Access-Accept/Reject messages a little too much: the
semantics of the question being asked don't match those of the messages
used.

...

Delivery-date: Fri, 07 Mar 2008 17:03:01 +0000
From: "Alper Yegin" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 19:02:40 +0200

Hi Alan,

> > Shouldn't the network have the option to let the host stay connected
> until
> > the expiration of the currently granted session, if it chooses to? If
> so, is
> > there a different interpretation of the above text, or a different
> message
> > (Access-Accept with EAP-Failure?) recommended?
> 
>   I tend to agree with David here.  RADIUS servers have traditionally
> been authoritative, so the user has to be rejected here.
> 
>   Much of the confusion comes about because RADIUS has traditionally had
> no definition of what a "session" is.  In this case, the server *is*
> authoritative for a session.  However, it's unclear whether or not the
> second session is related to the first, if at all.

For that reason and others, I think it's not RADIUS "protocol"
specification's role to dictate what a NAS should be doing with the output
of this protocol's execution. I think the reaction to a RADIUS state is an
"architectural" decision, and belongs to the users of this protocol. An
architecture spec can determine when and how to use the protocol, and how to
react to this protocol's output.

I wonder if this view is shared and ever used in
deployments/implementations, or if practically everybody is following the
interpretation described by Alan/David.

Alper

> 
>   NASes have traditionally made fail-safe decisions: If they receive an
> Access-Reject for a authentication tied to one MAC address, that MAC
> address is denied access.  This happens even if there are other
> "sessions" tied to that MAC which may still have access rights.
> 
>   Alan DeKok.
> 
> --

Delivery-date: Fri, 07 Mar 2008 16:54:58 +0000
From: "Alper Yegin" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>, <[email-masked]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 18:54:11 +0200

Thank you for the response.

> > Shouldn't the network have the option to let the host stay connected
> > until the expiration of the currently granted session, if it chooses
> > to?
> 
> I suppose that depends on whether one considers the responses of the
> RADIUS
> Server to be authoritative or merely advisory.  One can construct
> reasonable
> use cases to support either notion, 

For example, if the user is on a pre-paid account and his credit has reached
0 yet still has 1 more hour to go with the current session, that left-over
time shall not be taken away from him just because his "request to extend"
the session was not granted. [I don't know pre-paid support well enough to
say whether this is already taken care of by some means.]

> although historically we have
> considered
> the responses of the RADIUS Server to be authoritative.
> 
> If the Access-Reject was caused by a transient failure somewhere in the
> system, including the back-end authentication service, one might want to
> allow a customer to finish out his pre-allocated session time.  If the
> Access-Reject was caused by a system administrator's action to de-
> authorize
> a user (maybe an employee who is about to be fired), one would almost
> certainly want the session to be terminated upon a failed re-
> authentication.

That makes sense. AAA server can have its own reasons for expecting
different outcomes from issuing Access-Reject. But how does the NAS know how
to react to receiving an Access-Reject? Unless some auxiliary info is
provided to the NAS, it cannot know the real intention of the AAA when
issuing the reject. I wonder if there are such cases where a RADIUS
attribute is used for helping NAS make the right decision.

Thank you.

Alper

Delivery-date: Fri, 07 Mar 2008 16:31:12 +0000
Date: Fri, 07 Mar 2008 17:27:25 +0100
From: Alan DeKok <[email-masked]>
To: Alper Yegin <[email-masked]>
CC: [email-masked]
Subject: Re: Re-auth failure

Alper Yegin wrote:
> Shouldn't the network have the option to let the host stay connected until
> the expiration of the currently granted session, if it chooses to? If so, is
> there a different interpretation of the above text, or a different message
> (Access-Accept with EAP-Failure?) recommended?

  I tend to agree with David here.  RADIUS servers have traditionally
been authoritative, so the user has to be rejected here.

  Much of the confusion comes about because RADIUS has traditionally had
no definition of what a "session" is.  In this case, the server *is*
authoritative for a session.  However, it's unclear whether or not the
second session is related to the first, if at all.

  NASes have traditionally made fail-safe decisions: If they receive an
Access-Reject for a authentication tied to one MAC address, that MAC
address is denied access.  This happens even if there are other
"sessions" tied to that MAC which may still have access rights.

  Alan DeKok.

Delivery-date: Fri, 07 Mar 2008 16:06:52 +0000
Content-class: urn:content-classes:message
Subject: RE: RADEXT Meeting Slot (was RE: Call for Agenda items for IETF 71 RADEXT WG meeting)
Date: Fri, 7 Mar 2008 17:06:23 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "David B. Nelson" <[email-masked]>, <[email-masked]>

I think that the schedule is final now, or at least I would think that
making a change now will cause more problems.=20

Dan
=20

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: Friday, March 07, 2008 5:10 PM
> To: [email-masked]
> Subject: RE: RADEXT Meeting Slot (was RE: Call for Agenda=20
> items for IETF 71 RADEXT WG meeting)
>=20
> Stefan Winter writes...
>=20
> > Just surfing the IETF web site: the word "DRAFT" was=20
> removed from the=20
> > meeting agenda page meanwhile, and the radext session is=20
> still in the=20
> > Friday morning slot. Can you confirm that this is final now?
>=20
> I've seen what you've seen.  I tend to reach the same=20
> conclusion.  I don't know if there are any more schedule=20
> changes that the Secretariats plans to release, but at this=20
> late date I tend to doubt it.
>=20
> On the other hand, I note that the conflict between RADEXT=20
> and NMRG on Friday still exists.
>=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.
>=20

Delivery-date: Fri, 07 Mar 2008 16:02:08 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 11:00:31 -0500
Organization: Elbrys Networks, Inc.

Alper Yegin writes...

> Shouldn't the network have the option to let the host stay connected
> until the expiration of the currently granted session, if it chooses
> to?

I suppose that depends on whether one considers the responses of the RADIUS
Server to be authoritative or merely advisory.  One can construct reasonable
use cases to support either notion, although historically we have considered
the responses of the RADIUS Server to be authoritative.

If the Access-Reject was caused by a transient failure somewhere in the
system, including the back-end authentication service, one might want to
allow a customer to finish out his pre-allocated session time.  If the
Access-Reject was caused by a system administrator's action to de-authorize
a user (maybe an employee who is about to be fired), one would almost
certainly want the session to be terminated upon a failed re-authentication.

Delivery-date: Fri, 07 Mar 2008 15:49:07 +0000
From: "Alper Yegin" <[email-masked]>
To: <[email-masked]>
Subject: Re-auth failure
Date: Fri, 7 Mar 2008 17:48:20 +0200

RFC 3579 says:

   Reception of a RADIUS Access-Reject packet MUST result in the NAS denying
   access to the authenticating peer.

Consider a host that is already authenticated and authorized for network
access. If it performs re-authentication say 1 hour before the session
timeout and fails authentication (EAP-Failure), should the NAS disconnect
the host from the network immediately? According to the RFC 3579 text, it
MUST eject the host immediately. 

Shouldn't the network have the option to let the host stay connected until
the expiration of the currently granted session, if it chooses to? If so, is
there a different interpretation of the above text, or a different message
(Access-Accept with EAP-Failure?) recommended?

Thanks.

Alper 

Delivery-date: Fri, 07 Mar 2008 15:11:52 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: RADEXT Meeting Slot (was RE: Call for Agenda items for IETF 71 RADEXT WG meeting)
Date: Fri, 7 Mar 2008 10:10:07 -0500
Organization: Elbrys Networks, Inc.

Stefan Winter writes...

> Just surfing the IETF web site: the word "DRAFT" was removed from
> the meeting agenda page meanwhile, and the radext session is still
> in the Friday morning slot. Can you confirm that this is final now?

I've seen what you've seen.  I tend to reach the same conclusion.  I don't
know if there are any more schedule changes that the Secretariats plans to
release, but at this late date I tend to doubt it.

On the other hand, I note that the conflict between RADEXT and NMRG on
Friday still exists.

Delivery-date: Fri, 07 Mar 2008 14:47:39 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: "David B. Nelson" <[email-masked]>
Subject: Re: RADEXT Meeting Slot (was RE: Call for Agenda items for IETF 71 RADEXT WG meeting)
Date: Fri, 7 Mar 2008 15:38:15 +0100
Cc: [email-masked]

--nextPart2154255.J7eF34IJCU
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

> Just a "heads-up" to the WG members that the IETF-71 Meeting Agenda is
> apparently not final, and that there is a conflict for the O&M Area
> Directors in the Friday morning slot.  There was some discussion of moving
> RADEXT to a Monday afternoon slot, if the schedule can be so juggled.
>
> Stay tuned...

Just surfing the IETF web site: the word "DRAFT" was removed from the meeti=
ng=20
agenda page meanwhile, and the radext session is still in the Friday mornin=
g=20
slot. Can you confirm that this is final now?

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

--nextPart2154255.J7eF34IJCU
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart2154255.J7eF34IJCU--