RE: RADEXT WG Last Call on NAS ManagementAuthorizationSpecification

["David B. Nelson" <[e-mail]>]

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.


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



Envelope-to: [e-mail]
Delivery-date: Mon, 31 Mar 2008 20:53:14 +0000
From: "David B. Nelson" <[e-mail]>
To: "'David Harrington'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RADEXT WG Last Call on NAS ManagementAuthorizationSpecification
Date: Mon, 31 Mar 2008 16:50:28 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <017001c89370$da42f2e0$1f0a0a0a@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Ach491ishn12o/RWQ3O1M0GWoJe2MQARRdiQBhifgaAAZwwaIAAJ0JTwAAIQldA=

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.


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


Envelope-to: [e-mail]
Delivery-date: Mon, 31 Mar 2008 18:02:46 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Cc: "'David Harrington'" <[e-mail]>, <[e-mail]>
Subject: RE: RADEXT WG Last Call on NAS Management Authorization Specification
Date: Mon, 31 Mar 2008 14:00:30 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <016501c89359$1bcc5ed0$1f0a0a0a@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AciTWRuTBhkSj2gmT7qScXx6kIx4Gw==

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.

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

OK.

> section 6:
> OLD: "To aid in understanding of this document, it"
> NEW: "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.
 
> 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?

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.

> section 8.2
> s/The acronyms used/The names used/

OK.
 
> 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 protocol MUST protect against unauthorized
> disclosure of information.  The secure transport MUST provide
> encryption.

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.

> 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?

Both, which one depending upon context.

> Will IANA know just which TBA should be replaced with which assigned
> type or value?

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.
 
> Author's Address:
> 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.

> Requested changes:
> Section 3:
> OLD: "NETCONF (XML over HTTP/BEEP/SOAP)"
> 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.

> Section 4:
> VACM is composed of multiple tables
> OLD: (VACM) table [RFC3415],
> NEW: (VACM) [RFC3415],

OK.

> section 8.1 (and elsewhere)
> 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
> lump the non-secure and secure versions into Configuration-based, and
> Polling-based names and so on?

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

> section 8.3
> The first paragraph says zero or more, while the fourth paragraph
> says you should not send two or more.
> OLD" "Zero or more"
> NEW: "Zero or one"

OK.

> Paragraph 3 says what to do if one is received; and paragraph talks
> about receiving more than one. What if zero are received?

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."
> Doesn't this potentially override what the management protocol says
> 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".

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

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."
> How does it increase the minimum privilege level or decrease the
> 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...
 
> 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?

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

> I would change Example #4 to use a Management-Policy-ID="Level 15"
> rather than a Management-Privilege-Level=15

This is dependent on resolution of a previous comment.

> 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 think that the "v3" is as editing artifact, left over from the -01 version
of the draft.

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

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

> 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:

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?
 
> Example#8 doesn't mention which transport protocol should be used to
> 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


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


Envelope-to: [e-mail]
Delivery-date: Mon, 31 Mar 2008 18:02:26 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: FW: [Isms] FW: RADEXT WG Last Call on NAS ManagementAuthorizationSpecification
Date: Mon, 31 Mar 2008 13:58:56 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <016101c89358$e39a3b40$1f0a0a0a@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: Ach491ishn12o/RWQ3O1M0GWoJe2MQARRdiQBhifgaAAbm+ZcA==

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> David Harrington
> Sent: Saturday, March 29, 2008 11:53 AM
> To: 'David B. Nelson'; [e-mail]
> Cc: [e-mail]
> 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: [e-mail]
> 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: [e-mail]
> 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: [e-mail]
> 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
> [e-mail]
> [e-mail]
> [e-mail]
> 
> 
> _______________________________________________
> Isms mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isms


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


Envelope-to: [e-mail]
Delivery-date: Fri, 28 Mar 2008 11:37:41 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: Reminder of RADEXT WG Last Call on NAS Management Authorization Specification
Date: Fri, 28 Mar 2008 07:36:42 -0400
Message-ID: <030a01c890c7$ff9c8ac0$6401a8c0@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Ach491ishn12o/RWQ3O1M0GWoJe2MQXz/trA

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: [e-mail] [mailto:[e-mail]] =
On
Behalf Of Bernard Aboba
Sent: Tuesday, February 26, 2008 11:12 PM
To: [e-mail]
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/


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


Envelope-to: [e-mail]
Delivery-date: Thu, 27 Mar 2008 02:41:11 +0000
Date: Wed, 26 Mar 2008 22:40:53 -0400
To: [e-mail]
From: David Mitton <[e-mail]>
Subject: list test
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <[e-mail]>

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.


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


Envelope-to: [e-mail]
Delivery-date: Tue, 25 Mar 2008 00:43:55 +0000
From: Avi Lior <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Mon, 24 Mar 2008 20:43:09 -0400
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Thread-Topic: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Thread-Index: AciF5aUvBkCFdYXLRlirVvq1mFcMJwIK1YPw
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8A8CFE8F89C38B41A749C19328C76D6301E4BFDEF3exchange02bri_"
MIME-Version: 1.0

--_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: [e-mail] [mailto:[e-mail]] On=
 Behalf Of [e-mail]
Sent: Friday, March 14, 2008 11:10 AM
To: [e-mail]
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> [e-mail]=20
  [mailto:[e-mail]] <B>On Behalf Of=20
  </B>[e-mail]<BR><B>Sent:</B> Friday, March 14, 2008 11:1=
0=20
  AM<BR><B>To:</B> [e-mail]<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_--

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


Envelope-to: [e-mail]
Delivery-date: Sun, 23 Mar 2008 18:42:43 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: <[e-mail]>
Subject: Minutes from IETF 71
Date: Sun, 23 Mar 2008 11:41:44 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0194_01C88CDA.DE6E7840"

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


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


Envelope-to: [e-mail]
Delivery-date: Thu, 20 Mar 2008 18:02:01 +0000
From: "Sanchez, Mauricio (ProCurve)" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Date: Thu, 20 Mar 2008 18:00:55 +0000
Subject: FW: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item 
Thread-Topic: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item 
Thread-Index: AciKqy52nxM0iLe6S6yXygWVcvTmkwACRkcw
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_004_C7B67062D31B9E459128006BAAD0DC3D0757D1BB90G6W0269americ_"
MIME-Version: 1.0

--_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: [e-mail]
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
[e-mail]

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




--_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> [e-mail]<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>

[e-mail] <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

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a
HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABOAJADASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwCb40/E
TxV4S8Z2thoeqm1tXsEmaM28Unzl5ATllJ6KKwW8U/HGKwGot9tez8oT+YNPtyNm3OeEzjHNVv2j
v+Sh2P8A2Co//RstdRa/tB6Jp3he2srfSr+W8t7RIV37AhdUAyTuJxkelAG38Jfi5ceMrx9G1uGG
PURGZIJoRtWYD7wK5OGHXjgjPTHPrmR6ivlz4EaBfah42fXREUsrGKUtIBhS7qVCj8yfwrl9HvvE
+peIr/Q9GurmS41J3tyDM3C78nnPA459qAPssEMMggj1FG5c43DPpmvnfxp4g1z4a/DrQ/B8FysG
qTRO9zPA/KJuPCt2Jz19qo3vwq1HTfhz/wAJkuvXq6wsC3borEYUnOA+c5wc5oA+lmZURndgqqMk
k4AFfO3i342+Ida8QtongdNkRk8mGaOESzXDZ5Kg5Cr6cZ75Ha54c+JGo698GPFMV/M0up6dbeX5
/wDFJFJ8oJ9x8wz9K579nS0in8fXlxIqlrfT3aPPZi6Ln8iR+NABcfEL4r+BdQt5PEIkkhmzthvY
U8uTGM4dMEEZ7HjPSvoTwl4osvGHhq01qxBSOcEPExy0Tg4ZT9D+Ywe9VPHPgqy8d6HFpd7PLAkd
ws6yRAFgQGGOfZjXB+MPCFt8PPgd4gstJvbtleeG4Du+GVjLCpwVxxhaAPYgQehoyPWvH/2fLq4u
/AmqPPcSzONQcAyMWI/dp6muC+CV/e3HxTnimvLiWMQzna8rMPyzQB9O5HrSBgQCCCDXxtbaj4nu
vGWo6Xot5dPdX081sqCduFZznHPHHevSPGXgnWvDvwV07zLiRL/Sp2eb7NKQPLkPOSOuDigD6Coy
D3rxn4fePBD8D9Qv7m4d7rSEkh3McsWP+r6+7D8q5LQfEmpeBvhBc+IWupJNY126MVmZnL+Ui5y4
BOODu/MUAfSRdQcFgD6Zpa+W/C/hCx8YaE+u+IfHf2bVp2fyEmuQWTBwC5ZsjJzwO2K6/wCBXj3V
L/VLvwrrN292YommtZ5X3sNpAZN38Q5yD7H2oA5T9o3/AJKHY/8AYKj/APRste0eHfAPhOfw5pNx
LoFg8r2cLs5iHJKDJpvjDwT4Q8T+IrSTX7G5mvXhEEMiPIqbQzELlTjOWJrs7SCCytYbKDCxwRrG
iZyQoGB/Km00JSTGQ2Vrp9g1vZ20VvAqnEcSBVH4CvmT4KKD8ZJSRkrHcke3WvqQgMpB6EYNcloH
w08L+GdbbWNLspIr1gwLtO7jDdeCcUhnkv7SGi3A1LStaVGa2aI27sOiuDkZ+oP6V0WrfETQbj4G
kJfwG+msFtRahv3gfAUjHtyc163qemWOsafLYajbR3NrKMPHIuQa4JPgX4DS7E/9mzsA27ymuXKf
lnpQB578EfB0+seD/FbXCmO31SAWcDsOCwDHd7gFl/KuO+HniJ/hh8RLhdbtpUQI9neKBlo/mUhg
O/Kj8DX1lb29ppdgsFtDHb2sCYWONcKqj0FcXqei+B/iRZafqF5ZCdrtmhhmUNFMrKrMUYjkYCtw
f60AcF8TfjbZT6NFYeD9QuBeSSK8l3Gu0RoMnaM9ycfhmlv28TX/AOzVrN74juJ7m7u5Ip4fNUBl
gE0WMgDvhm+hFdTp/wAN/hj4dlg1PZbz/wCkpbxPcXPnJ5xICrjOM5x16V6NdQ2N9Yy2VysM1rNG
0ckTYKsnRhj05waAPn/4M+PvD3hTwRq9tq98sFyLlp44SpLSgxqAF98qevrWF8CHL/FKR2UqWt5i
VPGK9f0z4R/D3T9bFxBbJLcwETC3lui6oOoYoT05HXjpV7w/4R8FaL4svNQ0mMpqQjaWaX7QzIBI
xB6nbnIP0oA8U+EyK3x1k3AHEl2Rn1+avpbWtLh1rRL7TLhQ0V1C0TA+461y2h+BfBug+IBrtnbt
a6lLJIqme6OWZiQwClsc84rrW1WwW+WxN5B9rY4EAcF+mfujkcUAfGFu2r2MmoeDItym+vY4ZIyO
S6MQP517T8a/B8lp8M9DWwjZrfRCI5FUZIRlC7j+IH5121v4R8DXXji411YV/ty3uGd987D5wvLB
CcEAHriuxv57WLT7qS6CyW6QtJKhG7KAEnjuMA0AfN/w+0z4Waj4QSXxJMlvqtuX+0CSdl3DcSpU
DqMEDA7ium+EcnhHVfGU8/h3wveWbWUUn+myXRdArHaBt9WGTj2Naus/Df4Yqkepz6fcwx3Fo96k
dvI4DRrsJwueD86jHHWu58Hw6FplvNoujaZJpjWwSSS2mj2uVfIWQnJ3A7WGcnlSDigDpqpzWdrF
dNqf2YvdJEV3ICWK9cAd6uUU07CaTOfttVI0i9vRcyx7ZCR/aURjWLp8vAGR+daaagrJ5oQyW/le
YJ4T5ise4UDJP5VcdFdSrqGU9QRkGsMW1xNq8JudGtxBbFvs88coygx/d96v3ZXMPfhZXubEdzDK
xRJFLgBmTOGUHpkdRUtc0qyfZLhpbLU4PLnE21is5fnooOePp0q1Bfy2/lQs4JdHmCywuhC9QCec
Ed8/lQ6fYI177o1buNprOeNMb3jZVz6kVwF54K1hrO0trCaCBLiwkivQzH93c/ZmhSVSPUMFbH90
Hrmuyg1uCXbu27XQyKyOGBUYBbHBxk46VoRypKoKn8DwRUuLW5rGpGWzPO38M6nNZNd/2M63MFzY
SLbTXcLGRYHJYIEVUX5WKgkgtjBCgcuvfButTatdTQSRCxe5KRRPJ8y2t0d14D1G7f8AMvptxXot
FSWecXfhTWLmKewjsIY2inv7gah5y/6Us6yhIyPvA/vFBzwBGME8AW5vCGoRalb3VmES3s7K2WKy
Vgsc0kbklX/A8HkZ57V3lFAHnieCr8w6kZoLd5prd44GZ8lSZ2k/Dgis3wtdoni+FJ0LzC4uEigi
lQywbvvNNGR5m3jqxxyOuRXp11eW9lF5lxKsa9BnqfoOpqlHeTalcKbJtlmhy85H+sP91Qe3qapR
drkOcU+W+pyeoeGbyTU78T2NsLO6v1vJNQ84AxQquGUjG7cRkDHGCckVb8P6ZfXXhDU2kn8+5vIZ
Le0lZSu6FVKRE55+YfMf9412tFSWeb3nw+nj0q2i0+Mi4/saeznMl47fvH8nG3cSAPkbkY7V22ma
JaaXPcXETXEtxcBVkluJ3lYqudqgsTgDc3A9TWlRQAUUUUAFFFFAGVfaXfXV0ZYNXntkwAI0jUgf
nRc2VyLuOc6w8MI25iKLhsdeTzzWrVO/0qy1MRi8gWURnKgk4FWp6q5jOkrNpa+plXTQQGaS512J
Y51IiV40IQZ7evpzVcm0Fy8P2wySwwv5ojteWb+9kd+nHfFbTWOnWNoH+yRCK3QlQI9xUdTis9dZ
v77/AJBmlPsP/La5/dr+XWtYu60/Q55xUH734XY23mvvKQQfa2Bh3gvAFBYMSc7jkFumPcGlbVbu
0cm6ktkXAwsrgMCcnouc44HvUg0rUrs7tR1R1U9YbUbFA+vWqyz6bZXLW2jWK3l7/E4O4IfVnP8A
LrTST8/67k+/Fb29f8kTJrN86+alovkY/wBZLmJB05y3JHXt6VXW+1S/cy29ykdsnLTeXtjx7E8t
+gqy+nKqNqGv3SyCP5vKziGP6D+I/Wkggm150muozDpi8xWxGDL6M3t6CmnFapA1Udotu/b/AD7I
r2OnnVJjOzyNa9DPJ9+49h/dT6da6VEWNFRFCqowABwKUAKAAMAdBS1hObkddKkqa8woooqDUKKK
KACiiigAooooAKKKKACjoOKKKAOeNhq2sO39pS/Y7PJH2aBvmcf7Tf0FaEsmneHtMLbUt7dOioOW
PoB3JrRrHTRXn1l9Q1GcXHlt/osIGEiHrju3vWqlzfFol0RzOm4awV5PqyC1sbnWbhL/AFVPLgQ7
rezPb0Z/U+3at+iipnNyNadNQXd9woooqDQKKKKACiiigD//2Q==

--_004_C7B67062D31B9E459128006BAAD0DC3D0757D1BB90G6W0269americ_--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 20 Mar 2008 17:47:00 +0000
From: "Glen Zorn" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 20 Mar 2008 13:44:49 -0400
Message-ID: <001901c88ab2$266b30f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciKn4xm8ty5zqCISRyEMXDGEca5YwACJTiwAAJ2fCA=

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



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


Envelope-to: [e-mail]
Delivery-date: Thu, 20 Mar 2008 17:38:02 +0000
From: "Sanchez, Mauricio (ProCurve)" <[e-mail]>
To: "[e-mail]" <[e-mail]>
CC: Bernard Aboba <[e-mail]>
Date: Thu, 20 Mar 2008 17:36:36 +0000
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item 
Thread-Topic: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item 
Thread-Index: AciKqy52nxM0iLe6S6yXygWVcvTmkw==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: application/x-pkcs7-mime; smime-type=signed-data; name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Transfer-Encoding: base64
MIME-Version: 1.0

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggOpQ29u
dGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQYXJ0XzAw
MF8wMDM3XzAxQzg4QTcwLjgyNDBFMzgwIg0KWC1NUy1UTkVGLUNvcnJlbGF0b3I6IDYwMUE5ODJF
QUI4QUM4MDENCg0KVGhpcyBpcyBhIG11bHRpcGFydCBtZXNzYWdlIGluIE1JTUUgZm9ybWF0Lg0K
DQotLS0tLS09X05leHRQYXJ0XzAwMF8wMDM3XzAxQzg4QTcwLjgyNDBFMzgwDQpDb250ZW50LVR5
cGU6IHRleHQvcGxhaW47DQoJY2hhcnNldD0idXMtYXNjaWkiDQpDb250ZW50LVRyYW5zZmVyLUVu
Y29kaW5nOiA3Yml0DQoNCkkgYW0gaW4gZmF2b3Igb2YgYWNjZXB0aW5nIFJBRFNFQyBhbmQgdGhl
IHN0YXR1cyB1cGRhdGUgZHJhZnQgYXMgUkFERVhUIFdHDQp3b3JrIGl0ZW1zLg0KDQpDaGVlcnMs
DQpNUw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCk1h
dXJpY2lvIFNhbmNoZXosIENJU1NQIA0KQ2hpZWYgU2VjdXJpdHkgQXJjaGl0ZWN0IA0KDQpQcm9D
dXJ2ZSBOZXR3b3JraW5nIGJ5IEhQIA0KSGV3bGV0dCBQYWNrYXJkIA0KODAwMCBGb290aGlsbHMg
Qm91bGV2YXJkLCBtcyA1NTQxDQpSb3NldmlsbGUgQ0EsIDk1NzQ3LTU1NTcgDQo5MTYuNzg1LjE5
MTAgVGVsIA0KOTE2Ljc4NS4xODE1IEZheCANCm1hdXJpY2lvLnNhbmNoZXpAaHAuY29tIA0KIA0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCi0tLS0t
LT1fTmV4dFBhcnRfMDAwXzAwMzdfMDFDODhBNzAuODI0MEUzODANCkNvbnRlbnQtVHlwZTogYXBw
bGljYXRpb24vbXMtdG5lZjsNCgluYW1lPSJ3aW5tYWlsLmRhdCINCkNvbnRlbnQtVHJhbnNmZXIt
RW5jb2Rpbmc6IGJhc2U2NA0KQ29udGVudC1EaXNwb3NpdGlvbjogYXR0YWNobWVudDsNCglmaWxl
bmFtZT0id2lubWFpbC5kYXQiDQoNCgSDAUROZUo4K0loUVFBUWFRQ0FBRUFBQUFBQUFCQUFFQUFR
ZVFCZ0FJQUFBQTVBUUFBQUFBQUFEb0FBRUlnQWNBR0FBQUFFbFFUUzVOYVdOeQ0KYjNOdlpuUWdU
V0ZwYkM1T2IzUmxBREVJQVFPUUJnQ3NJd0FBTXdBQUFBc0FIdzRCQUFBQUFnSDREd0VBQUFBUUFB
QUFOc2hhVE9mcw0KaWs2MW5UMmc4MURlQ0FJQitnOEJBQUFBRUFBQUFIUWtyZmxscGpCTms2dmhZ
UmQ5NHQ4REFQNFBCUUFBQUFNQURUVDlQNlVHQXdBUA0KTlAwL3BRWUNBUlEwQVFBQUFCQUFBQUJV
bEtIQUtYOFFHNldIQ0FBcktpVVhIZ0Q2UHdFQUFBQWlBQUFBVTJGdVkyaGxlaXdnVFdGMQ0KY21s
amFXOGdLRkJPUWlCU2IzTmxkbWxzYkdVcEFBQUFBd0JPZ0FNZ0JnQUFBQUFBd0FBQUFBQUFBRVlB
QUFBQUFZRUFBQUFBQUFBRg0KQUZDQUF5QUdBQUFBQUFEQUFBQUFBQUFBUmdBQUFBQUNnUUFBQUFB
QUFBQUFBQUFEQUFlQkF5QUdBQUFBQUFEQUFBQUFBQUFBUmdBQQ0KQUFBUWdRQUFBQUFBQUFNQUNJ
RURJQVlBQUFBQUFNQUFBQUFBQUFCR0FBQUFBQkdCQUFBQUFBQUFDd0FFZ1FNZ0JnQUFBQUFBd0FB
QQ0KQUFBQUFFWUFBQUFBSklFQUFBQUFJQUFMQUVDQUF5QUdBQUFBQUFEQUFBQUFBQUFBUmdBQUFB
QWNnUUFBQUFCMEFBc0FBNEVESUFZQQ0KQUFBQUFNQUFBQUFBQUFCR0FBQUFBQ3lCQUFBQUFIUUFB
d0JWZ0FNZ0JnQUFBQUFBd0FBQUFBQUFBRVlBQUFBQUtZRUFBQUFBQUFBRA0KQUFtQkF5QUdBQUFB
QUFEQUFBQUFBQUFBUmdBQUFBQXFnUUFBQUFBQUFCNEFBb0VESUFZQUFBQUFBTUFBQUFBQUFBQkdB
QUFBQUNlQg0KQUFBQkFBQUFBUUFBQUFBQUFBQURBQ2FBQXlBR0FBQUFBQURBQUFBQUFBQUFSZ0FB
QUFBU2dRQUFBUUFBQUFNQVBvQURJQVlBQUFBQQ0KQU1BQUFBQUFBQUJHQUFBQUFCT0JBQUFCQUFB
QUhnQlRnQU1nQmdBQUFBQUF3QUFBQUFBQUFFWUFBQUFBSVlFQUFBRUFBQUFCQUFBQQ0KQUFBQUFB
c0FCWUVESUFZQUFBQUFBTUFBQUFBQUFBQkdBQUFBQUFPQkFBQUFBQzBBQXdBOWdBTWdCZ0FBQUFB
QXdBQUFBQUFBQUVZQQ0KQUFBQUk0RUFBUC8vLzM4TEFBYUJBeUFHQUFBQUFBREFBQUFBQUFBQVJn
QUFBQUFtZ1FBQUFBQXRBQXNBQklBSUlBWUFBQUFBQU1BQQ0KQUFBQUFBQkdBQUFBQUFhRkFBQUFB
Q0FBQXdBUmdBZ2dCZ0FBQUFBQXdBQUFBQUFBQUVZQUFBQUFBWVVBQUFBQUFBQUxBQkNBQ0NBRw0K
QUFBQUFBREFBQUFBQUFBQVJnQUFBQUFEaFFBQUFBRGRvd3NBQm9BSUlBWUFBQUFBQU1BQUFBQUFB
QUJHQUFBQUFBNkZBQUFBQUZNQQ0KQXdBRGdBZ2dCZ0FBQUFBQXdBQUFBQUFBQUVZQUFBQUFFSVVB
QUFBQUFBQURBSW1BQ0NBR0FBQUFBQURBQUFBQUFBQUFSZ0FBQUFBWQ0KaFFBQUFBQUFBQXNBajRB
SUlBWUFBQUFBQU1BQUFBQUFBQUJHQUFBQUFJS0ZBQUFCQUhZQUFnRUpFQUVBQUFDU0hRQUFqaDBB
QUpOLw0KQUFCTVdrWjF1VnNaS2djQUJnRUJDMkJ1WnpFd01tWTFBR1FBY21Od0RkQU9BRElGREdC
akRVUm1NekUxTUVJM0FQVnpkSE5vQlhCaQ0KZEdOb0Q5STJFSVFKQUJFTGFETU9zQkVhWW1rUDF3
MmtNek9KRkNabVpSU2pkR2hsQjRDZkZHY1YxeFZnQVVBVjEyTnpBZWp6QXFRVA0Kc0dScEF6WUNB
QkVBQ3NBSWMyVjBBdEZ3Y25FeXBRQUFLZ3FoYm04YVVDQU44TlVib1RZVXNEQVA4RFFjSVFIUTJS
d1FOSDBIYlJyeQ0KWmdkQUJVRDlCMk45QW9NQVVCa21BK01aL3hzTC9tSWI0UnhRRzdJaVZCelFC
eE1kNTFwSUZoQjJJSUFPc0dFZXhETStOQmtmSUU4Yg0KTmllZko4QjlRKzVoQnRBSElRWFFZUlhR
SGVjbzROSnNCQUIwYndYUVZDU0ZFQkQvSDA4bUx4dEhBVEFjY2lLekhBRWkwa2NxTWlrUg0KSGVk
TWRYb0dFaTNxUWdid1pDU0ZPQ3RmTEc4aFhtY2NGQ0l5SE5GaGFBTnhBb00wWHc4Z01ZOHluek92
TkxoV0JKQmsvd0J3TmFRUA0KMGhrUE55OGJMeHcvSFUvL0hsc1AwaDhvTzY4OHZ6M1BQdDgvNy84
NmxUWVlRZzlESDBTalJIUkVVaTcwL3lrRE9uY1UwRWZ2U1A5RA0KcjBTL1JjLy9RSDBrLzAzUFR0
OVA3MUQvVWc4T0VQOVRQMVJQVlY5V2IxZC9RSDBSWURZLy8xcXZMWTh1bnkrdk1Ma1A0MW1mWVE5
dg0KVzc5Y3oxM2ZIbmswWDlobXpETGZNVkpuMGg1a0I3Z3FJRVZyRHpYUzMyWXZiV1pUQW00dmJ6
TjVDTEZ2djgwMThEbHcvMmRFTVRZZg0KSVhLLzlRT0NSd25SYTNRL0FmRVA4SFdmNzNhbU5oRjNY
d09DVkFod2VQOTZBcnRCYjNhV055dEJmQjhEZ2lnajhQc3BFQWZRS1gyZg0KZWdKSHozLzNiZi8v
Z1pZSEVBR2dEckNDZjNuelRMOTJsdTQ0WDlHRnJ3T0NRaDR4RHJDSGY3OTZBbE1mZHBlSXdZcWZn
Y05XQ0pEMg0KZERwUUI0RmxoMjk1ODEvZmJXLzNCeE52YWlQOU5TdFBjZitVNVhRWi81WCtkWWhn
ZkhjSWxPUjRyQ1A5YVJEL20wOTdicFRrZldxZQ0Kbmg4dmYvK1U1UCtDRDU2ZU5oK0U3NlgxaHc2
ZW5vakkvNXZkaWxlVTVJdnRucDZObUp2ZWp6Yi9wZldRejdBL01VRnNYNVBmS09wdg0KYW4wcVB6
aHc3NWdQdUd4MEdibnZPTjkxajV4UHVHdDRyTDYvT1hwUG9LLzN1R3Q5YXNPdk9ZalByZys0YTR2
dC9jaCtOSGNBc1grMw0KYjJQVWIycGt6Ly9PWVpiL3ZCL1F0M1FaMGUvT1lacy8vOER2MExaNHJO
YVBOZkdmbjhYZjBMYi9mV3JiVHpYeHJQL0tyOUMyaSszZg0KNy84MThjNmZ6NjgxVkc5aE5iWFRM
OVEvLytnV2RCQTF0ZGZQMk4vb0ZYaWpOYlQvYVREc1gzdHY2Q1I5WWU4bG85K2s3Ly9vRmFaVw0K
N3lXb2I2bC85T2FIQmU4bC8rRXY0ai9vRll2azd5V3hiN0ovOU9hL3MvbnZKVmw0NXAwQ1lQUjlW
R2RBZW1uMXhUYmwvK2NQT2dYbw0KZHpidjZSL3FMd1puNjdZMjdFL3RYd1ptdmU3Wk4rK2Y4SzhH
WnZJbk4vblA5L3JmQm1iOFdqZjlMLzQvQm1iL3YvOWw0akZvdHUrUA0KVDI4ZlFIMi8zd2lQOXhy
ZmRCODZkakYrN3d2UGQ2OTR2LzhobVlQZkR5OThiMzEvSWJmSm4vUGYvNCsvZ2g4aGJJMmY5MTh1
TDRjUA0KSVd6L1dYOFNiNHJ2aS84aGlyWlBGZDh6VC8rei96b3ZOOEE3WHhuZkd1OC9MeUhWM3gx
L0hvOUN6eUN2VENZeUlrOGpYLzhrYnlWLw0KU1lrblB5aFBLVjhxYjBtbi95d1BMUjg5Ynk4L1NW
d3hMekkvVmgvL05GOUpYRFpQTjE4NGJ6bC9TWG83VCs4OFgxcy9QbjlpSHpKQQ0KcjBHL3VHYi82
SVZKOGtWdlJuOXF0K3UxR0hIeXVmOUszOHRON3RodkFrOHZVRCs0WnZJbS8yOENYajlmVDdobS9G
bHZBbWlmYWEvLw0KUjQ5RDMyN0dhKzlzLzN2ZlNKOFlKdi9PY0g2UFMxOU1iMDEvZ3FoeXozUGYv
MUZQVWwrQ3QxUC9WUTlsWDFjdmdtei9XUjlhTDQ4dg0KWEUrQ2JIWXZkejlnWDM5aGI0S0tZejlr
VDVSUFptK2JMelQvZWI5Nno0Q2ZmTytDeG41L2Y0K2p6LytCcnhnbUlpQ21mNFJ2aFgrRw0KajZx
WS80Zy9pVStLWDR0dnFxZU5ENDRmbm0vL2tEK3FYSkl2a3orM0g1VmZxbHlYVC8rWVg1bHZtbitx
ZXB4UG5WKzhQNTkvL2NNZg0KTmFHdm9yK29qNlRmcXJhbWIvK25mOHUvcVo4WUp0bFN6bytzZjYy
UC82NmYwcWF3TDdFL3NrK3pYOUtYdFAvL3RnL0dYN2d2MGt5Ng0KSDdzdjN3KzlULy9TVEw4L3dF
L0JYOEp2MG1yRVA4VlBkK1F2eDIvckR6YkptQVR2ZDlkc2htbDFFY3lxVEhWNlU5UHd3SE10UW05
cw0KWk5LSUNyL2Z6Mi96cDlHSjlOOFlZamZUS0F0Zi8vTTkxa3o1bi9xajJCZ092L005MnpyLy9u
LzZvK2NvRWYvelBlcE5Bei82by8vSg0Kbi9LZjBIL016L3AyemwvM1R3dXYrOUdQR0NZNDB5LzhE
OVZQMWw4U2FmL1lId0R2MmovYlR4S0gzTy9kLys1UC8rQWZFanppRCtNZg0KSHYvbFB4STg1eS8v
QmEvcFQrcGZFbHJzTCswL0pCL3ZYd3NxK1RYQlkvVmdiM0owWWdoc08xejlvR1F3WEdlTi9hRnVN
Z0F4a0hWbA0KTURHLyttVmVJRFV5NmpRQk03ODB5VExVZnpUeU0xODNMemJ0Tm04MG56THZaZjR4
YUlBOHVqM1JQWTgrbVRMVVBzSy9QUzlBLzBDOQ0KUUQ4K2IwSTBPWFJnLzBXRVJ1RS9BMGJnUEw4
MVowRWZQMkRUVHFFcXNHUmxGQkZ3TElGTzRTb3dkOEZ6VHhBZ1N1WndZZmxMZ1hGcw0KTElEendE
SUFkU0F5QUtIN29HUmpkR3hNOEhKTjhDVWxNSEJMTVdGMUt2QmNZUjV6VFBCT1VQd1FUMUp1ZFcw
VEtzRlBFSFJ2VDFCaw0KYW5Ya2MzUjFJR2RvVDBCMUlESmhVL1BBTW1GcGRFMEFNRXhnWEJodWIz
RjM0U1RBYjNSbHBpQllvRkVRZVd3a1FHajlzUDUwV0tCTg0KVDA1ZlQyOVFmMUdQU0NDblZWQVVJ
QlFCY3pFc2dHRkxzeThlY0Zwd1RERldZR3dUNEdjeC9qQmVJRlJ4V0RCWjVGbUJTN2xVZ0cxYg0K
Y3pNYzBGdGlaajh3WGRKajUwTEFMRkJkYzI1d1hjbGZaQ3lBb0hOdVpYaDBXWUZ6VXREZk1XQWsw
R2VBVTRCMzhHa3hZRkl3dm5saA0KQWxPZ2NJQXNVR3ZRTUYzUStqbGdnRTVoWWpHZ1N1TmFJVm1C
ZDFmZ0xHQjQ4SFpUVUZPQUw4QnRQR2xvTEZCTE1DVHdVNEIxYnIxbA0Ka1dWWUVESGdZYmxhUUVS
V0JEUWdVUHdnWVVMQVRRQm9JTkJHYjI1MFN0UjBXakFURUZ0cFVCT3dkMThBV0RCbWFWQlg4U3hR
ZEdoQw0KSE5CWU1FendaTEF1YkZ1Z0k1QnE1SEpyV0daczEyckdhakJzeDJKc3gzSnF3VEdRVDFH
Z01mRnV4Rk9nY0dWcXdYUHdZMlZzYkZVUg0KYXBCcU1XOGgvbk5sQURGd0t1RnBRU0FnYStCeGhq
cHNjWlZpY1pWVmtIR2taR2ZmY29aMEFIT0dXZkJ4cEhaTkwxVlAvMVpmVjI5WQ0KZjFtUFdwOWJy
MXkvWGMvL1h0OWY3eFNBZStGbFQyWllZVVpqaFA4dUlDVkFVOEJqNTMxeFpLaDdYSHNodDMycWQ5
QXhJR1llVUdDUg0KWW5nUVB6SGdhTUJrWW9MdlpsaGlwRGc0NmpjdG9EQjc0RWh2c1hKd1VhQzZh
MlBuTm9aL2g0K0ltemlKZi8rS2o0dWZqS0pvc0hCQQ0KYWRBeDRJenYvNGxTamo5N3p5NFFmWjkr
cG9rd1lRTHZrVStTVm1IcWpRRnphTUNGVVZPQXNURXdiWEJ2TDhDVGYwVWswUGhwYkZOVA0Kb2g1
UW9SS1hjQ09RLzNYL2R3OTRIM2t2ZWorVzdpT1FmSkgvRkpCODc1ajNJNUdtMG44dmdEK0JULyth
ZG1FQ2dtT1JBbzB5UnRDUg0KMzVMdi80eFhCekV4VUdqQUxpQmcwV1BucmVGL2xsK21IYWV2cUxP
YVhhMlRyVk52L0dOclpxT3VLNi9Qc05mNHdQd1J0ekRqS3JEOQ0Kb0hZeGdWTmdWWTFRK1ZLd2Qy
NjZWbUxSdXZLOEUyTUZYN3dUakdXOEV3UmlJZEU0dzdGdHVXR0JhRkJ6Z0w4amFMSXpJZkF5YlNB
Zw0KYTBKUm9zQmxVM1ZLWXNEUmMyT3hiRVlsTUdNZndORXNZS0p3WjVFVEVHMXNUVFg4SUdmQXMz
TEROMHN4U21NN3d2R2hva2x2QURKUQ0KRklBME5IUEEwVkdnZEV3a0lNRFJMNEJ5Nm5uR0VURks0
M2pERVBVZ3V2TUh4elI3NEtSZ2RIQTZMeStuY0JCVDhDVFFjeTZ1UUdNVA0Kc0t1ZEFHb3dMcDJC
TDhtd1ppcHd5R1V2ZHpGZ1pDOFB3S2xndDhxVHd4QXc4RnhNOFhFd2R6OUE5akxGb2N2VGFDSEN3
TkhEUVd0QQ0KdjhXVHcwRnI4TTIyeFhYRFFXTEZnL1pubzVCVFFISlJ3YVFnTDhDaE1EOHNnS0VC
YWRDaE1ISnhhakJ1WW41cW9sQXlVR1N3dHhCcQ0KQWNJd2EvOVRJR1VBY05MU2NtRlVCMkNuUVVz
Z2oyakFVekhBWURIZ2MzbHpZVkRUeFdGSUlXeDVhTUIyd3hBeUFGUFVPRkhoWjJSaA0Ka0dFeUFt
YnYwaUc2ME1WUmNORjI4N0hXOFdEUTc4TVFFeEJUNEduUWNLY2djQ0RaRUgvMWNOaVJZUEJTSUty
Z01XQ3VNWGlmTWVBeA0KTUdqUXhWRXlBSE5oWlFEL1VhRFlNOGRCMjFIWkVjZEJjVEFUc0RjVVVC
TVFVckI0cHlESWNHOTU5VEpRWEdEUWNGUGdNWEFUOEZLdw0KNzZJaGNuQ2ljTkpBWkdqUU1aRDFJ
UHhpWkhNQVVyQ2ljWEFnWVZHSkFTZGhVbFBnbzlCbFhOa1FjbnJmMGlKMEFNMVNVYURoOFdqZw0K
TXlpUStkWHhaM2JpeWVHQnBFQlJvRXZSZitOQzVFVGo4OWtDMUJIalllWFRhcGZlSVJQZ3FwQjJM
MUIzYTI3eC95Y1E1ekp3RVBPdw0KcWZITWNjOWdkUkorWmFQUTZKVmhVRk13WWNIVmdIVC91NUJS
b09GZzBZSHFKNlJnSk5DamtQK2ljRktoeDJDa1lLUFJNWUdJOEMvQQ0KL3lyd21vREhZS2NCMzNK
dThhQnc2akQvNkNHaE1ER1FhZUhxSVRHQk1YQjBzWC9IWU1CeDRLSGhZRkt3d0hHaG9IRC83Skpn
c0UwQQ0KbzZDcVlsR2djQ0tuQVgrVXNjcFFjREN1a2RUQWNEQ2hrWER1Y0dZZ29UQ2lVV2tUNE8r
MllzTC9FN0JUTUw1MlVxQWdRREdCWXBLaQ0KSVAvNzBGS3dRc0JwMEtPQ3lsQ2lRR2FCLzlwUndi
QlRvR0ZSL1RDa0VGS2hidkgrYnNCaGFWRDZrSEF3NzZGd01MclErVktoWTNpaQ0KY0ZKQWhhRlNJ
RzhBdjk4QmxORDVrZDN4VXJCOEVHUEhjYi9za253UStZT2prRkdnY29Cbyt2UGI2ZkxJZ0dlaFl0
UlJZOWd3NjlOLw0KTVlEQWdQdXlMS0R1Y3Y0QzJEQjA4SGhpZUZ6djBLcndGRkJnd08raVFPZ2d5
T0hhMFd6dElTeUEzckcvS25DZGtXR1NxZUJnOEMveQ0KZDlkUjNHWnQvekNmTU5BQklNeFFTK0Qv
VXBLcDRHR1FHekFVY041Z1V6Q2hRUHMvTUZJZ2JHRlFKTkRvSU80d3gyRCtkVkpnbUpLaA0KWVdD
UjBKRm1zZEJWLzFIU1lOQXlBTkh4WmpCeE1PRmdCd1Avb2ZRR0VGT0EwWU5UWVNxd294RFFnZnhz
ZHRqUm94SEpjS05BQ29GUw0KUU84eGNBc0NidkhGVVRjUHdBcHhGRENmcDBCVFlhTVFBQUJTUUNB
dXVtVC9Db1lab0FzaW1LRUxqd3lmRGE4SzRIOGMwS01RU3pEUw0KUUE5L0VJOFJuMnkvSWZDakVK
Y1FEejhVRHhVVktRMzg3eWNRRXQ4WHp4VDFZaC9nSVhFWS8vOEtzeWl3RnA4YmJ4eC9IWThLMFh4
dw0KL3g3aUMyOGdUeUZmR1cyMUlCN3ZKSC8zSlk4bW53clJPU052S1E4cUh5c20vOHZCY2RETHdL
Y2c1VkNZZzZGaW9FLy9vVitpYjZOLw0KcEkrVzczeGZwNDkrZi8rcGY2cVBZQWkvQURiUE45QTQv
Sm9oQi9xQmFiQ01PVWtnWVcwZ3R6Q3haN0RsQVNESnNFRWdZM0FnQS9DZw0KMCtFZ1VrRkVVMFYr
UTB4aVBkOCs3ei8vUVNCdkFDRFBhcEN5a0MwUkJLQnpJQVpBMkhJK0lHdmdONEFDWURPQVFySkZX
S0JVSUZkSA0KSU1xaGEwRlEwOVJ4eVRBTkNqQWlJRW5sdWhETFZBQytNQ3hKNVUxVFF6OUVULzlG
WDczeUFSQXRNSXdxU2V3d0ZERGYvekhpY2JEbw0KWXR0d1V1T2FnRFN4Mk9IL05KTUZZREl2TXo4
MFR6VmZObUl3SXY4dE1JdzVTOTRGWUxQZm1VR20wazRDZnpoMXdFQTdKbDFTdHhBMw0KQURlQU5Q
ODZjSzVnWGxiZjRGNVRtWElhVU5wUTJ3Q0FzT0JtVGo5UFRTMWl2MlBQLzJSblM4L1hNRnMvWEU5
ZFgxNXZYMzkvWUk5aA0KbnpHQWFrOXJWR21qYWdFZy96R0NnbUJETDFzUE9ZUGY4R2ZmYU8vL2Fm
OXJEMndmYlM5MW4yOU53OUFFc0RQS1lKd3dJRlB6MEFFUg0KZWl6aHVnQkpVMU5RY0s5bWoyZWYv
M1AvZFE5MkgzY3ZlRDk1VDNwZmNCLy9jUzkrajMrZmdLK0ZyNExQZzkrRTc5K05QNGNKdWhEbg0K
UUVJQVV4cWdlNkg1dUdBZ1FUa3hTWUZVc0lndmZnLy9paytMWDR4dmpYK09qNCtma0srUnYvK0hu
NGl2bGYrWEQ1Z2ZuUithUDV0UA0KLzV4Ym4wK2dYM0ovb2wramI2Ui9wWStmcHArY2Y2My9ucGUv
Y0c5REJMQzUyNUFnVGdEQVNUSkNnbUtUc1A1SWZPK1ZiNkd2cSsrcw0KLzY0UHJ4Ly9zQyt4UDdK
UG52K3BIN2FmdDYrNHY3KzV6N3JmdSsrOC84VlB2eHBJNTFELzZFRDc0TE53MG9Fd1FjQlB0aS9D
Yi8vRA0KZjhTUHhaL0dyOGUveU0vSjM3Ky8vOERQelkvT244K3YxSy9SejlMZjArL1AzRC9XQ2VQ
ZzZIQWdSdlRCa3ZENzhoQkljRUlCNFBtUg0KTUVGOGdFbXc4aUQxSURReDF5L05EOWxQMmwvLzIy
L2NmOTJQM3Arb0g5ZXY1WS9tbjMvbnIraS82Yy9xMzk4ZjhoL1dDVkthYndxZw0KZHVLQlIrQkRR
WHlBd0RrMU56UTNMZU93K0xELzdRL2xEKzh2OEQveFQvSmY4Mi8wZi8vMWovYWYxcC90ai9yZisr
Lzgvd0gvWC84Zg0KQUM4QlB3bVBBMWs1cWdBdVlEYzROUzR4RHpBMmtGVDhaV3dFZi9wZkJwOEhy
d2kvQ2MvL0N0OEw3d3ovRGc4RDd3VC9FYzhTMy84VA0KN3hqdkZnOFhIeGd2SUg4T2p3K1I1amdh
RU9JZ1lYZ2JieEZQSFkvL0hwOGZyeUMvSWM4aTN5UHZKUDhhMy84Yjd5aS9LYzhxM3kvZg0KTFA4
dUR5OGZhemR2TVRsdGU1VXVVeUI4TTBEQWFIQXVZMjl0TWw4b1AvODBmeldQTnA4M3J6aS9PYzg2
M3p2di96SFBQd3hCMEVBTw0KUWRGQlAwSlBSMDhYUkc5aDhraGdOK093T0RRNGgwWW5VT1pKUUc5
aWFtSExVUDlXTUVrd1NiOUt6MHZmVE85Ti8wOFB0MFR2UmYvcw0KZUZ6MzRKUkFaRUFEQzF4aVNW
TjRQNUJsYm1SdWVYeFFjbVZjVkpNUWU1Q3FRR09pYkZ4UVpuUnVVcUFnVTBBWUtseHdXZ0NVTUd4
Mg0KYkVNellGL2dkV055YlYvU2RCM2pNSFJnWWtsd1hwQnVkRGQrTWorUVgrQlJnTFNSVTBCZjRI
VGllR0VnSUM1OVV6RmZ5RWZBdjJDQw0KcWtGZzcySC9ZdzlnUUROZjBmMWVrR05rejJYZlp1OWdR
RmFRWCtEdlU0QmtuMmx2YW5VcFkxeElrR2cvNDIwdmFsVmlJQ2hUTVc1Zg0KWUJPL1FSQnIvM0RQ
Y2Q5eTcyQXhOM1F6LzJEUGRhOTJ2MjdOVVZCMFQzbmZldS83ZS85Z01UbDR6MzV2ZjMrQWlES1Bm
ei9QUU45Vw0KbjFldldMOVp6MXJmTGYrT0w0OC9qOWVGZjRlaHFrcUlMNGsvejRwUGkxK01iMGFK
RFFwZjBPTXcrMXd4bVJGa1g5Q1RJRWx3aHZPWg0KRVhoY2NXeEpRaitRUFVBL2tIY0xScEJjZ0d5
YVluZHlZWEQ3WHBVL1lIT1pFSnV3VVlDY3NtQ1FKNEl3WHJBOUlIUnZQMkJrYW1aMQ0KZ25BOVFH
ZG9YVEE5UUc3cmt3R2ZBbW1DZ0hCdG9lTXc0ekQvUm9wVGJFaFNlTEJVWWtmQW5QQ1ROTDhtMElj
TVNGS0lBS0pUa3lReg0KYUJCems3YWxNV05uUFVDWm9KTWlidjV3cFJtbXRGK1JvUStpRUpJUGt4
Ly9rM0tWcjVhL2w4K1kzSm9mbXkrY1AvK2RUNTVmbjJhbg0KNzZqL3FnU3MvSmpYVzEraXFtQjBn
ekdDY0huTE1ITXBTVkJ6WklKd2FUMFFlREtPTm5pd3VvR1VZV3RsWkY2UjQ2cEJ1cEZsYlduaQ0K
Y0x2Umd4SGJobkc2Z1hWZDhFYVFaYlFBdThQeHZUTnhabStDSUZMQXUrWlFFTTg5Y0QxQXVpQmVr
VGs1a1BDN1YvRmRnR05sY010Zw0KdkN5UjhyMXFmOEprdnFYc2dyOTR3bVM3aE9JUVRubSt3bXc3
d1kvQ244T3Z2N1E1MzhVclBlQ3owRWx3YmhBeHhsUElyN3ZKdjhySA0KTXN0dnpIL0tmRFBPZjd2
UGo4cDhOTkdQMHAvS2ZEWFVuN3ZWcjhwOE50ZXYyTC9LZkRmYXY3dmJ6OHA4T04zUDN0L0tmRG5H
VSsyLw0KbGpQaWZMT2dZOHRGNUQvbFNQL09aT1pQNVVqUmRPaGY1VWpVaE9wdi8rVkkxNVRzZitW
STJxVHVqK1ZJM2JULzhKL2xTT0RFOHEvbA0KU09QVTRTLzA4NXVqSXNWWVk3SEF1c0J2YnNaZjM4
ZHY5cCsvcFEvUnhUcFVuNUM2UUpmMGE4UTB4WFpFWHFRZ1VLQUIxNllnc2NCVA0KQUViNVVIVDVm
L3FQeC91Zi9LYi9MRk4xWXJyQS9pYi9BYjhDendQZnVpQ2ljQVVzaHlENVVENW5CbjhIandpZkNh
YkZIRVZ0dTdLeA0KUm9CekMyOE1mNzlwTmVKOHlGUmhZcnBBSUVlbU1SQnpHd3kreFhaUXFtREJN
R2h2YlB0ZWtKa3dWRjJBQVY4UmZ3MS8vcTkveGFVRg0KNEprUVBXQUxUeGlmeEVzMi9jVWNUTFJD
QmVCUmdNc0NITThkMy84ZTZ2OHNJSVFnZ0lKd0lWOGlieDdxL3dvc0lJUVVseVlQSng4Zg0KTmFm
UXhUcjZUYnZBYWJNd0lOYkxSU3B2SzMvL0h6VlVvaTAvTGtiT1pDOHZNRDhmTmYvNExDM1ZKWEl1
dnpTUEhzeUc0amEvL3pmRA0KTTQ4NUx4N2J0dEk3VHhTU09BLy9QYThlekZKaFA4OUExRHl2UWs4
ZTI3L2lmRUI2MFhSR0wwYy92N1EzeFJ4NlJKbUFheVZ2U3k5TQ0KUC84c1Evc1hBTDdBWnJJZ0lO
OVBUMUJmVFJIL0tKeFNkMDUvVkU5TVRpejhVbmNwMzQ5WTN4NnZLSzhneHlCQlk4RXcvNE5BUVM5
ZA0KanlOZlg2ODN3MkUvWWsvL1kxOG9ieWw0Wmg5bkwyZy9MTDh0ei85ckQyd2ZiUzh4ZnpLUGNG
OXhiM0ovSHpZL04weDFyQlV2eFlWUw0KWlhiL0VGRDVUM2NmR1ovMG1YUE1OOE1BaHg5OXIzNi9m
ODhKcGtpOFVYVnZ2N25RZ3grRUw0VS85TVpOVEVrQlFQK25jSHdRaDUrSQ0KcjNmL092ODhDWFd2
LzQzZmp1OC9YMEJza2UrUy81UVBRKy8vUlB5WEQ1Z2ZtUzlJZjBtTW5DK2RQLytlVDAwUFRoaWhU
NkpmbzI5Ug0KWDFKdi82WXZweitvVDFZZlZ5eXJmNnlQclovL1dxOWJ2TENmc2EreXYxOC9ZRSsx
NC85Rno3ZFBZODlrMzdCcHUxKzhiMmkvLzJuUA0KdFluQVQ4RmZiYStmMzIvUHhULy94azl5Lzho
dmRSL0tqOHVmZUUvTnYvOTZiTS9mME8rUGI5TVBrWXpVLzlZUC81U1AyQytXck5vZg0KMnkrWnI5
MVBtOHovM3ovZ1Q1N1A0bStnN09SZjVXK2o3LytrLzcrdjZlL3EvNmsvcWsrNnYrN1AvKy9mcm8r
dm4vTS85RS8xWDdQZg0KdE8vLytJLzVuK1kvdVMrNlAwcFAvdSs5Yi84QkQ3QmFBdzhFSDhKdncz
KzFpUWYvL3drUHgxL25qOGwvRE84Ti84eXZFQi8venM4Uw0KUHhOUDBmOFZiM3BzRjQ4WW4vL1hI
eHEva1l3Y3J4Mi8zRDhmMzVhcy95SFBJdC9oWHlUL204d203eWYvNW4vL0toK2c3Q3dQTFIvcg0K
bit5dkIxOHhuLzh5ci9EdjhmOENielovTjQvMlAvZFAvenJ2Ty84OUQvdVAvSjlBUDBGUExlL3pB
TjhCN3lBMFJhOUd2d1UvQmsvLw0Kc0hoS3YwdlBDaDhMTDdXSlQ2OVF2LzhQRHk4L0VTOVVuMVd2
RkY5WHp4Wi8vMW52V3Y4WnIxMGZlbXhmUDJCUEhzLy9ZbStSakdSZg0KWlc4ajcyZVBscXhwZi85
cWp5a1BiSytiekc2ZmI2OHVMM0hQLzZEc2M3OTB6ek5QTkY5UEQzbFBlbC8vT0o4NXIwb2ZmaTkv
UHozdg0KUHYrQ24vK0RyNFMvUXo5RVQ0ZnZpUDkxbjBpUCtVbWZJRFdOWDQ1dlRPOU4vN0I0LzVK
dmszOVJ6MUxmdFltWFg1aHZWci8vZHU5WQ0KMzV4UG5WOWNENTkvWGkraG4vK2lyMkZmcE0vVUhL
YnZwLzltZjZvZi85azhyQSt0SDJ1ZnJ6L2VYTEV2c2ovL2NMKzBYK044dGsrMw0KWDNYZnVYL29u
UCs3Yjd4L2V2OThENWEvd1AvQ0Q0QlAvNEZma2MvRjM4YnZoWitHcjhwUHkxLy96RytLNzR2L3o1
L1FyNzFQa0QrUg0KVC93Z050VVAxaCtVbjVXditDamFILy9iTDVsL21vLzlPZDhQNEIrZWI3NmYv
NkNQNC8vbEQ2Ty81eStsMytsUDZsLy9xUS9zZnh2TQ0KN3AvdnI2NHY4YzhnN1AvenYvVFBzMC8y
N3lZTStOLzU3N2h2Ly93UEt5ejkvLzhQdlk4Qkx6Qk1BeC8vQkMvQ3I4Ty8zbThJcndtLw0KeC8v
SkQvL1pmdzJQRHAvTlQ4NWZFZjhURHhRZm45S2YwNjhYVHhoZkJQWnhaaFpnV0cxaGRCQUUxMVl4
Qmd4VEFIVmlkR3hsSUVWdA0KK25CWTRITmpnQnkvSGM4ZTM5ZGwraklRREVsRllFVlFHVkFocnlL
L0d5UFBIMTR6RUF3aFJWSmxadnhsY2tWUVJVQW56eWpmS2U4cQ0KOW4vaC9DYkdMTTh0M3k3dkwv
OGFmRUwwYjI5ODBGVFhvQ0dBTXZNcTV5SDd6RUpwWW16WGNHZHllbUVuWUhreTh6VlBLeU1HREZR
Zw0KVDBNZ1NHVlk4enQ5d0gxN1hDcGNaQjlRSjRBR2RCWmdKeUF3TVRBMU1DMC9NakkvTXo3d09E
K1VOR1NCR21BM09EWmtObU13OEFBeQ0KWlRVek5ERTFPTU5Ca0VCd05HTTFNdkZ3M1BEdjdDRHhj
QlZBUVRBelFoQkM0RCtVRDBPZTE5QS9NZGJnWTJZeE1TQmxNR0V4WWtVdw0KWVdYM1B3QkYvMGJz
TTBWUVI5RS9NREtBOEdabU1EbEVka2xQUDlGS0hmOUovVWh5VEpKSmRreCtUUGRPLzFBUC8xRWZV
aTlUUDFSUA0KVlY5V2IxZC9XSS8vV1o5YXIxdS9YTTlkMzE3dlgvOWhELzlpSDJNdlpEOWxUMlpm
WjI5b2YybVAvMnFmYTY5c3YyM1BidDl2NzNELw0KY2cvL2N4OTBMM1UvZGs5M1gzaHZlWDk2ai85
N24zeXZmYjkrejMvZmdPK0IvNE1QL1lQOFpJUDFUSVdGNzRiL2lBK0pILytLTDRzLw0KakUrTlg0
NXZqMytRajVHZi81S3ZrNytVejVYZmx1K1gvNWtQbWgvL215K2NQNTFQbmwrZmI2Qi9vWStpbi8r
anI2Uy9wYyttMzZmdg0KcVArcUQ2c2YvNnd2clQrdVQ2OWZzRyt4ZjdLUHM1Ly90SysxdjdiUHQ5
KzQ3N24vdXcrOEgvKzlMNzQvdjAvQVg4RnZ3bi9EajB5VA0KVDBJUVJJRk00Y1V5TnpRL1pEVDlQ
eUUyU0FIRnNoVkF4WkZJd3NkLy84aVB5Wi9Lcjh1L1A5RkVvajhodys5RmhSWmpCZkJrT1RqUA0K
VUdLdHozQXpRZUZCb0RrOWdHWkE4SHBrUVlGaVJWQk43OUZtU01BeTFjOEFZVUV3WWMrQVljL2dQ
dkQvVFgvVWY5V1AxcC9YcjlpLw0KMmMvYTMvL2I3MDZQM2V6Y2I5Ly80US9pSCtNdi8rUS81VS9t
WCtkdjZIL3BqK3FmNjYvLzNNL3R6OTd2Nysvdy8vSVA4eC8wTC8vMQ0KUC9aUDkxLzRiL2wvK28v
N24reS8vLzIvN3QvLzN3RHZBZjhERDBzK1B5UUxBL1U5OEFBR0lBQUFIZ0J3QUFFQUFBQkZBQUFB
VWtVNg0KSUZKQlJFVllWQ0JYUnlCRGIyNXpaVzV6ZFhNZ1kyRnNiQ0J2YmlCaFkyTmxjSFJoYm1O
bElHOW1JRkpCUkZORlF5QmhjeUJoSUhkdg0KY21zZ2FYUmxiU0FBQUFBQUFnRnhBQUVBQUFBV0FB
QUFBY2lLcXk1Mm54TTBpTGU2UzZ5WHlnV1ZjdlRta3dBQUF3QW1BQUFBQUFBTA0KQUFJQUFRQWdB
QXNBS1FBQUFEWUFDd0FCRGdBQU1RQUNBUW9PQVFBQUFDNEFBQUFBQUFBQWRDU3QrV1dtTUUyVHEr
RmhGMzNpM3dFQQ0KMXRVVlU1clFnRWEzNXFUQUxuSmlQZ0FBQUJrMDB3QUFBQUFEQUFKWkFBQVdB
QU1BQ1ZrREFBQUFBd0RlUDU5T0FBQWVBQ2dPQVFBQQ0KQUZVQUFBQXdNREF3TURBd013RkhObGN3
TWpZNUwwODlRMDlOVUVGUkwwOVZQVlJFVFM5amJqMVNaV05wY0dsbGJuUnpMMk51UFdGdA0KTFRN
M01qSTNBVTFwWTNKdmMyOW1kQ0JGZUdOb1lXNW5aU0JUWlhKMlpYSUFBQUFBSGdBcERnRUFBQUJW
QUFBQU1EQXdNREF3TURNQg0KUnpaWE1ESTJPUzlQUFVOUFRWQkJVUzlQVlQxVVJFMHZZMjQ5VW1W
amFYQnBaVzUwY3k5amJqMWhiUzB6TnpJeU53Rk5hV055YjNOdg0KWm5RZ1JYaGphR0Z1WjJVZ1Uy
VnlkbVZ5QUFBQUFBTUE4VDhKQkFBQUFnRi9BQUVBQUFBUkFBQUFOakF4UVRrNE1rVkJRamhCUXpn
dw0KTVFBQUFBQURBQVlRWlZKN1V3TUFCeEJYQVFBQUF3QVFFQUFBQUFBREFCRVFBQUFBQUI0QUNC
QUJBQUFBWlFBQUFFbEJUVWxPUmtGVw0KVDFKUFJrRkRRMFZRVkVsT1IxSkJSRk5GUTBGT1JGUklS
Vk5VUVZSVlUxVlFSRUZVUlVSU1FVWlVRVk5TUVVSRldGUlhSMWRQVWt0Sg0KVkVWTlUwTklSVVZT
VXl4TlV5MHRMUzB0TFMwdExTMHRMUzB0TFMwdExTMHRMUzBBQUFBQU9FNENBcEFHQUE0QUFBQURB
SHNCQUFELw0KLy8vL0FBQUFBSHNFQWhDQUFRQVVBQUFBVlc1MGFYUnNaV1FnUVhSMFlXTm9iV1Z1
ZEFCeUJ3SVRnQU1BRGdBQUFOZ0hBd0FVQUFrQQ0KTndBVUFBUUFUZ0VDRVlBR0FMZ05BQUFCQUFr
QUFBUGNCZ0FBQUFBaEJnQUFBQUFGQUFBQUNRSUFBQUFBQlFBQUFBRUMvLy8vQUtVQQ0KQUFCQkM4
WUFpQUFnQUNBQUFBQUFBQ0FBSUFBQUFBQUFLQUFBQUNBQUFBQkFBQUFBQVFBQkFBQUFBQUFBQVFB
QUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFELy8vOEFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0K
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFEZ0FBQUg0QUFBQitBQUFBZmdB
QUFINEFBQUIrQUFBQWZnQUFBSA0KNEFBQUIrQUFBQWZnQUFBSDRBQUFCK0FBQUFmZ0FBQUg0QUFB
QitBQUFBZmdBQUFINEFBQUIrQUFBQWZnQUFBSDRBQUFCK0FBQUFmZw0KQUFBSDRBQUFCK0FBQUFm
Z0FBQUg0QUFBQitBQUFBL2dBQUFmNEFBQVArQUFBSC9nQUFELzRBQUIveUVHQUFCQkMwWUFaZ0Fn
QUNBQQ0KQUFBQUFDQUFJQUFBQUFBQUtBQUFBQ0FBQUFBZ0FBQUFBUUFZQUFBQUFBQUFEQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFGVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZW
VlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWVg0KVlZWVlZWVlZW
VlZWVlZWVlZWVlZWVlZWVlZWVlZWVlZWUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBSWFHaHRibjU4
ek16TXpNek16TQ0Kek16TXpNek16TXpNek16TXpNek16TXpNek16TXpNek16TXpNek16TXpNek16
TXpNek16TXpNek16TXpNek16TXpNek16TXpNek16TQ0Kek16TXpGVlZWUUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBSWFHaHRibjUvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy84ek16RlZW
VlFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBSWFHaHRibjUvLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy84ek16RlZWVlFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUlhR2h0Ym41Ly8vLy8v
Lw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy84ek16RlZWVlFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUlhR2h0Ym41Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vOHpNekZWVlZRQUFB
QUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUlhR2h0Ym41Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vOHpNekZWVlZRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFJYUdodGJuNS8vLw0KLy8vLy93
d01EQXdNREF3TURBd01EQXdNREF3TURBd01EQXdNREF3TURBd01EQXdNREF3TURBd01EQXdNREF3
TURBd01EQXdNREF3TQ0KRFAvLy8vLy8vOHpNekZWVlZRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFJ
YUdodGJuNS8vLy8vLy8vNGFHaHN6TXpNek16TXpNek16TQ0Kek16TXpNek16TXpNek16TXpNek16
TXpNek16TXpNek16TXpNek16TXpNek16TXpNekF3TURQLy8vLy8vLzh6TXpGVlZWUUFBQUFBQQ0K
QUFBQUFBQUFBQUFBQUFBQUFJYUdodGJuNS8vLy8vLy8vNGFHaHRibjU5Ym41OWJuNTlibjU5Ym41
OWJuNTlibjU5Ym41OWJuNTlibg0KNTlibjU5Ym41OWJuNTlibjU5Ym41OHpNekF3TURQLy8vLy8v
Lzh6TXpFMU5UUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBSWFHaHRibg0KNS8vLy8vLy8vNGFHaHRi
bjUvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vOWJu
NTh6TQ0KekF3TURQLy8vLy8vLzh6TXpGVlZWUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBSWFHaHRi
bjUvLy8vLy8vLzRhR2h0Ym41Ly8vLzRhRw0KaG9hR2hvYUdodi8vLzRhR2hvYUdob2FHaHYvLy80
YUdob2FHaG9hR2h2Ly8vOWJuNTh6TXpBd01EUC8vLy8vLy84ek16RlZWVlFBQQ0KQUFBQUFBQUFB
QUFBQUFBQUFBQUFBSWFHaHRibjUvLy8vLy8vLzRhR2h0Ym41Ly8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vOWJuNTh6TXpBd01EUC8vLy8vLy84ek16
RlZWVlFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUlhRw0KaHRibjUvLy8vLy8vLzRhR2h0Ym41Ly8v
Lzh6TXpBQUFnUC8vLy8vLy84ek16SUFBZ0lBQWdQLy8vd0NBQUFDQUFBQ0FBUC8vLzlibg0KNTh6
TXpBd01EUC8vLy8vLy84ek16RlZWVlFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUlhR2h0Ym41Ly8v
Ly8vLy80YUdodGJuNS8vLw0KL3dBQWdBQUEvd0FBZ1AvLy8vOEFBUDhBQU16TXpQLy8vd0NBQUFE
L0FQOEFBUC8vLzlibjU4ek16QXdNRFAvLy8vLy8vOHpNekZWVg0KVlFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUlhR2h0Ym41Ly8vLy8vLy80YUdodGJuNS8vLy93QUEvd0QvL3dBQWdQLy8vLy8vQVA4
QQ0KQVA4QUFQLy8vLy8vL3dDQUFBQ0FBUC8vLzlibjU4ek16QXdNRFAvLy8vLy8vOHpNekZWVlZR
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUlhR2h0Ym41Ly8vLy8vLy80YUdodGJuNS8vLy8vLy8v
d0FBL3dBQWdQLy8vLzhBQVAvLy8vLy8vLy8vLy8vLy93Q0FBUC8vLy8vLw0KLzlibjU4ek16QXdN
RFAvLy8vLy8vOHpNekZWVlZRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFJYUdodGJuNS8vLy8vLy8v
NGFHaHRibg0KNS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy85Ym41OHpNekF3TURQLy8vLy8vLzh6TQ0KekZWVlZRQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFJYUdodGJuNS8vLy8vLy8vNGFHaHRibjUvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy85Ym41OHpNekF3TURQLy8vLy8vLzh6TXpGVlZWUUFBQUFB
QUFBQUFBQUFBQUFBQQ0KQUFBQUFJYUdodGJuNS8vLy8vLy8vNGFHaHRibjU5Ym41OWJuNTlibjU5
Ym41OWJuNTlibjU5Ym41OWJuNTlibjU5Ym41OWJuNTlibg0KNTlibjU5Ym41OHpNekF3TURQLy8v
Ly8vLzh6TXpGVlZWUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBSWFHaHRibjUvLy8vLy8vLzRhRw0K
aHN6TXpNek16TXpNek16TXpNek16TXpNek16TXpNek16TXpNek16TXpNek16TXpNek16TXpNek16
TXpNek16TXpBd01EUC8vLy8vLw0KLzh6TXpGVlZWUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBSWFH
aHRibjUvLy8vLy8vLzRhR2hqT1p6SmtBQUprQUFKa0FBSmtBQUprQQ0KQUprQUFKa0FBSmtBQUpr
QUFJQUFBSUFBQUlBQUFJQUFBSUFBQUlBQUFBd01EUC8vLzlibjU4ek16RlZWVlFBQUFBQUFBQUFB
QUFBQQ0KQUFBQUFBQUFBSWFHaHRibjUvLy8vLy8vLzRhR2hqUE0vNWtBQUprQUFKa0FBSmtBQUpr
QUFKa0FBSmtBQUprQUFKa0FBUC8vLzRBQQ0KQVAvLy80QUFBUC8vLzRBQUFBd01ETmJuNTh6TXpK
bVptVlZWVlFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUlhR2h0Ym41Ly8vLy8vLw0KLzRhR2hvYUdo
b2FHaG9hR2hvYUdob2FHaG9hR2hvYUdob2FHaG9hR2hvYUdob2FHaG9hR2hvYUdob2FHaG9hR2hv
YUdoZ3dNRE16TQ0KekptWm1YZDNkMVZWVlFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUlhR2h0Ym41
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy85Ym41OHpNekptWm1YZDNkM2QzZDFWVlZRQUFBQUFBQUFBQQ0KQUFB
QUFBQUFBQUFBQUlhR2h0Ym41Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLzVtWm1VMU5UVTFOVFRNek16TXpNek16TXpN
ek13QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFJYUdodGJuNS8vLw0KLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy81bVptZi8vLy8v
Lw0KLzlibjU4ek16RlZWVlFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFJYUdodGJuNS8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy81bVptZi8vLzlibjU4ek16RlZWVlFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFB
QUFBQUFJYUdodGJuNS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy81bVptZGJuNTh6TXpGVlZWUUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBSWFHaHRibg0KNS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vNW1abWN6TQ0KekZWVlZR
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBSWFHaHRibjU5Ym41OWJuNTli
bjU5Ym41OWJuNTlibg0KNTlibjU5Ym41OWJuNTlibjU5Ym41OWJuNTlibjU5Ym41OWJuNTlibjU5
Ym41NW1abVZWVlZRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFB
SWFHaG9hR2hvYUdob2FHaG9hR2hvYUdob2FHaG9hR2hvYUdob2FHaG9hR2hvYUdob2FHaG9hRw0K
aG9hR2hvYUdob2FHaG9hR2hvYUdocG1abVFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFNQUFBQUFBQ0ZmQWdXUQ0KQmdEY3VnQUFFQUFBQUFNQUlRNEFBQUFBQXdEK0R3Y0FBQUFE
QUFVM0JnQUFBQU1BQ3pkN0FRQUFBd0FOTkhrT0JBQU5BQUUzQVFBQQ0KQUJDNkFBQUxBQUFBQUFB
QUFNQUFBQUFBQUFCRzBNOFI0S0d4R3VFQUFBQUFBQUFBQUFBQUFBQUFBQUFBUGdBREFQNy9DUUFH
QUFBQQ0KQUFBQUFBQUFBQUFCQUFBQUFRQUFBQUFBQUFBQUVBQUFBZ0FBQUFFQUFBRCsvLy8vQUFB
QUFBQUFBQUQvLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Lw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vOS8vLy8vdi8vLy83Ly8vLysvLy8vQlFBQUFB
WUFBQUFIQUFBQUNBQUFBQWtBQUFBSw0KQUFBQUN3QUFBQXdBQUFBTkFBQUFEZ0FBQUE4QUFBQVFB
QUFBRVFBQUFCSUFBQUFUQUFBQUZBQUFBQlVBQUFBV0FBQUFGd0FBQUJnQQ0KQUFBWkFBQUFHZ0FB
QUJzQUFBQWNBQUFBSFFBQUFCNEFBQUFmQUFBQUlBQUFBQ0VBQUFBaUFBQUFJd0FBQUNRQUFBQWxB
QUFBSmdBQQ0KQUNjQUFBQW9BQUFBS1FBQUFDb0FBQUFyQUFBQUxBQUFBQzBBQUFBdUFBQUFMd0FB
QURBQUFBQXhBQUFBTWdBQUFETUFBQUEwQUFBQQ0KTlFBQUFEWUFBQUEzQUFBQU9BQUFBRGtBQUFB
NkFBQUFPd0FBQUR3QUFBQTlBQUFBUGdBQUFEOEFBQUJBQUFBQVFRQUFBRUlBQUFCRA0KQUFBQVJB
QUFBRVVBQUFCR0FBQUFSd0FBQUVnQUFBQkpBQUFBU2dBQUFFc0FBQUJNQUFBQVRRQUFBRTRBQUFC
UEFBQUFVQUFBQUZFQQ0KQUFCU0FBQUFVd0FBQUZRQUFBQlZBQUFBVmdBQUFGY0FBQUJZQUFBQVdR
QUFBRm9BQUFCYkFBQUEvdi8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0K
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLzFJQWJ3QnZBSFFB
SUFCRkFHNEFkQUJ5QUhrQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFXQUFVQS8vLy8vLy8vLy84Q0FBQUFGZ01BQUFBQUFBREFBQUFB
QUFBQQ0KUmdBQUFBQUFBQUFBQUFBQUFPQTBuaTZyaXNnQkF3QUFBSUFBQUFBQUFBQUFBUUJQQUd3
QVpRQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBb0FBZ0QvLy8vLy8vLy8vLy8vLy84QQ0KQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUZBQUFBQUFBQUFCREFF
OEFUZ0JVQUVVQQ0KVGdCVUFGTUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBRWdBQw0KQVFFQUFBQURBQUFBLy8vLy93QUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUUFBQUMycndBQQ0KQUFB
QUFBTUFUUUJoQUdrQWJBQlRBSFFBY2dCbEFHRUFiUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBWUFBSUEvLy8vLy8vLy8vLy8vLy8vQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBUUFBQUF3QUFB
QUFBQUFBL3YvLy8vNy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Lw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0KLy8vLy8vLy8vLy8vLy8vLy8vLy8v
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0K
Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLzhCQUFBQ0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUUFB
QU9JT0FBQVFDQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBRUpOdHE4QUFBQUFBQUEyQUFB
QUtBQUFBSkFBQUFCT0FBQUFBUUFnQUFBQUFBQ0Fyd0FBeEE0QQ0KQU1RT0FBQUFBQUFBQUFBQUFQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBOWYvL0FQNy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vd0EvLy8vQVAvLzhBRC8vdmdBLy9Yc0FQLy8vd0QvLy9VQS8vLy9BUC8vL3dELw0KLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0K
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0RrejdRQXpydU5B
UC8vM1FELy8vTUEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
Lw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUFQvL3dELy8vOEEvLy8yQVAvLytBREZxVjBBcVlRMUFPbkRjZ0QvLzhv
QS8vLytBUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0K
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVA3Lw0KL3dELy8vOEEvLy8vQVAvLzlRRC8vLzRB
Ly8vL0FQLy8vd0QwLy84QS8vLy9BUC8vOVFEKzQ1d0F6YXRWQUxLUU13RFNyR0FBLy8vZA0KQVAv
Ly9BRC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Lw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QQ0KLy8vL0FQYi8vd0QrLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy9FQS8vL0tBTGloWHdDaw0KZ1RZQTZMZGVBUC8veGdELy8vMEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0K
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QrLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RCsvdjhBLy8vMw0KQVAvL3lRRFB0MndBd1pNM0FOQ2pUUUQvLzlFQS8vL3VBUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Lw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RDIvLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dEMQ0K
OWZVQS8vLy9BUC8vOXdELy85RUE0TGg0QUxlTk9nRGpzMlVBLysrb0FQLy82Z0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84
QS8vLy9BUC8vL3dELy8vOEEvLzcvQVAvKy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vUUQ1OWVr
QStmWG5BUC8vOEFELy8vMEEvLy8rQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy9VQS8vL2pBTm01ZVFDdWhpOEEyTFppQVB2eXR3RC8vL0FBLy8vL0FQLy8vd0QvLy84
QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vbi9BUC84L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0K
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLzVRRFByWDRBeFoxbUFQWG9v
UUQvK3M4QS8vL3BBUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzRB
Ly8vOUFQLy82Z0RheFhzQXRaTS9BTU9lVWdEODc3VUEvLy92QVAvLw0KL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvZi8vQVA3Lw0KL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vN0FEUHU0SUFySXcvQUxxV1BRRHB3RzBBK3ZP
dA0KQVAvNzZ3RC8vLzhBLy8vL0FQLy8vd0QvL1A4QS8vLy9BUC8vL3dELy8vY0EvLy8vQVAvLytR
RC8vK0FBOU42WUFNZVlUd0RJa2s0QQ0KK3QrckFQLy82d0QvLy84QS8vLytBUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0K
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QQ0KK1AvL0FQMy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8rUUQ0OWMwQTQ5S1NBTk8zWGdDNw0Ka1RRQXpxQkhBUFBKaGdE
NDg5QUEvLy8wQVAvLy9RRC85djhBLy8vL0FQLy8vd0QvLy84QS8vLytBUC8vK0FELy8vVUEvLy9u
QVBMTw0KbVFETW1FMEF6WlpSQVBuZG1BRC8vdU1BLy8vNUFQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Lw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzBBLy8vOUFQLy8vUUQvLy84QS8vLy9BUC8vL3dEOC8v
OEEvLy8vQVAvLy93RC8vL2tBLy8veA0KQVAvOXpRRHIxSTBBeDZGSUFMK1VTQUROcFZrQTh1U3RB
UDc0MHdELy8vd0EvLy8vQVAvLy9RRC8vLzBBLy8vL0FQNysvd0Q4L1A4QQ0KLy8vN0FQLy83d0Qv
M3FrQTI2SmVBTWVWU3dEejFKZ0EvLy9rQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS92LytB
UHovL0FELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0K
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vZ0EvLy8xQVAvLzlRRC8vL2tBLy8vL0FQLy8vd0Q0Ly84QSsvLy9BUC8v
L3dELw0KLy84QS8vLzdBUC8vL3dELy8rd0EvL0M3QU4zR2Z3REduMHNBdUpNOEFObStkQUR3N0xr
QS8vbnBBUC8vOXdELy8va0EvLy8vQVA3Kw0KL3dENCtQOEEvLy8vQVAvLyt3RC8vL0VBLytXekFN
eWpZQUM4bkZFQTU5YVVBUC85NFFELy8vMEEvLy8vQVAvLy93RC8vLzhBL2YvOQ0KQVBuLytRRC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Lw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vK0FQLysr
UUQvKytZQS8vL2xBUC8vNXdELy8rMEEvLy82QVAvLy93RDkvLzhBK1AvLw0KQVB2Ly93RCsvLzhB
Ly8vL0FQLy8vd0QvLy8wQS8vLzNBUC8vNEFENzY3QUF6YTlyQUs2VlNnQzFrMHNBN011TEFQLzJ6
Z0QvLyt3QQ0KLy8vOEFQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8yQVAvbnVRRFVzM0lB
cnBCRUFPblJrd0QvKzlVQS8vLytBUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0K
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy80QVAzejJnRGN5WnNBM2My
VkFPemlxQUQ2OGNnQS8vL21BUC8vK3dENQ0KLy84QS8vLytBUGovL3dEKy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vZ0QvLy9rQS8vYlZBT2ZYbndES3Bsb0F6cDFIQU9Ddg0KWUFEcjJaa0Ev
L2JZQVAvLy9RRC8vL3dBLy8vOUFQLy8vd0QvLy84QS8vLy9BUC8vL0FEKzdjRUEwN2x3QU1XV1J3
RG94b0VBLy9qVA0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLzNBUHowMXdDMG0yTUFwSWxEQUx1ZFV3RFJz
bU1BNWRlSw0KQVBicXRBRDc4TXNBLy8vbkFQLy8rZ0QvLy84QS8vLytBUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBKy8vL0FQLy85QUQvL3MwQQ0KNjhxS0FNZVlVUUM4a1VrQTVibCtBUExwdHdE
Ly8rRUEvLy8wQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy9nQS8vM1hBTmkyY1FERA0KbDB3QTNi
NTJBUC80ekFELy8vc0Evdi85QVB6Ly9BRCsvLzhBL1AvL0FQLy8vUUQvLy93QS8vLy9BUC8vL3dE
Ly9mMEEvL3o4QVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0K
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RDcvLzhBL3YvOUFQLy84d0RsMmJJQTJjeUZBTmk4YlFERw0KbzBrQXc1c3RB
Tk9xUXdEYnVsWUE0dGVMQU8vbHZRRDI3OWdBLy8vckFQLy8rZ0QvLy84QS8vLzlBUC8vL3dELy8v
OEErUC8vQVAvLw0KL3dELy8vc0EvLy90QVBua3ZRRGF5SDBBMEo5UUFMK2JUUURqMVlzQTh1M0JB
UC8vOGdELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vOA0KQVAvNjJRRGp4NFFBd3AxRUFOdThhZ0Q1
OU1ZQS8vLzVBUG4rL0FENi9Qd0ErLy8vQVAvLy9BRC8vL3NBLy8vL0FQLy8vd0QvL1B3QQ0KLy92
N0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
Lw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy9RRC8vL3NBLy8vN0FQLy8vZ0QvLy84QS8vLy9BUC8v
L3dENi8vOEEvZi8vQVAvLy9nRC8vL1VBLy8vZQ0KQVAvNnpBRDQ1ckFBNjlDQUFOdTNYZ0RKcVZV
QXVKMUpBTDZlVmdETnNtd0E0OCtMQVBibnRnRC8rZGNBLy8vckFQLy85Z0QvLy8wQQ0KLy8vOUFQ
Ly8vd0QvLy84QS8vLzVBUC8vOVFELy8rRUErT1N0QU0rOGVRQ3dtRTRBdmFsZ0FPSGNsZ0QvK05N
QS8vLy9BUC8vL3dELw0KL3Y4QS8vdi9BUC8vK3dELy85a0E2ZE9IQUx5Y1N3RE10V1VBOSsvRkFQ
Ly8rZ0Q3Ky93QS8vLzhBUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0K
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8v
d0QvLy84QS8vLzlBUC8vK0FELy8vWUEvLy80QVAvLyt3RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELw0KLy9rQSsvLzFBUDcvOWdELy8vZ0EvLy9qQVAvMHl3RHMzNzRBNHRXZEFOYkJi
d0RSc2s4QXdwMCtBTWVpVGdEWXVXZ0E0dE9TQVBmbQ0Kc3dELzg5QUEvLy93QVAvLytnRC8vLzhB
Ly8vNEFQLy85d0QvLy84QS8vLzVBUC8vNGdEZDA2UUF6YkZvQUx1bFJnRFh1VzRBOGQ3Qg0KQVAv
Mzh3RC8vLzhBLy9yK0FQLy8vd0QvLy9NQS8vN2ZBT1hWbkFDOHBFb0F4cXhsQVBYbnhRRC8vLzBB
Ly8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Lw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vZlVBL1BY
YUFQMzF6Z0QvLzlRQS8vL2dBUC8vN1FELy8vZ0EvLy8vQVAvLy9BRC8vL29BLy8vLw0KQVAvLy93
RC8vLzhBOXYvOEFQei8vd0QvLy8wQS8vLytBUC8vL1FELy8vb0EvLy93QVAvLzF3RDg4Ym9BNk5p
ZUFOaS9ld0RDbzFvQQ0Kdkp4TkFNZW1XQURRcm1VQTROQ1VBUGJxdUFELy90a0EvLy8wQVAvLytR
RC8vL3NBLy8vL0FQLy8rZ0QvLy9ZQS8vYlRBT2ZVa2dERQ0KbmwwQXhKbFZBTisraXdEdzdNb0Ev
Ly92QVAvLy9BRC8vL2dBLy8vN0FQLy84QURyM3FrQXhLRmRBTXl0WndEMTZyd0EvLy8yQVAvLw0K
K3dELy8vMEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dEOCtOMEExOG1YQU15MGJ3RFl3
M0VBM002REFOak9sZ0RmM3I0QStmdnlBUC8rNGdEKw0KODg4QS8vbm1BUC8vL1FELy8vOEEvUC8v
QVA3Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy8wQS8vLytBUC8vL0FELy8vOEEvLy83QVAvLw0KNFFE
eTZNSUE1Tm1mQU5qUGdBRFp1bVVBeDZaUUFNU29XZ0RQdUd3QTFjNmNBUEhrd0FELytkZ0EvLy8w
QVAvLy93RC8vL3dBLy8vOQ0KQVAvOTV3RDA0N3NBMmNwMEFMK21Sd0Mvc1dJQTNOV2VBUHJ5M0FE
Ly8vb0EvLy8vQVAvLy93RC8vdlFBODkrckFOQ3dXQURJcm1BQQ0KN2VPdUFQLys1UUQvLy9vQS8v
LzlBUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Lw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Q2OXR3QXpMNk1BTFNWVlFDNWswa0F0cFJHQUt5
T1NnQ3lwSGNBOE9uSw0KQU92Vm53RFZ0bXNBMWJWeUFOM0xrZ0RoMXFzQSsvdllBUC83MWdELzk5
TUEvLy9jQVAvLzN3RC8vL01BLy8vL0FQLy8vQUQvLy84QQ0KLy8vL0FQLy85d0QvLy9ZQS8vL3dB
UC8vNVFELyt0QUE3dU94QU52UmtnREZybW9BdWFGY0FMK2pZUUROdG04QTN0YVRBUGZvc3dELw0K
LzkwQS8vL3ZBUC8vL0FELy8vd0EvLy9mQU9yaHJRRFJ1SGtBdEp4ZEFNbXVlQURyM2E4QS8vL3FB
UC8vK1FELy8vb0EvLy94QVBYbg0KdEFESXIya0F3YUZlQVBqanJRRC8vK0FBLy8vMUFQLy8vUUQv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvL3YvQVAvOS93RCsvUElBOHUzUEFPbmV1UURvMnFzQTVkbWRBT0hIaWdEZg0KeUtJ
QSt2TFlBT2pQbUFET3NGZ0F5cDlGQU1HY1FBQzJtMHNBOS9HckFPelVqUURMcTJJQXo3cHFBTTY5
ZHdEdDU4QUE4Ky9ZQU9QYQ0KdkFEczQ4SUEvL3JlQVAvLzhRRC8vLzhBLy8vL0FQLy8vd0QvLy93
QS8vLzVBUC8vNXdENDhjNEE2K0NzQU4zVGtBRGR4MnNBemJSWA0KQU1HclN3REp3VzBBek1pU0FQ
UHB5Z0QvL2ZJQS8vLy9BUC8vL3dEODhkSUE1ZGlkQU5pNGF3RENvVjBBMjcyR0FQbnN4d0QvLy9R
QQ0KLy8vK0FQLy85UUQwNmNNQTFycDNBTXVsWXdEbzFxSUEvLy9xQVAvLy9BRC8vL3dBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
ei9BUC85L3dELy8vOEEvLy80QVAvLzlnRC8vL0lBLy8vcQ0KQVAvOTRnRC8rdWtBLy8vOUFQejEz
d0QxN0xzQTllYTJBT3plcVFEajA1NEEvdnJXQU9mTm9RRFl1SVFBeGFoZUFMaWdWd0RuM2JVQQ0K
M2RXMEFMQ1paUUN6bFZ3QXk2dDJBUC82eWdERnU1c0F4TG1aQU9ubHZRRC8vK0FBOStUQ0FQLy8x
UUQvLytjQS8vL2hBUC8vNGdELw0KLzlFQTlleTVBTjdib2dET3Vuc0F2SzVwQUw2a1d3RFp1MzBB
NE1hYUFQL3Z5QUQvLzlVQS8vL2tBUC81d1FEaTBwc0F6S0p4QU1HaA0KYndEZjA1MEEvLy9VQVAv
LzlBRC8vK3NBL2ZlL0FOTytld0N4bUY4QTN0R2xBUC8vN1FELy8vZ0EvLy84QVAvLy93RC8vLzhB
Ly8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vK3dELy8vZ0EvLy84QVAvLy9nRC8rLzBBLy96OUFQLy8vd0Qv
Ly84QS8vLzhBUC8vL1FELw0KLy84QS8vLzlBUC8vL2dELy8vOEEvLy81QVAvLytnRC8vL1lBLy8v
NEFQLy85d0QvLy9NQS8vLzdBUHJ6NlFELzk5Z0E5T3ZBQU8zbg0KdVFENjkrRUE4dkRZQU9IWW5n
RGYwNUVBNHRXU0FQLy93Z0RUdW44QXU2Rm5BTjdQaVFELy9ib0F2S1puQUw2b2JBRDY2YlFBMGNH
TQ0KQU5iR293RC85dGNBNnVIRkFQLzUzUUQvL05nQTlmR3lBT1Bja0FEcjJIVUE2c0JzQU5tdmFB
RE12SGtBejcrU0FQbnJ3d0QvLzlJQQ0KOXU3TEFON09qZ0RPclZvQXpiaG5BTzdocndELy85c0Ev
Ly9nQVByNXlBRFd4NVFBdnFScEFOckluQUQvL3VRQS8vLzlBUC8vL0FELw0KLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vN0FQLy83Z0QvLytZQS8vL3JBUC8vOGdELy8vY0EvLzMzQVAvLzlnRC8vL01BLy8vdg0K
QVAvLzZ3RC8vL2NBLy8vM0FQLy8rd0QvLy9zQS8vL3ZBUC8vNkFELy8vSUEvLy92QVAvLzh3RC8v
L0VBLy8vcEFQLy85QUQvLytvQQ0KLy8vcUFQLy82Z0QvLy9FQS8vLzBBUC8vNUFELy85VUEvLy9W
QVAvLzNRRC8rOHdBOXUvUUFQajB5UUQvLzgwQTVOcWJBT0Rab0FELw0KOWJvQTY5Q1VBTW11ZWdE
MDJLRUF3cmQ5QU5HK2lnRGF6cHdBMWNtTkFQTGZtUUQwMm9rQS8vS2dBT0hCZkFEWXhJNEF4N0ND
QUw2aA0KZFFEUXUzOEE2dHlWQVAvL3FnRDQ3cGdBNE1weEFNeXVhQURRdjRJQTllN0NBUC8vNHdE
Ly84b0EzOCtFQUx1Z1hRRGd6NXdBLy83cA0KQVAvLytBRC8vLzBBLy8vL0FQLy8vd0Q0K1BnQStQ
ajRBUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUDc2OVFEazFzTUEwTHlaQU5l
L2l3RFh3b1VBejhHSkFNN0NtUUR1NnRNQS8vL3ZBT0xjdXdETw0KdnBRQTFjT1FBTmJBamdEWHda
VUE5dkhmQVBIejVRRFF5S1FBemNLS0FNaTloUURUekpnQSsvdmFBTi9Vc2dETHc1RUF3Y0dJQU5u
VA0KclFELy85NEExTVNZQU1Ld2dnRGl4NmtBLy92YUFOM0xvUURJdG44QTh0K3hBUGJvdlFETHda
QUEyTTJyQVBudHlBQy90SWtBOHVLdA0KQVBydXVnREd1WU1BK3Qyb0FOaTloZ0RkeXBJQTcrN0JB
T3pudkFEdjZiZ0E3T0N3QVBidHdRRGJ3NUFBNnVLbUFOZkJrQUQvOTlJQQ0KOVBEYUFPZmV2QURv
MkpvQTRjUnlBTmErWkFEY3czTUE2OGQyQU9qSGZ3RFB1WGtBdGFadUFOL1FtUUQvK2IwQS8vL01B
T0xVbEFDOA0Kb0ZzQTByNlJBUC8vNndELy8vNEEvLy84QVAvLy93RDgvUHdBL1B6OEFQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0K
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQM3o2QURXdDVnQXJvcFdBTE9PUndDNGswZ0Fx
NUpLQUtTU1hRRGUxN1FBLy8vZw0KQU1yQmtRQ2NqRlVBcnBWVkFMYVRVUUMrbkYwQThPaktBUFh6
MmdDMHBYRUFzNXRjQUxLZVd3REpzbmNBKy9qVEFOUERvUUN1bzI4QQ0KbzUxbEFOVEpsd0QvLytB
QXliYUdBTXF4ZlFEV3ZaUUEvLy9nQU5uSWp3RFd1MzRBN3RpZUFQLzgwUUM5cTMwQTJzMmhBUC8y
eVFDLw0KczQ4QTdlbTVBUERyeFFESnZaUUEvL3ZiQU4vUnVBRHc1Y3NBLy8vNEFQLy84d0QvLytr
QS8vL29BUC8vOUFEMThlZ0E5L1hxQVBMdA0KNUFELy8vTUEvLy8rQVAvLzlRRC8vdW9BK2ZQYUFQ
RGx2d0RzelowQTNyMkZBTmV5Y1FEYXZvTUEzdFdmQUx1dGJBREJybWdBN09XaA0KQVAvL3lnRG8y
NThBdjZWZkFNaThpZ0Q4K2VFQS8vLzhBUC8vL1FELy8vOEEvLy8vQVB2Nyt3RDcrL3NBLy8vL0FQ
Ly8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy84QVAvOTlBRDM2TTRBN3R1b0FPL2duZ0R3NVpzQTd1V2tBT3ZrdGdE
NA0KOTl3QS8vL3RBUFB5elFEcDU3Z0E3dW0xQVBEcHRnRHg2N1VBL1B2VkFQNys1d0R3N013QThP
dS9BUEh2d1FEMjg4Y0EvLy9yQVBmMg0KNFFEMTlOb0E4Ty9OQVB6ODJnRC8vOVlBK1BmTkFQSGRy
UUR5Nkx3QTllbklBTnpNbmdEdTJLc0ExY3VTQVAvLzNnRHo3OUlBK3ZqaA0KQVAvLzhRRDE4K1VB
L1AzMUFQejg3Z0QzOWU4QS8vLy9BUG51N0FEKy9mc0EvLy8vQVAvLy9nRC8vL3dBLy8vOEFQLy8v
Z0QvLy84QQ0KLy8vL0FQLy8vd0QvLy80QS8vLy9BUC8vL1FELy8vOEEvLy8vQVAvLy93RC8rdk1B
K1BMZUFQUHN4Z0QzOGNvQS8vL2hBUEhyeGdEZQ0KeXBJQXc3QnNBTmpGZmdEOThySUErTzZ1QU5H
NGN3RE11WUlBK3ZYVEFQLy8rUUQvLy9vQS8vLzhBUDM5L2dEOS9mMEEvLy8vQVAvLw0KL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0K
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLytBUC8vL3dELy8va0EvLy90QVAvLzZBRC8vK2dBLy8vcQ0KQVAvLzh3RC8vL29BLy8v
ekFQLy84QUQvLy9BQS8vL29BUC8vNmdELy8rZ0EvLy9lQVAvLzBRRC8vOXdBLy8vbUFQL3d1d0Qr
NmFvQQ0KLy9EQUFQL3p4d0RBdUl3QTYrVzNBTnJObVFEQXQzNEE4T3F3QU1HNGdnRHIzTHdBNTlP
L0FPRFV0d0Q5K3Q0QTV0eTZBUC8vOGdELw0KLy9VQS8vLy9BUC8yOWdELy8vOEEvLy8vQVAvLy9n
RC8vLzhBLy8vL0FQLzkvZ0QvLy84QS8vLytBUC8vOXdELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL2dELy8vb0EvLy8vQVAvLy9R
RC8vL2tBLy8vMQ0KQVAvLzlRRC8vT3NBNitDL0FOTzFmZ0RSdFc0QTc5eUlBUC9za3dEYnZXVUEx
OFI1QVBUdnlBRC8vL2tBLy8vOEFQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QQ0KLy8vL0FQLy8vd0QvLy84QS8vLzlBUC8vL0FELy8vOEEvLy84QVAvLy93RC8vLzRBLy8vK0FQ
Ly8vd0QvLy84QS8vLzhBUC8vOXdELw0KLy9ZQS8vL3dBUDc0NHdELyt1Y0EvLy95QVAzNjVRRG0z
N2NBeGIrVUFOVE5zQUQ3K3VzQTJNK2pBS3lZVXdET3ZJVUEvZnZVQU0rNw0KZ3dDNW5GWUE4KzND
QVBqb3VRRFR5SlFBK2ZqTEFQcnh2UUR4Nks4QS9QclhBUEx4MGdENytld0ErL2oyQVByNTlnRC8v
L1VBL1B2Mw0KQVAvLy93RC8vLzRBLy8vL0FQLzkvUUQvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vK0FQLy8vUUQvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vZ0QvLy8wQS8vLy9BUC8vL3dELw0KLy84QS8v
LytBUC8vL2dELy8vOEEvLzc5QVByMjVRRHk1TEVBMUxWc0FOcTRYd0R5MDNJQXpMTmNBTXk1ZHdE
eTY4Z0EvLy82QVAvLw0KL1FELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0K
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL1FELy8vWUEvLy80QVAvLw0KL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vNEFQLy83Z0QvLytRQS8vL3FBUC8vOWdELy91VUEvL1RBQVB6bXFBRHQySmtB
OHR5bw0KQVAvNjJ3RDI2c1lBeXJaN0FLaVVWUUNxa2wwQTQ5cTNBUDM1endDNnJIa0FwcE5oQU1X
NGtBRHo4K0FBNmQ2MkFOekJpd0R6NUxBQQ0KLy8vZ0FQdjcxQURxMnFVQS8vM1pBT1RldEFEajJM
RUEyTkcxQU92aXhBRC8vT3dBLy8vMUFQLy8vZ0QvLy84QS8vLy9BUC8vL3dELw0KLy80QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vRUEvUGpWQU52UW9BREp0WElBN2RxUUFOWERnQURCc1hvQQ0KN3Vq
TEFQLy8rZ0QvLy9VQS8vLzhBUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
Lw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vZ0QvLy80QQ0KLy8vOEFQLy8rQUQvLy84QS8vLy9BUGYxOEFEYzBMY0Ex
YjJRQU5PN2VBQy9yMmNBeGNPUkFQYjQ1d0QyNzh3QXc2MW1BS2FHTWdDcw0KalRNQXhhNW5BUEhx
dkFELytjVUE0TWVFQU5hMGJRRHV6WVVBL1BQSkFQLy81UUQzOXNrQSt2bk1BUDMrNXdELy8vQUEv
dkhTQVAvNw0KMlFELzlzb0Ewc0dYQU9qZ3RBRE52SllBM2RHdkFQRG95UUQ4K3VVQTgrdlhBUHI1
N0FELy8vNEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLzhBUHo4OGdENDkrTUEvLzdoQVAvMw0KelFEVHdZa0F1cVYyQVBEbHh3RC8v
L1VBLy8vNkFQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0K
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUDMvL3dEMS8vOEErUC8v
QVAvLw0KL3dELy8vOEEvLy8rQVAvLy9nRC8vLzBBLy8vNEFPL3EwUUMxb1djQW40UStBTEdXUlFD
eW1rd0F4TGFMQVBMdTZRRDUrdXdBMzlhdg0KQU5mRG1RRG4wNk1BOStuQkFQNzY2Z0QvLy9RQS8v
L2hBUDc5MlFELy85OEEvLy9kQVAvLzZBRC8vOXNBNGRHVkFOM0ltZ0QrOU5BQQ0KdXJDT0FNMi9u
QUR2MjhBQTJzeXFBUFR4MmdENysrSUEvUHZsQVA3KytnRC8vLzhBLy83OUFQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QQ0KLy8vM0FQLy84d0QvOStFQTA4Q1dBSytkYndEazM3RUEvLy95QVAv
Ly9RRC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Lw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQNy8vd0QrLy84QQ0KL3YvL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vb0EvLy90QVAvNjRnRDQ1YmdBOWQ2aUFQM3Fvd0Q4L2JVQS9memRB
UC8rL0FELw0KLy9vQS8vLzNBUC8vK0FELy8vTUEvLy82QVA3Lzl3RHU1c29BOHVDOEFQLzk0QURs
M2J3QW9aUnVBTG13andENDhjZ0Eyc21VQU9MTg0KcUFEKzkrTUErL3pqQVB6NzVRRCsvZklBL2Yz
c0FQLy8rd0QvLy9nQS8vLytBUC8vK0FELy8vMEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0K
L3dELy8vOEEvLy8vQVAvLyt3RC8vL2tBLy96cEFPRFNvQUM3cVc0QTQ5MjhBUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL0FELy8vY0EvLy8rQVAvLzl3RDgvLzhBOS8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8rQVAvLzd3RC8vK1VBLy8vcA0KQVAvLzdBRC8v
KzBBL1BYTkFPZlduQURrMDVNQSsvTEdBUEh5endDcnAzb0FsSXBRQU43YnNBRDQ3Y2NBM2MrdUFP
L3MyQUQvLy9BQQ0KL3Y3ckFQNysrQUQvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8zQVAvLy9RRC8v
LzhBLy8vL0FQLy8vZ0QvLy80QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0Q2Ly84QSt2
Ly9BUC8vL3dELy8vWUEvLy93QVAvLzNnRGN6S0lBdWJDV0FON2YyQUQ5L2Y0QS8vLy9BUC8vL3dE
Lw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QQ0KLy8vL0FQLy8vd0QvLy8wQS8vLzNBUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vL3NB
Ly8vOEFQLy8vd0QvLy84QS8vLy9BUDN6NlFEYw0KeFpJQXU3SjVBTjNmc0FELy8rTUEyOUtxQUp1
SVN3Q3ZubG9BNnVPNUFQLy82d0R1NnI0QTgrKzhBUC8vMndEUzA2a0F6YzJzQVBmMw0KNlFELy8v
OEEvLy8vQVAvLy93RDQrUDhBKy92L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0K
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLzdBUC8vOXdELy8vUUE5UFRuQVBiMzh3RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vMEEv
Ly8xQVAvLytBRC8vLzRBLy8vL0FQLy85UUQvLy93QS8vLy9BUDc4NXdENTdha0E2TTZLQU5XNGdB
RDQzNzhBLy8vMg0KQU96ZnZBQ3dpMUlBbUg1SkFNM0RtUUQvLytVQS8vcmhBUC94eFFELzdMb0Ev
L1hXQVAvLzhnRGIwTEFBd3JHQUFPdnB4QUQzOHMwQQ0KOCszSUFQejk4d0QvLy9zQS8vLzBBUC80
K3dELy9QOEEvLy8vQVBqLy93RDcvLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84
QS8vLy9BUC8vOWdELy8vd0EvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vOUFE
LzhkSUE3OVczQU9YWHVRRDg5dVlBLy8vL0FQYncwZ0RCbzJJQWxIRXBBTE9PUXdEaA0KeDVVQS8v
LzBBUC8vNUFELy84d0EvLy9lQVAvLzZRRC85dDRBLy9YaUFQLy84Z0RKdkowQXA1TjVBT25uMWdE
Ly8ra0EvLzdmQVAvLw0KN0FELy8vUUEvLy8vQVAvLytRRC8vL3NBLy8vL0FQLy8vd0Q0K1A4QSsv
di9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0K
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QTkvVHpBSlNQandBckxDd0FJU0VoQURNek13Q3BxS2dB
Ly8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEFnb0tDQUdC
Z1lBRGs1T1FBLy8vL0FQYjI5Z0Q4L1B3QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBOWZUZEFMU25jZ0NwaWl3QXBJRWdB
S0dJUGdEbDE2OEEvLy8vQVAvNjZ3RC8zN0VBK3RlbA0KQVAvNHlRRC8vK2NBLy8veUFQLy8zZ0Qv
OTlJQS8vL2xBTi9YdVFDVmhXd0F1N2FiQVAvLzlRRCsrL0VBLy9qckFQLzkrd0QvLy84QQ0KLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vL1lBLy8v
K0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
Lw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS92NytBUDM5L1FELy8vOEEvLy8vQVA3Ky9n
RDkvZjBBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBaW51RkFENDFPd0RuM3QwQS8vLy9BTXZMeXdCRA0KU2tvQW42T2pBUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QTRlSGhBR2xwYVFCemMzTUE1
dWJtQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQ
Ly8vd0QvL3Y4QS8vWC9BUC8vL3dELy8vOEErdm5zQU16Q2pnQytyRThBNTgxeEFQcm1uQUQvLzlz
QS8vLy9BUC8vL3dELw0KLy9RQS8vL29BUC8vNWdELy8rOEEzdC9QQUptVGZRREp0bzRBLy9uY0FQ
Ly85QUQvOXVJQStmWHpBUC8vL3dELy8vd0EvLy84QVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0K
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0RXMXRZQW9xS2lBUEx5OGdELy8vOEEvLy8vQU0vUHp3Q01q
SXdBK2ZuNUFQLy8vd0J6YzNNQQ0KUGo0K0FEczdPd0QvLy84QS8vLy9BUC8vL3dCL2YzOEFJeU1q
QUxpNHVBRC8vLzhBc3JLeUFNUER3d0QvLy84QTUrZm5BSTJOalFELw0KLy84QS8vLy9BT3pzN0FC
a1pHUUFNakl5QUhkM2R3RC8vLzhBOXZiMkFLbXBxUUREdzhNQS8vLy9BUER3OEFDbnA2Y0F3Y0hC
QVAvLw0KL3dEZTNOd0FuWlNVQU5MTHl3QzF0clFBNCtmYkFMRzlzZ0RTMnRJQS8vLy9BTm5WMVFD
OXRiUUF0S2lyQUg5c2RnQ2NrNWdBbko2ZQ0KQUh4OGZBQkpTVWtBcXFtcEFQLy8vd0QvLy84QTRl
SGhBTi9mM3dDTmpZMEFORFEwQUkrUGp3RDE5ZlVBLy8vL0FQUHo4d0JyYTJzQQ0KMGRIUkFQLy8v
d0QvLy84QS8vLy9BUC8vL3dDc3JLd0F0YlcxQVBmMzl3RC8vLzhBLy8vL0FKV1ZsUURwNmVrQTI5
dmJBSmFXbGdEOQ0KL2YwQS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QTgvLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLytBUC8vNmdELy8rUUEvLy9zQVAvLzZRRC8vKzRBLy8vNA0KQVB6
MzNnRGF4cFVBdWFad0FPZmJzUUQvLy9zQTh1L3BBTlRLd1FEbTR0TUEvLy84QVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEErUC8vQVB2
Ly93RC8vLzhBLy8vL0FQLy8rQUQvLy9zQS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93QzFyTFVBWTFsakFPbnA2UUQvLy84QSsvdjdBRFUxTlFBdkx5OEEvLy8vQUZC
UQ0KVUFBOVBUMEF3OFBEQUkyTmpRQVRFeE1BLy8vL0FLNnVyZ0FBQUFBQXhjWEZBUC8vL3dELy8v
OEFJeU1qQUZOVFV3RC8vLzhBYVdscA0KQUFBQUFBRC8vLzhBKy92N0FENCtQZ0JMUzBzQTA5UFRB
RTVPVGdCcWFtb0E4L1B6QURZMk5nQ3hzYkVBLy8vL0FNN096Z0JKU1VrQQ0Kd3NMQ0FQejYrZ0Nh
a1pFQVlWWlhBTUsxc3dCWFZFNEF1N095QUY1aldRQ25ycWdBLy8vL0FLV3FwUUJrWldZQXFLU2tB
RnRXVlFCTA0KU1V3QWMybHZBSGh1YlFEQnU3c0EvLy8vQVAvLy93RC8vLzhBcWFtcEFDZ29LQUIz
ZDNjQXQ3ZTNBRDQrUGdDSWlJZ0EvUHo4QU5yYQ0KMmdBWUdCZ0FvcUtpQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0JoWVdFQVkyTmpBTy92N3dELy8vOEEvLy8vQUNVbEpRREl5TWdBcnE2dQ0KQURjM053
RHg4ZkVBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVA3Ly93RC8vLzhBLy8v
L0FQLy8vd0QvLy80QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL2dELy8vOEEvLy8vQVAvLy93
RC8vL2dBLy8vK0FQLy8rZ0QrL1BJQTdPUzJBTkxUcVFEeQ0KOHRrQS8vLy9BUHY1NkFETHc1Z0Fx
YUIzQVBUdXlnRC8vL0lBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL2dELy8vOEEvLy8vQVAvLw0K
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dDNnNia0FXRmRpQU9qbzZnRC8vLzhBalk2TkFCc1NHd0JaV0ZrQQ0KNmVycEFCTVRFd0QvLy84
QS8vLy9BUC8vL3dEcTZ1b0EvLy8vQUxPenN3QWtKQ1FBLy8vL0FQLy8vd0R5OHZJQUFRRUJBRU5E
UXdELw0KLy84QVFVRkJBQzh2THdEbDVlVUEzZDNkQUE4UER3RC8vLzhBLy8vL0FPcnE2Z0FqSXlN
QTBkSFJBRk5UVXdDam82TUEvLy8vQU5yYQ0KMmdBMk5qWUFpWW1KQU5yWTJBQmNVMVFBNWVEZ0FM
Njl2Z0JjVlZVQXg4akpBR2RtWkFDc3JLY0EvLy8vQUxXMHRRQnNiR3dBdHJlMw0KQUh4OGZBQjFk
blVBc3E2eUFPVGc1UUQvLy84QS8vLy9BUC8rL3dELy8vOEFzN096QUZkWFZ3REh4OGNBLy8vL0FL
eXNyQUJjWEZ3QQ0KNE9EZ0FJS0NnZ0F6TXpNQVpHUmtBT1RrNUFELy8vOEEvLy8vQVAvLy93QmFX
bG9BYVdscEFQUHo4d0QvLy84QS8vLy9BQ2dvS0FETA0KeThzQXM3T3pBRXBLU2dEOS9mMEEvLy8v
QVAvLy93RC8vLzhBOVBUMEFQLy8vd0QvLy84QS8vLy9BUFgvL3dELy8vOEEvLy8vQVAvLw0KL3dE
Ly8vWUEvLy8vQVAvLy93RC8vLzhBLy8vK0FQLy85Z0QvLy9ZQS92M3pBUDc5NmdEKy92Z0EvLy8v
QVAvLzlRRDA4TWNBcFpSZQ0KQUk2SFZnRGMzYmtBLy8vNUFQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy9BRC8vL1VBLy8vMUFQLy8rUUQvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Lw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0N3c3JrQVlW
bGlBTy9tN3dEMzlmY0FNREF3QUtDZw0Kb0FCNWVYa0EzTnpjQUJrWkdRQjNkM2NBY0hCd0FJU0Vo
QUJjWEZ3QS9QejhBSitmbndCQVFFQUEvLy8vQVAvLy93Q0ZoWVVBWldWbA0KQUlTRWhBQ0VoSVFB
WVdGaEFLK3Zyd0I1ZVhrQTF0YldBQ2dvS0FELy8vOEEvUHo4QU9mbjV3QWJHeHNBdHJhMkFGOWZY
d0NycTZzQQ0KLy8vL0FOdmIyd0F2THk4QU1EQXdBRjFkWFFDSmlvb0EvLy8vQUxpMnVRQlpWRm9B
dkwyOEFHbG9hUUM2dXJvQS8vLy9BSzJ3clFCag0KYldNQTBOWE1BSHlCZUFCVlYxRUFmWFIwQUVs
QVJRQ3VxcTRBLy8vL0FQLzYvd0QvLy84QXBLU2tBR1JrWkFEUzB0SUEvLy8vQU1IQg0Kd1FCT1Rr
NEF4TVRFQUZaV1ZnQ3lzcklBVTFOVEFNYkd4Z0QvLy84QS8vLy9BUC8vL3dCcmEyc0FYMTlmQU9q
bzZBRDkvZjBBKy92Nw0KQURZMk5nRE96czRBdHJhMkFDOHZMd0M0dUxnQXVMaTRBTVhGeFFENysv
c0EvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vK0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RDYrZGdBeHJxS0FNT3hoQURwMzhBQS8vLy9BUC8vL2dENg0K
K040QTM5bXBBT2ZvdXdELy8rOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vd0EvLy81QVAvLw0KL3dELy8vOEEvLy8vQVAvKy93RC8vdjhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93Qzd1N29BVzF0YkFQajUrQUJQ
VUU4QQ0KaDRlR0FQWHM5QUJzYkd3QStQajRBQmdZR0FDOHZMd0E5ZlgxQU1YRnhRQVFFQkFBNysv
dkFMS3lzZ0FoSVNFQS8vLy9BUC8vL3dBVQ0KRkJRQXhzYkdBTTdPemdBQUFBQUFuNStmQVAvLy93
QlBUMDhBMnRyYUFCWVdGZ0QzOS9jQS8vLy9BTXpNekFBdkx5OEE0K1BqQUVaRw0KUmdCNGVIZ0Ev
Ly8vQU4vZjN3QmlZbUlBakl5TUFGaFlXQUNjbkprQS8vLy9BTGU0dUFCWFYxY0F4c1BHQUZ4UlhB
Q01ob3dBLy8vLw0KQUxDd3NBQnViV2tBa3BDTkFHWnBad0RKejhvQS8vLy9BSGx3ZWdDQ2VZSUEv
Ly8vQVAvLy93RC8vLzhBcWFtcEFGaFlXQURGeGNVQQ0KLy8vL0FKNmVuZ0J3Y0hBQWQzZDNBR05q
WXdEbjUrY0FrSkNRQUp5Y25BRHk4dklBLy8vL0FQLy8vd0JrWkdRQUVoSVNBRTFOVFFCTg0KVFUw
QVVsSlNBQUVCQVFEVjFkVUF3OFBEQUFjSEJ3QnpjM01BVkZSVUFESXlNZ0JaV1ZrQS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8xQVAvLy93RC8vTzhBK3Zqa0FQejg4d0QvLy84
QS8vLy9BUC8vOHdEbTNxVUFrWVpDQUoyTVVBRGkwNllBLy96NQ0KQVAvLy93RC8vLzhBLy8vL0FQ
Ly85d0QvLy9rQS8vLzRBUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC82L3dELyt2OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dDNXViZ0FiVzFzQUxHeQ0Kc1FBc0xDd0E5T3pz
QVBQcjZnQlFUazRBLy8vL0FHNXViZ0JjWEZ3QTVPVGtBSStQandCYlcxc0EvLy8vQUZCUVVBQW1K
aVlBenM3Tw0KQVBmMzl3QWdJQ0FBK2ZuNUFPM3Q3UUFRRUJBQTBORFFBUC8vL3dCRFEwTUEzZDNk
QUdCZ1lBQlVWRlFBenM3T0FHUmtaQUJyYTJzQQ0KL2YzOUFFWkdSZ0F1TGk0QW9hR2hBTlRVMUFC
T1RrNEEwTkRRQU5iVzFnQlpXMXdBek5YU0FMbkF2UUJkWG1RQXpzck5BRjFVWFFCVw0KVGxZQXRM
QzFBR3ByYkFCNWRIVUExdERRQUdKbll3Q0pqWWtBczdpNEFFZE5Td0NhbXBrQS8vLy9BUC8vL3dE
Ly8vOEF1N3U3QUNvcQ0KS2dCMGRIUUF2YjI5QUV4TVRBQ1VsSlFBZFhWMUFLaW9xQUQrL3Y0QTA5
UFRBSGg0ZUFEZTN0NEEvLy8vQVAvLy93QjJkbllBUlVWRg0KQUxDd3NBQ3hzYkVBc3JLeUFCQVFF
QURUMDlNQXNiR3hBRkZSVVFELy8vOEEvLy8vQU5yYTJnQWRIUjBBNStmbkFQLy8vd0QvLy84QQ0K
Ly8vL0FQLy8vd0QvLy84QS8vLzJBUGoxekFEZ3daRUF2YUo4QU5iT3NRRC8vLzBBLy8vK0FQLy8r
QUQvLzk0QTZOaXFBUC8zekFELw0KLys0QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0M2dXJNQQ0KWldWY0FDWW1IZ0NnbUpjQS8vNytBTzN1N2dCY1ZW
VUE5dlgxQVAvLy93Q2xwYVVBWEZ4Y0FJYUdoZ0QvLy84QTUrZm5BRTlQVHdBQQ0KQUFBQXRiVzFB
T3ZyNndDdXJxNEEvLy8vQVAvLy93Q29xS2dBLy8vL0FQLy8vd0RTMHRJQTBkSFJBUC8vL3dDSWlJ
Z0FabVptQUl5TQ0KakFELy8vOEErUGo0QU1iR3hnREJ3Y0VBZm41K0FMZTN0d0JXVmxZQXVMaTRB
UC8vL3dEUjFORUFzTGl5QU9mdjd3REF4c1lBN3U3dQ0KQU5EUjBBQzV1cmdBZTN4L0FJeUprZ0R0
Nk8wQS8vLy9BTnpiM0FDQWY0QUFhVzVwQUUxVFRnQ0FnSUFBNmVucEFQLy8vd0QvLy84QQ0KbnA2
ZUFHUmtaQUNKaVlrQWRYVjFBS1dscFFEKy92NEF3TURBQU9ibTVnRC8vLzhBLy8vL0FNYkd4Z0R1
N3U0QS8vLy9BUC8vL3dCbA0KWldVQVpXVmxBUGIyOWdELy8vOEEvLy8vQURBd01BRE16TXdBcEtT
a0FFNU9UZ0QxOWZVQS8vLy9BUHY3K3dBQUFBQUEzdDdlQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vc0FNbXBjd0NmZlQ0QXE1SlRBTWEzZ3dELy8vb0EvLy80QVAvLy93RC8vL3NBLy8v
Lw0KQVAvLy9RRC8vL3NBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLw0KL3dESHg4Z0FDd3NNQUZkWFdBRHk4L01BLy8vL0FPVGs1QUJXVmxZQTlQVDBBUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQU1YRnhRQmNYRndBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQU4zZDNRQlFVRkFBdmIyOUFQLy8vd0QvLy84
QS8vLy9BTnpiMndDdQ0KcnE0QStQajRBUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BT1RvNkFDd3NMQUEyZG5aQVAvLw0KL3dELy8vOEFxNnVyQUcxdGJRRGEy
dG9BLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0K
QVAvLy93QmlZbUlBY0hCd0FQSHg4UUQvLy84QS8vLy9BRFEwTkFET3pzNEFzTEN3QURBd01BQ2pv
Nk1BdXJxNkFFVkZSUUJTVWxJQQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy84
QU96VnBnRGd6SXdBK3VhMEFQLzYyUUQvLy8wQS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8v
d0RwNmVrQWc0T0RBTnZiMndELy8vOEEvLy8vQU9ucDZRREt5c29BL2YzOUFQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dEczdPd0EvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BTy92N3dDMXRiVUE0ZUhoQVAvLy93RC8vLzhBL3Y3Kw0KQU5Y
VjFRQ3VycTRBNit2ckFQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QTJ0cmFBTVBEd3dEdTd1NEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dDNnVy
b0F1cnE2QVBqNCtBRC8vLzhBLy8vL0FLcXFxZ0RuNStjQS8vLy9BRzV1YmdDSGg0Y0FZbUppQUo2
ZQ0KbmdEeDhmRUEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Q4L1A4QS8vLzVBUC8vK2dELy8r
d0EvLy83QVAvLy9RRC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvdjcrQVAzOS9RRC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELw0KLy84QS9mMzlBUDM5L1FELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dEMjl2WUEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dEOS9mMEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0K
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dENStma0EvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAzLy93RDA5djhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUHI2K2dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8v
LzhBKy92N0FQLy8vd0QvLy84QS8vLy9BUHI2K2dEMjl2WUE5L2YzQVA3Ky9nRC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUG41K1FEMQ0KOWZVQTlmWDFBUHI2K2dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dE
Ly8vOEEvLy8vQVA3Ky9nRDA5UFFBOVBUMEFQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS9m
MzlBUDM5L1FELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Lw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS92
NytBUFgxOVFENCtQZ0E5L2YzQVAvLw0KL3dELy8vOEEvLy8vQVB6OC9BRCsvdjRBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUGovL3dENi8vOEE5L2o1QUxtOHZBQzN1cm9BdGJpNA0KQUx1N3hRQzB0TDBB
ME5EUEFQLy8vd0QvLy84QS8vLzhBUC8vL0FELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QStQajRBTTdPemdDeHNiRUF2YjI5QUx5OHZBQzd1N3NB
MzkvZkFQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQU96
czdBREx5OHNBcXFxcUFJK1Bqd0NEZzRNQWhJU0VBSjZlbmdDOXZiMEE1ZVhsQVAvLw0KL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS9QejhBUDcrL2dELy8vOEEvLy8vQVBM
eThnRFQwOU1BdXJxNg0KQUk2T2pnQ0JnWUVBZzRPREFJNk9qZ0Nnb0tBQXc4UERBT0RnNEFELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0Q4L1B3QXlNaklB
SldWbFFCK2ZuNEFnSUNBQUtDZ29BQzd1N3NBNit2ckFQLy8vd0RoNGVFQXNMQ3dBTDYrdmdDKw0K
dnI0QXVibTVBTi9mM3dELy8vOEEvUHo4QU52YjJ3Q3hzYkVBdWJtNUFNREF3QUM0dUxnQTBkSFJB
UDcrL2dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBKy92N0FQdjcrd0Qv
Ly84QTZPam9BTUhCd1FDMnRyWUF1Ym01QUwyOXZRRHc4UEFBLy8vLw0KQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEErL3Y3QU4zZDNRREN3c0lBbXBxYUFJU0VoQUNJ
aUlnQQ0KaFlXRkFLMnRyUURLeXNvQTh2THlBUC8vL3dELy8vOEErL3Y3QVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QTIrZmpBQUFGQlFBQQ0KQVFFQUFBQUFBQVFEQ1FBQUFBQUFaMmRtQVAvLy93
RC8vLzhBLy8vNEFQLy8rUUQvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBM3Q3ZUFFdExTd0FBQUFBQUFnSUNBQUFBQUFBS0Nnb0FpNHVMQVAvLy93
RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Q2K3ZvQXo4L1BBSEJ3Y0FBZ0lDQUFB
UUVCQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFJQ0FnQQ0KVTFOVEFMZTN0d0R4OGZFQS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBK2ZuNUFQLy8vd0QvLy84QXpzN09BSFoyZGdBcQ0KS2lv
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQkFRRUFFdExTd0NqbzZNQTd1N3VBUC8v
L3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93Q1hsNWNBR0JnWUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBTkRRMEFhMnRyQU9qbzZBQ1NrcElBQUFBQQ0KQUFBQUFBQUFBQUFBREF3TUFK
Q1FrQUQvLy84QThmSHhBSUNBZ0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBWDE5ZkFQajQrQUQvLy84
QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBa3BLU0FC
b2FHZ0FBQUFBQUFBQUFBQUFBQUFDaw0KcEtRQS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0RzN093QW01dWJBRVJFUkFBTEN3c0FBQUFBQUFBQQ0KQUFBQUFBQUFBQUFB
QUFBQUFBQWRIUjBBZUhoNEFOTFMwZ0QvLy84QStQajRBUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBOWZueA0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQVRrNU9BUC8vL3dELy92NEEvL3Y4
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEzOS9mQUV0TFN3QUFBQUFBQUFBQUFBQUFBQUFGQlFVQWdZR0JBUC8vL3dELw0KLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93QzJ0cllBT3pzN0FBRUJBUUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUNBZ0lBQ1BqNDhBN3U3dUFQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVBqNCtBQ2xwYVVBSGg0ZQ0KQUFBQUFBQUFBQUFBQkFRRUFBSUNB
Z0FBQUFBQUFnSUNBQUFBQUFBQ0FnSUFBQUFBQUFBQUFBQUFBQUFBWW1KaUFOSFIwUUQvLy84QQ0K
Ly8vL0FQLy8vd0QvLy84QS8vLy9BTWpJeUFBQUFBQUFBQUFBQUFJQ0FnQUFBQUFBQXdNREFBY0hC
d0FBQUFBQUFBQUFBR05qWXdDQg0KZ1lFQUFBQUFBQUFBQUFBQUFBQUFFaElTQUltSmlRRC8vLzhB
OXZiMkFJR0JnUUFBQUFBQUFnSUNBQUlDQWdBQUFBQUFWRlJVQVBuNQ0KK1FELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dEKy92NEFhMnRyQUFBQUFBQUFBQUFB
QUFBQQ0KQUFBQUFBQmVYbDRBNXVibUFQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQU9q
bzZBQnBhV2tBQlFVRkFBQUFBQUFBQUFBQQ0KQXdNREFBRUJBUUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUN3c0xBREx5OHNBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vYjNB
QUFBQUFBRkJRVUFBd0FBQUFBQUFBQUJBQUFBVTFSVEFQLy8vd0QvL3Y0QS8vbjVBUC8vL3dELy8v
OEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QTRlSGhB
RTlQVHdBQUFBQUFBQUFBQUFBQUFBQUpDUWtBZ1lHQg0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BTW5KeVFCQVFFQUFBQUFBQUFBQUFBQUJBUUVBQWdJQ0FDQWdJQUE4UER3QQ0KTXpN
ekFCRVJFUUFBQUFBQUFBQUFBQUFBQUFBV0ZoWUFqSXlNQVBUMDlBRC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BSTZPamdBRw0KQmdZQUFBQUFBQUFBQUFBUER3OEFBQUFBQUFJQ0FnQUFBQUFBQUFB
QUFBQUFBQUFEQXdNQUJnWUdBQUFBQUFBQUFBQUFBQUFBQUQ0Kw0KUGdEbTV1WUEvLy8vQVAvLy93
RC8vLzhBLy8vL0FGbFpXUUFBQUFBQUFBQUFBQVVGQlFBQ0FnSUFBUUVCQUFVRkJRQUFBQUFBQUFB
QQ0KQUFBQUFBQTlQVDBBQUFBQUFBUUVCQUFBQUFBQUR3OFBBSTZPamdELy8vOEE4L1B6QUgxOWZR
QUFBQUFBQlFVRkFBQUFBQUFBQUFBQQ0KV2xwYUFQYjI5Z0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0RWMWRVQVBEdzhBQUFBQUFBRg0KQlFVQUFRRUJBQUFB
QUFBYkd4c0F4OGZIQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QTgvUHpBR0ZoWVFBQUFBQUFB
QUFBQUFJQw0KQWdBQUFBQUFBQUFBQUJZV0ZnQWtKQ1FBSEJ3Y0FBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBbUppWUEwOVBUQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBOSszc0FBQUFBQUFDQUFB
QUJRQUFBQUlBQWdBSEFBQUFWRkZWQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBM3Q3ZUFFcEtTZ0FBQUFB
QUFnSUNBQUFBQUFBRg0KQlFVQWc0T0RBUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBOC9QekFH
NXViZ0FBQUFBQUFBQUFBQUFBQUFBQUFBQUFMeTh2QUtHaA0Kb1FEYzNOd0F4OGZIQUd0cmF3QVNF
aElBQUFBQUFBTURBd0FBQUFBQUdob2FBTVBEd3dELy8vOEEvLy8vQVAvLy93RC8vLzhBd01EQQ0K
QUJVVkZRQUFBQUFBQUFBQUFBQUFBQUFFQkFRQUFBQUFBQWNIQndBdExTMEFPRGc0QUNZbUpnQUVC
QVFBQUFBQUFBUUVCQUFBQUFBQQ0KQUFBQUFBQUFBQUJVVkZRQSt2cjZBUC8vL3dELy8vOEEvLy8v
QUJnWUdBQUFBQUFBQUFBQUFBTURBd0FFQkFRQUlTRWhBR1ZsWlFCcg0KYTJzQVNrcEtBQWNIQndB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBRUJBUUFKU1VsQUQvLy84QTgvUHpBSHA2ZWdBQUFBQUFCQVFF
QUFFQg0KQVFBQUFBQUFYRnhjQVB2Nyt3RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93Q1JrWkVBRUJBUQ0KQUFBQUFBQUJBUUVBQWdJQ0FBQUFBQUFBQUFBQW1w
cWFBUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBa1pHUkFBWUdCZ0FBQUFBQQ0KQXdNREFBSUNB
Z0FQRHc4QVhWMWRBSjZlbmdDMnRyWUFvcUtpQUZCUVVBQUtDZ29BQUFBQUFBQUFBQUFBQUFBQVFF
QkFBUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEE5Ty8wQUFBQUFBQUVBQUFBQUFBREFBUUFB
d0FDQUFJQVhGZGdBUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEzdDdlQUVwS1NnQUFBQUFBQXdNRA0KQUFB
QUFBQURBd01BZjM5L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEF2THk4QUNzckt3QUFBQUFB
QUFBQUFBQUFBQUFDQWdJQQ0Ka3BLU0FQLy8vd0QvLy84QS8vLy9BT0hoNFFCQVFFQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFITnpjd0R1N3U0QS8vLy9BUC8vL3dEeg0KOC9NQVB6OC9BQUlDQWdBRUJB
UUFBQUFBQUFBQUFBQUFBQUFBSVNFaEFJeU1qQUREdzhNQXk4dkxBTHU3dXdCcWFtb0FFeE1UQUFF
Qg0KQVFBRUJBUUFBQUFBQUFJQ0FnQUFBQUFBc3JLeUFQLy8vd0QvLy84QSsvdjdBQUlDQWdBQUFB
QUFBQUFBQUFNREF3QUNBZ0lBZ29LQw0KQVByNitnRC8vLzhBNWVYbEFGUlVWQUFBQUFBQUFBQUFB
QUVCQVFBQ0FnSUFFUkVSQUl1TGl3RC8vLzhBOHZMeUFIcDZlZ0FBQUFBQQ0KQVFFQkFBSUNBZ0FB
QUFBQVhWMWRBUHI2K2dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
Tzd1N2dCYg0KVzFzQUFBQUFBQUlDQWdBQkFRRUFCQVFFQUFRRUJBQUFBQUFBV2xwYUFPYm01Z0Qv
Ly84QS8vLy9BUC8vL3dEMzkvY0FPam82QUFBQQ0KQUFBQUFBQUFCd2NIQUFBQUFBQlhWMWNBNStm
bkFQLy8vd0QvLy84QS8vLy9BTzd1N2dCRlJVVUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUw2K3Zn
RC8vLzhBLy8vL0FQLy8vd0QvLy84QTd1NzVBQUFBQUFBQUFBTUFBQUFKQUFBQUFnQUFBQUlBVjFo
Y0FQLy8vd0QrLy84QQ0KK3YvL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QTRPRGdBRTVPVGdBQQ0KQUFBQUFnSUNBQUFBQUFBREF3TUFm
MzkvQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QWhvYUdBQUFBQUFBQUFBQUFBZ0lDQUFBQQ0K
QUFBbUppWUF3TURBQVAvLy93RC8vLzhBLy8vL0FQLy8vd0JwYVdrQUJRVUZBQUFBQUFBQ0FnSUFB
QUFBQUMwdExRRGMzTndBLy8vLw0KQVAvLy93Q1hsNWNBQ0FnSUFBQUFBQUFBQUFBQUNBZ0lBQUFB
QUFBWEZ4Y0Fzckt5QVAvLy93RC8vLzhBLy8vL0FQLy8vd0R3OFBBQQ0KajQrUEFBQUFBQUFFQkFR
QUFBQUFBQVVGQlFBQUFBQUFSRVJFQVAvLy93RC8vLzhBOWZYMUFBQUFBQUFCQVFFQUFBQUFBQUFB
QUFBTw0KRGc0QXljbkpBUC8vL3dELy8vOEEvLy8vQU1MQ3dnQVVGQlFBQUFBQUFBQUFBQUFBQUFB
QUVoSVNBSXFLaWdELy8vOEE5UFQwQUg1Kw0KZmdBQUFBQUFBUUVCQUFJQ0FnQUFBQUFBV2xwYUFQ
djcrd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQU1qSXlBQXlN
aklBQUFBQUFBUUVCQUFDQWdJQUF3TURBQU1EQXdBQUFBQUFIUjBkQU12THl3RC8vLzhBLy8vL0FQ
Ly8vd0N2cjY4QQ0KRlJVVkFBQUFBQUFEQXdNQUFnSUNBQUFBQUFDNXVia0EvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0M0dUxnQVNrcEtBRkpTVWdCZA0KWFYwQVZGUlVBTDI5dlFELy8vOEEvLy8v
QVAvLy93RC8vLzhBNy9YNUFBQUFBQUFBQUFNQUFBQUVBQUFBQXdBQUFBQUFURXRMQVAvLw0KL3dE
Ky8vOEErdi8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBNE9EZw0KQUU1T1RnQUFBQUFBQXdNREFBQUFBQUFGQlFVQWdvS0NBUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RHk4dklBWTJOakFBQUFBQUFFQkFRQQ0KQVFFQkFBQUFBQUJQVDA4QTE5
ZlhBUC8vL3dELy8vOEEvLy8vQVAvLy93Q1ZsWlVBRnhjWEFBQUFBQUFEQXdNQUFBQUFBQWNIQndE
Sw0KeXNvQS8vLy9BUC8vL3dCQlFVRUFBQUFBQUFRRUJBQUFBQUFBQ0FnSUFBQUFBQUNCZ1lFQS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQUNzckt3QUFBQUFBQUFBQUFBQUFB
QUFCQVFFQUFBQUFBUHI2K2dELy8vOEE5dmIyQUFBQUFBQURBd01BQkFRRQ0KQUFBQUFBQVBEdzhB
MTlmWEFQLy8vd0QvLy84QS8vLy9BT3JxNmdBdUxpNEFBQUFBQUFBQUFBQUFBQUFBRHc4UEFJK1Bq
d0QvLy84QQ0KOVBUMEFINStmZ0FBQUFBQUFRRUJBQU1EQXdBQUFBQUFWMWRYQVB2Nyt3RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BSlNVbEFBUER3OEFBQUFBQUFB
QUFBQUFBQUFBS0Nnb0FCTVRFd0FBQUFBQUFBQUFBSnljbkFEOS9mMEEvLy8vQVAvLw0KL3dCcGFX
a0FCQVFFQUFBQUFBQUhCd2NBQUFBQUFCa1pHUUQyOXZZQS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBNU9Uaw0KQVBUMDlBRCsvdjRBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEE3L1gwQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KWEZ4Y0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0K
Ly84QTRPRGdBRTVPVGdBQUFBQUFBQUFBQUFBQUFBQUpDUWtBZzRPREFQLy8vd0QvLy84QS8vLy9B
UC8vL3dEYTJ0b0FTVWxKQUFBQQ0KQUFBRUJBUUFBUUVCQUFBQUFBQmxaV1VBNStmbkFQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dDcnE2c0FIUjBkQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQ3lzcklBLy8v
L0FOL2Yzd0FhR2hvQUFBQUFBQUFBQUFBRUJBUUFBQUFBQUFBQUFBRFoyZGtBL2YzOUFQLy8vd0Qv
Ly84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BSFYxZFFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQkFR
RUFOWFYxUUQvLy84QTkvZjNBQUFBQUFBQQ0KQUFBQUJBUUVBQUFBQUFBSkNRa0ExdGJXQVAvLy93
RC8vLzhBLy8vL0FPam82QUE0T0RnQUFBQUFBQUVCQVFBQUFBQUFEdzhQQUkrUA0KandELy8vOEE4
dkx5QUhwNmVnQUFBQUFBQUFBQUFBQUFBQUFBQUFBQVZsWldBUG41K1FELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBOHZMeUFHRmhZUUFBQUFBQUJBUUVBQU1EQXdBRUJBUUFo
NGVIQUVwS1NnQUFBQUFBQUFBQUFGTlRVd0RrNU9RQQ0KLy8vL0FQLy8vd0JSVVZFQUFBQUFBQUlD
QWdBRUJBUUFBUUVCQUJJU0VnQ2pvNk1Bc2JHeEFMT3pzd0NwcWFrQXJhMnRBS3lzckFDdA0KcmEw
QXVibTVBS3lzckFDd3NMQUFwcWFtQU1iR3hnRC8vLzhBLy8vL0FQLy8vd0QvLy84QTd1M3RBQUFB
QUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFQRHM4QUxDNnNBQ2pxS01BbmFlakFKNmlud0NrcEtv
QXI2bXZBTDI0dkFEZDJOZ0E4L1B6QVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBNE9EZ0FF
MU5UUUFBQUFBQUFBQUFBQUFBQUFBRUJBUUFjM056QVAvLy93RC8vLzhBLy8vL0FQLy8vd0RQejg4
QQ0KUGo0K0FBQUFBQUFCQVFFQUFRRUJBQUFBQUFCcmEyc0E3Ky92QVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0MwdExRQUlDQWdBQUFBQUFBQg0KQVFFQUFBQUFBQUFBQUFDcHFha0EvLy8vQUtlbnB3QVJF
UkVBQUFBQUFBQUFBQUFEQXdNQUFBQUFBQm9hR2dEMzkvY0EvLy8vQVA3Kw0KL2dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FOWFYxUUJnWUdBQWVYbDVBSlNVbEFDT2pvNEFxYW1wQU92cjZ3RC8v
LzhBOXZiMg0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFRRUJBQTI5dmJBUC8vL3dELy8vOEEvLy8v
QU9ucDZRQTdPenNBQUFBQUFBQUFBQUFBQUFBQQ0KRHc4UEFJNk9qZ0QvLy84QTh2THlBSHA2ZWdB
QUFBQUFBQUFBQUFFQkFRQUFBQUFBUzB0TEFPcnE2Z0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8v
Ly9BUC8vL3dELy8vOEF3c0xDQUM4dkx3QUFBQUFBQXdNREFBQUFBQUFqSXlNQXo4L1BBSUdCZ1FB
SkNRa0FBQUFBQUJJUw0KRWdERnhjVUEvLy8vQVAvLy93Qk1URXdBQUFBQUFBSUNBZ0FBQUFBQUFn
SUNBQUFBQUFBZkh4OEFIaDRlQUNJaUlnQWFHaG9BSEJ3Yw0KQUNnb0tBQWRIUjBBSWlJaUFCY1hG
d0FqSXlNQURnNE9BR1ptWmdELy8vOEEvLy8vQVAvLy93RC8vLzhBNysvdkFBQUFBQUFBQkFBQQ0K
QUFBQUFBQUFBQUFBQUFBQUF3a0RBQjhvSGdBWEdoY0FFeUVYQUJNY0ZBQVpGeDBBSkJza0FDc29L
Z0JGUVVFQVcxdGJBTGk0dUFELw0KLy84QS8vLy9BUC8vL3dELy8vOEE0T0RnQUU1T1RnQUFBQUFB
QXdNREFBQUFBQUFBQUFBQVhGeGNBUDM5L1FELy8vOEEvLy8vQVAvLw0KL3dEUzB0SUFRRUJBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUJvYUdnQTcrL3ZBUC8vL3dELy8vOEErL3Y3QVAvLy93Q3dzTEFB
SkNRaw0KQUFBQUFBQUVCQVFBQUFBQUFBQUFBQUNzckt3QS8vLy9BSDUrZmdBSUNBZ0FCUVVGQUFJ
Q0FnQUFBQUFBQUFBQUFDNHVMZ0QxOWZVQQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RHY3KzhBL2YzOUFQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QTkvZjNB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQU5EUTBBME5EUUFQLy8vd0QvLy84QS8vLy9BT2pvNkFBMk5q
WUFBQUFBQUFFQg0KQVFBQUFBQUFEdzhQQUpDUWtBRC8vLzhBOC9QekFJQ0FnQUFBQUFBQUFBQUFB
QU1EQXdBQUFBQUFPam82QU5YVjFRRC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QWlvcUtBQVFFQkFBQUFBQUFBUUVCQUFBQUFBQlVWRlFBNit2ckFLNnVyZ0FiR3hzQQ0KQUFB
QUFBQUFBQUNPam80QStQajRBUC8vL3dCU1VsSUFBQUFBQUFBQUFBQUVCQVFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFZR0JnQUFBQUFBQUFB
QUFGMWRYUUQvLy84QS8vLy9BUC8vL3dELy8vOEE5ZlgxQUFBQQ0KQUFBQUFnQUFBQUFBQUFBQUFB
QUFBQUFBQUFJQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQkFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QQ0KQUNvcUtnQ1BqNDhBK1BqNEFQLy8vd0QvLy84QTRPRGdBRTFOVFFBQUFBQUFCQVFFQUFNREF3
QUFBQUFBTnpjM0FOTFMwZ0QvLy84QQ0KLy8vL0FQLy8vd0RsNWVVQVUxTlRBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQmpZMk1BNit2ckFQLy8vd0QvLy84QS9QejhBUC8vL3dDYg0KbTVzQUdCZ1lBQUFB
QUFBRUJBUUFBQUFBQUFBQUFBQzV1YmtBLy8vL0FHbHBhUUFEQXdNQUFBQUFBQUFBQUFBRUJBUUFB
QUFBQURZMg0KTmdEMTlmVUEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RDUrZmtBLy8vLw0KQVAvLy93RC8vLzhBOWZYMUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBSkNRa0F6YzNOQVAvLy93RC8vLzhBLy8vL0FPZm41d0F5TWpJQQ0KQUFBQUFB
QUFBQUFBQUFBQUR3OFBBSTZPamdELy8vOEE4L1B6QUg1K2ZnQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUhoNGVBS3VycXdELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RHQ3ZTBBV0ZoWUFB
QUFBQUFCQVFFQUFBQUFBQUFBQUFDQmdZRUEvLy8vQU9MaQ0KNGdBMU5UVUFBQUFBQUFBQUFBQktT
a29BNGVIaEFQLy8vd0JqWTJNQUJ3Y0hBQUFBQUFBQ0FnSUFBQUFBQUEwTkRRQXpNek1BUmtaRw0K
QURzN093QkNRa0lBUER3OEFFWkdSZ0FoSVNFQUJBUUVBQWNIQndBQUFBQUFBQUFBQUlDQWdBRC8v
LzhBLy8vL0FQLy8vd0QvLy84QQ0KOWZYMUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFFQkFRQURBd01BQVFFQkFBSUJBZ0FBQUFBQUFBQUFBQWNGQlFBQQ0KQUFBQUFBQUFBQUFBQUFB
ZEhSMEFxS2lvQVAvLy93RC8vLzhBM3Q3ZUFFcEtTZ0FBQUFBQUJBUUVBQVFFQkFBQUFBQUFEdzhQ
QUhsNQ0KZVFEejgvTUEvLy8vQVAvLy93RC8vLzhBZW5wNkFBQUFBQUFCQVFFQUFnSUNBQUFBQUFC
S1Nrb0EyTmpZQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93QjlmWDBBQndjSEFBQUFBQUFBQUFBQUFB
QUFBQmdZR0FEUTBOQUEvLy8vQUZoWVdBQUJBUUVBQUFBQUFBQUFBQUFDQWdJQQ0KQUFBQUFFQkFR
QUQyOXZZQS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QzOS9jQS8v
Ly9BUC8vL3dENw0KKy9zQS8vLy9BUC8vL3dELy8vOEE5L2YzQUFBQUFBQUFBQUFBQUFBQUFBSUNB
Z0FKQ1FrQTA5UFRBUC8vL3dELy8vOEEvLy8vQU9qbw0KNkFBNU9Ua0FBQUFBQUFBQUFBQUFBQUFB
RUJBUUFKQ1FrQUQvLy84QTgvUHpBSUNBZ0FBQUFBQUFBUUVCQUFZR0JnQUNBZ0lBQUFBQQ0KQUZO
VFV3RGQzZDBBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dDOHZMd0FMUzB0QUFBQUFBQUNBZ0lB
QUFBQUFCQVFFQUN4c2JFQQ0KLy8vL0FQLy8vd0JoWVdFQUFBQUFBQUFBQUFBVkZSVUF6czdPQVAv
Ly93Q25wNmNBRmhZV0FBQUFBQUFBQUFBQUFBQUFBQTRPRGdERA0KdzhNQTNOemNBTkhSMFFEWDE5
Y0ExZFhWQU9IaDRRQmVYbDRBQVFFQkFBUUVCQUFBQUFBQUFBQUFBTGEydGdELy8vOEEvLy8vQVAv
Lw0KL3dELy8vOEE3T3pzQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQ0lpSWdBRkJR
VUFGQlFVQUJFUkVRQUJBUUVBQUFBQQ0KQUFBQUFBQUJBUUVBQlFVRkFBQUFBQUFBQUFBQVBqNCtB
T1BqNHdELy8vOEEzdDdlQUVwS1NnQUFBQUFBQVFFQkFBQUFBQUFBQUFBQQ0KQUFBQUFCZ1lHQUJr
WkdRQW5KeWNBTUhCd1FELy8vOEFucDZlQUJVVkZRQUVCQVFBQkFRRUFBQUFBQUFkSFIwQXVibTVB
UC8vL3dELw0KLy84QS8vLy9BUDcrL2dCYVdsb0FBQUFBQUFBQUFBQURBd01BQUFBQUFGUlVWQURu
NStjQS8vLy9BRmRYVndBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUQwOVBRRDI5dllBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RDcrL3NBLy8vLw0KQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS9QejhBQUFBQUFBQUFBQUFCZ1lHQUFBQUFBQUpDUWtBMXRi
V0FQLy8vd0QvLy84QQ0KLy8vL0FPbnA2UUE4UER3QUFBQUFBQUFBQUFBQUFBQUFEdzhQQUk2T2pn
RC8vLzhBOC9QekFIOS9md0FBQUFBQUFBQUFBQUlDQWdBQg0KQVFFQUFBQUFBQXdNREFCSVNFZ0Fq
bzZPQUxTMHRBRG41K2NBLy8vL0FQLy8vd0NEZzRNQUFRRUJBQUFBQUFBQkFRRUFBQUFBQUVGQg0K
UVFEVjFkVUEvLy8vQVAvLy93Q2dvS0FBRnhjWEFBQUFBQUFBQUFBQWtKQ1FBUDM5L1FEczdPd0FL
eXNyQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQzF0YlVBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dBa0pDUUFBZ0lDQUFJQ0FnQUFBQUFBQUFBQUFQWDE5UUQvLy84QQ0KLy8vL0FQLy8vd0QvLy84
QThmSHhBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBUWtKQ0FOdmIyd0RBd01BQXg4ZkhBTWZI
eHdDLw0Kdjc4QWdJQ0FBQTBORFFBQUFBQUFBZ0lDQUFBQUFBQUFBQUFBQ3dzTEFJdUxpd0QvLy84
QTRlSGhBRkJRVUFBQUFBQUFBQUFBQUFBQQ0KQUFBQ0FnSUFDQWdJQUFBQUFBQUZCUVVBRFEwTkFG
cGFXZ0RuNStjQTE5ZlhBRUpDUWdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBY25KeQ0KQVBmMzl3RC8v
LzhBLy8vL0FNTEN3Z0FyS3lzQUFBQUFBQWtKQ1FBRUJBUUFBQUFBQUttcHFRRC8vLzhBLy8vL0FH
bHBhUUFKQ1FrQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQzh2THdEMTlmVUEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBKy92N0FBQUFBQUFBQUFBQUFnSUNBQUFBQUFBTEN3c0EzZDNkQVAvLw0KL3dE
Ly8vOEEvLy8vQU9qbzZBQTBORFFBQUFBQUFBQUFBQUFBQUFBQURnNE9BSXVMaXdELy8vOEE4dkx5
QUhoNGVBQUFBQUFBQmdZRw0KQUFNREF3QUFBQUFBQXdNREFBQUFBQUFEQXdNQUVCQVFBRDQrUGdD
OHZMd0EvLy8vQU9ucDZRQlpXVmtBQUFBQUFBSUNBZ0FDQWdJQQ0KQUFBQUFIbDVlUUQwOVBRQS8v
Ly9BUC8vL3dEaTR1SUFPVGs1QUFBQUFBQUFBQUFBUTBOREFPTGk0Z0QvLy84QWQzZDNBQXNMQ3dB
RA0KQXdNQUFRRUJBQUFBQUFBek16TUE1ZVhsQVAvLy93RC8vLzhBLy8vL0FKK2Zud0FDQWdJQUJ3
Y0hBQUFBQUFBQUFBQUFUVTFOQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBOWZYMUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFXMXRiQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhB
OC9QekFJMk5qUUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUVWRlJRRC8vLzhBNGVIaEFFeE1U
QUFBQUFBQQ0KQUFBQUFBQUFBQUFNREF3QUZoWVdBQUFBQUFBQkFRRUFBQUFBQURzN093RFMwdElB
Ly8vL0FKbVptUUFQRHc4QUFBQUFBQUFBQUFBQQ0KQUFBQURRME5BRnRiV3dDR2hvWUFoWVdGQURv
Nk9nQUJBUUVBQWdJQ0FBWUdCZ0FBQUFBQVMwdExBT1hsNVFELy8vOEEvLy8vQUlxSw0KaWdBT0Rn
NEFBQUFBQUFBQUFBQUZCUVVBQUFBQUFCWVdGZ0QwOVBRQS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vLw0KQUt5c3JBQ1dscFlBbnA2ZUFMYTJ0Z0REdzhNQXg4ZkhBUFgxOVFELy8v
OEErdnI2QUFBQUFBQUFBQUFBQmdZR0FBQUFBQUFLQ2dvQQ0KMHRMU0FQLy8vd0QvLy84QS8vLy9B
T0xpNGdBN096c0FBQUFBQUFVRkJRQUFBQUFBRkJRVUFJcUtpZ0QvLy84QTgvUHpBSHg4ZkFBQQ0K
QUFBQUFnSUNBQU1EQXdBS0Nnb0FEUTBOQUFJQ0FnQUFBQUFBQUFBQUFCMGRIUUN0cmEwQS8vLy9B
TGk0dUFBbUppWUFBQUFBQUFRRQ0KQkFBQUFBQUFEdzhQQUt5c3JBRC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QVlHQmdBQUFBQUFBQUFBQUFBQUFBQUwrL3Z3RC8vLzhBNXVibQ0KQUM4dkx3QUFBQUFBQUFB
QUFBQUFBQUFBQUFBQVB6OC9BSFoyZGdDcXFxb0FmWDE5QUJVVkZRQUFBQUFBQVFFQkFBQUFBQUFa
R1JrQQ0KM2QzZEFQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEE5ZlgxQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQVQwOVBBUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQU9EZzRB
QW1KaVlBQUFBQUFBQUFBQUFBQUFBQUFBQUFBREV4TVFEMzkvY0E1ZVhsQUZCUQ0KVUFBQUFBQUFD
UWtKQUFBQUFBQTFOVFVBWGw1ZUFCVVZGUUFBQUFBQUFBQUFBRU5EUXdEWTJOZ0EvLy8vQVBMeThn
Q0JnWUVBQ3dzTA0KQUFBQUFBQURBd01BQWdJQ0FBVUZCUUFWRlJVQUVSRVJBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQTNOemNBenM3T0FQLy8vd0QvLy84QQ0KLy8vL0FMQ3dzQUFURXhNQUFBQUFBQVVG
QlFBREF3TUFBQUFBQUFJQ0FnRHE2dW9BLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84
QS8vLy9BRXhNVEFBTEN3c0FFeE1UQUJvYUdnQWRIUjBBSEJ3Y0FNbkp5UUQvLy84QS8vLy9BQUFB
QUFBQUFBQUFBZ0lDQUFBQQ0KQUFBSkNRa0ExTlRVQVAvLy93RC8vLzhBLy8vL0FPWGw1UUExTlRV
QUFBQUFBQUVCQVFBQUFBQUFFUkVSQUpHUmtRRC8vLzhBOHZMeQ0KQUh0N2V3QUFBQUFBQUFBQUFB
QUFBQUFSRVJFQVJFUkVBREF3TUFBQUFBQUFBQUFBQUNJaUlnQ3VycTRBLy8vL0FIcDZlZ0FBQUFB
QQ0KQWdJQ0FBUUVCQUFBQUFBQU9UazVBTTdPemdELy8vOEEvLy8vQVAvLy93RC8vLzhBa3BLU0FC
WVdGZ0FBQUFBQUFBQUFBSDE5ZlFEMA0KOVBRQS8vLy9BTTdPemdBZEhSMEFBQUFBQUFVRkJRQUFB
QUFBQUFBQUFCUVVGQUFZR0JnQUJ3Y0hBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFDNnVyb0EvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QTZ1cnFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBVlZWVg0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BT3pzN0FBL1B6OEFBQUFB
QUFFQkFRQUdCZ1lBQUFBQUFETXpNd0RsNWVVQQ0KNHVMaUFFSkNRZ0FBQUFBQUFBQUFBQUFBQUFB
OVBUMEFxcXFxQUVaR1JnQUFBQUFBQUFBQUFFUkVSQURRME5BQS8vLy9BUC8vL3dEeA0KOGZFQWo0
K1BBQThQRHdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBRmhZV0FE
VDA5TUErdnI2QVAvLw0KL3dELy8vOEEvLy8vQU9UazVBQWhJU0VBQUFBQUFBRUJBUUFBQUFBQUFB
QUFBQUFBQUFDb3FLZ0EvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FCUVVG
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU9mbjV3RC8vLzhBNHVMaUFBQUFBQUFBQUFBQQ0K
QUFBQUFBQUFBQUFIQndjQTB0TFNBUC8vL3dELy8vOEEvLy8vQU9mbjV3QXZMeThBQUFBQUFBQUFB
QUFBQUFBQUNRa0pBSWFHaGdELw0KLy84QTcrL3ZBSE56Y3dBQUFBQUFBQUFBQUFBQUFBQU5EUTBB
Z1lHQkFIZDNkd0FBQUFBQUFBQUFBQ1VsSlFDM3Q3Y0EzdDdlQUVCQQ0KUUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBWFYxZEFPWGw1UUQvLy84QS8vLy9BUC8vL3dELy8vOEF4Y1hGQUN3c0xBQUFBQUFB
QUFBQQ0KQURBd01BRFcxdFlBLy8vL0FQLy8vd0ROemMwQVJVVkZBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KTEN3c0FLeXNyQUQvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBOC9QekFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQVYxZFhB
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FPYm01Z0FSRVJFQUFBQUFBQVlHQmdBQkFR
RUFBQUFBQUM4dg0KTHdEcTZ1b0E4Zkh4QUppWW1BQmVYbDRBWDE5ZkFGOWZYd0NGaFlVQTcrL3ZB
TXJLeWdCV1ZsWUFDZ29LQUV0TFN3RGEydG9BLy8vLw0KQVAvLy93RC8vLzhBK1BqNEFOZlgxd0NQ
ajQ4QVNFaElBQ01qSXdBUUVCQUFIaDRlQUQ0K1BnQndjSEFBdmIyOUFPN3U3Z0QvLy84QQ0KLy8v
L0FQNysvZ0QvLy84QS8vLy9BUC8vL3dCUFQwOEFBQUFBQUFBQUFBQUFBQUFBQndjSEFBQUFBQUJV
VkZRQS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEzZDNkQUFBQUFBQUFBQUFBQ1Fr
SkFBQUFBQUFFQkFRQUVSRVJBUC8vL3dELy8vOEErdnI2QUdGaA0KWVFCeGNYRUFhbXBxQUcxdGJR
QmJXMXNBOXZiMkFQLy8vd0QvLy84QS8vLy9BUER3OEFDR2hvWUFaR1JrQUdWbFpRQnBhV2tBZFhW
MQ0KQUx1N3V3RC8vLzhBL2YzOUFMZTN0d0JWVlZVQWNYRnhBSEJ3Y0FCd2NIQUF4Y1hGQU92cjZ3
QitmbjRBRmhZV0FDa3BLUUM3dTdzQQ0KNE9EZ0FINStmZ0JpWW1JQWIyOXZBRzV1YmdCaVltSUF2
THk4QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS9QejhBSXVMaXdCcQ0KYW1vQWFtcHFBRzF0
YlFEaTR1SUEvLy8vQVAvLy93RC8vLzhBN096c0FMdTd1d0IzZDNjQU5EUTBBQlFVRkFBWkdSa0FM
aTR1QUZsWg0KV1FDd3NMQUE1ZVhsQVA3Ky9nRC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEE2K3ZyQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBWFYxZEFQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEErdnI2QUdCZ1lBQUFBQUFBQlFVRkFBSUNBZ0FNREF3QQ0KQUFBQUFF
TkRRd0QvLy84QS8vLy9BUGYzOXdEeTh2SUE4dkx5QVBMeThnRDA5UFFBLy8vL0FQLy8vd0R3OFBB
QTQrUGpBT3JxNmdEOA0KL1B3QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RDYrdm9BN3U3dUFP
am82QURsNWVVQTUrZm5BTzN0N1FEMTlmVUEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0NvcUtnQUNnb0tBQUFBQUFBQUFBQUFBQUFBQUFVRkJRQUFBQUFBbHBhVw0K
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0RzN093QVJrWkdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBYVdscEFQLy8vd0QvLy84QQ0KLy8vL0FQSHg4UUQxOWZVQTlQVDBBUFgxOVFEdjcrOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQNysvZ0QxOWZVQTgvUHpBUFB6OHdEMA0KOVBRQTlQVDBBUHI2K2dE
Ly8vOEEvLy8vQVByNitnRHc4UEFBOWZYMUFQWDE5UUR6OC9NQSsvdjdBUC8vL3dEMzkvY0E1dWJt
QU9ibQ0KNWdENCtQZ0EvZjM5QVBQejh3RHo4L01BOWZYMUFQWDE5UUR5OHZJQSsvdjdBUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVBYMTlRRDA5UFFBOVBUMEFQSHg4UUQ5L2YwQS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RDI5dllBNit2ckFPYm01Z0RuNStjQQ0KNnVycUFQSHg4
UUQvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QTZl
bnBBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFKU1VsQUk2T2pnQ0RnNE1BZTN0N0FIcDZl
Z0JoWVdFQVRVMU5BQUFBQUFBQUFBQUFCQVFFQUE0Tw0KRGdBQUFBQUFFaElTQUoyZG5RRC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBV0ZoWUFBQUFBQUFBQUFBQUNBZ0lBQUFBQUFBRA0KQXdNQUFRRUJBR0ppWWdDa3BL
UUFzckt5QUlLQ2dnQTNOemNBQUFBQUFBY0hCd0FIQndjQUVoSVNBQUFBQUFBQUFBQUEzTnpjQVAv
Lw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBNk9qbw0KQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQTBORFFBQkFRRUFBZ0lDQUFFQkFRQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQU9UazVBUGo0K0FELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0K
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEE2
dXJxQUNNakl3QUFBQUFBQUFBQQ0KQUFnSUNBQUFBQUFBQUFBQUFBQUFBQUFQRHc4QUJ3Y0hBQXdN
REFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUI3ZTNzQQ0KLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QTgvUHpBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQ0FnSUFBQUFBQUFHQmdZQUFBQUFBQWNIQndBRkJRVUFBQUFBQUFjSA0KQndB
QkFRRUFDQWdJQUFBQUFBQVhGeGNBNGVIaEFQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BTURBd0FB
Zg0KSHg4QUFBQUFBQUFBQUFBUUVCQUFDQWdJQUFjSEJ3QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUVwSw0KU2dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8v
d0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBOWZYMUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFB
RDgvUHdEYTJ0b0EvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0K
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RGQzZDBBTGk0
dUFBQUFBQUFBQUFBQUJnWUdBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQQ0KWFYxZEFQLy8vd0QvLy84QS8vLy9BUFQwOUFELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84
QS8vLy9BUC8vL3dELy8vOEEyTmpZQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFGQlFVQUN3c0xBQnVibTRBeGNYRkFQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQUxpNHVBQlhW
MWNBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUd0cg0KYXdEUHo4OEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQNysvZ0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8v
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dE
Ly8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8v
Ly9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQVDA5
QUQvLy84QS8vLy9BT3pzN0FEeTh2SUEvUHo4QVB2Nyt3RC8vLzhBK3ZyNkFQcjYrZ0R4OGZFQQ0K
Ly8vL0FQbjUrUUR5OHZJQS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RCsvdjRBOXZiMkFQMzkv
UUQ0K1BnQS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAv
Ly93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhB
Ly8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEE5L2YzQUxp
NHVBQzR1TGdBbzZPakFMVzF0UURJeU1nQQ0KNysvdkFQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8v
OEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9B
UC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0Qv
Ly84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8v
L0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUDM5L1FEMzkvY0EvLy8vQVAvLy93RC8vLzhBLy8v
Lw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93
RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEv
Ly8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8v
L3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0KQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QQ0KLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84
QS8vLy9BUC8vL3dELw0KLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vL0FQ
Ly8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLw0KL3dELy8vOEEvLy8vQVAvLy93RC8v
LzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BUC8vL3dELy8vOEEvLy8vQVAvLy93RC8vLzhBLy8vLw0K
QVAvLy93RC8vLzhBLy8vL0FQLy8vd0QvLy84QS8vLy9BQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQQ0KQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFB
QUFBQUFBQUFBQUFBQUFBQUFBQUFRQUQ3ZndCQTNhTlhSYk1NQWdFQw0KTndFQUFBQUFBQUFBUUFE
OGZ3QkEzYU5YUmJNTUF3RDlmd0FBQUFBZUFBRXdBUUFBQUNRQUFBQlFhV04wZFhKbElDaEVaWFpw
WTJVZw0KU1c1a1pYQmxibVJsYm5RZ1FtbDBiV0Z3S1FBREFQcC9BQUFBQUFNQUZEY0FBQUFBQ3dE
K2Z3QUFrM3dMQVA5L0FBQWhBQUlCQ2pjQg0KQUFBQUN3QUFBQ3FHU0liM0ZBTUtBd0lCQU4vVw0K
BDENCi0tLS0tLT1fTmV4dFBhcnRfMDAwXzAwMzdfMDFDODhBNzAuODI0MEUzODAtLQ0KAAAAAAAA
oIIOEjCCAwMwggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQ
cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWdu
IFRydXN0IE5ldHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQ
cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZl
cmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWdu
IFRydXN0IE5ldHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8
DyEI8Zzbl+ma/MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTH
qQKkQsIjT0rY8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93
AgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbq
Lwn0ytfqpSuV9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3Nq
VCI0ZC22FptZW7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhB3lLeh
2K9TSN0bRHs7wmmDMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy
aVNpZ24sIEluYy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3Ig
YXV0aG9yaXplZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0w
MTA0MjQwMDAwMDBaFw0xMTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQg
Q29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg
b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0Ns
YXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3Jh
dGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wHBTCwUTa0hbaHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRV
IWAdYDgw28tQ+Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7M
DoEdBjGY1MyY5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYL
YIZIAYb4RQEHAQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAL
BgNVHQ8EBAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ
cml2YXRlTGFiZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNv
bS9wY2EyLWcyLmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEF
BQADgYEAIC20InJbjxHbFARQiJa3lZPqTCrVfV5vngYprhEGanLYRa9c6bf2tbkHdxBelAHWJaLS
zZW6NF4K3fkqNjtRHaR16iUovo4pRS6hJvUywmKS38AK5V6iAMcYf1n57MF3WcG2ZVeI97IUd9cY
B0G8dY+vGp77WZNqiQC9vwkPTzwwggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqG
SIb3DQEBBQUAMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMW
VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v
d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2
aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9u
IEF1dGhvcml0eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdI
ZXdsZXR0LVBhY2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBs
b3llZXMxDzANBgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqG
SIb3DQEJARYXbWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAPgf5XSwMrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdH
twZVTEQoSiDTw9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HA
hI+eUdtGuHMh+gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5j
aGV6QGhwLmNvbYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8B
Af8EBAMCBaAwHwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGS
nBG2RoqTHc7TYsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNp
Z24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/
BAwwCgYIKwYBBQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggr
BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYX
SGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMg
bm90IGNvcnJlc3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRl
LiBJc3N1ZWQgdG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3Mg
Q1BTIGluY29ycC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggr
BgEFBQcBAQSCASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24u
Y29tMIHxBggrBgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0
aW9uIEF1dGhvcml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3Jp
YmVyIENBMTowOAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYShjKTAxMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXds
ZXR0LVBhY2thcmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggq
hkiG9w0DAgICAEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GB
AH50gDgTOqzgNw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gI
psf/vW8avKenCa+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7
LGkhUcjj2j5vHoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2Fy
ZCBDb21wYW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt
cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMn
Q2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJv
cmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIa
BQCgggLgMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDMyMDE2
NTUyMFowIwYJKoZIhvcNAQkEMRYEFEvJ4LGRJJ4qDDHhjXrDFq3UUlYSMGcGCSqGSIb3DQEJDzFa
MFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHi
MSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWdu
LmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2Ny
aWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQ
CkMamb4agmBpCN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXds
ZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG
A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDEx
MDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UE
AxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzM
aTANBgkqhkiG9w0BAQEFAASBgH1CP21TvnxfX46kS6VyyQAVfJi6IZO1Wv2NR0l0zXH/FifKaac/
7o3VuLyK99dFNcqGIWRl9/Kk5cAkh7Ty2xMoPkKBnKaKO7z34rl1usbKPcr79VqVbDG2/nyTnplJ
cFJQ7tNR6r/bHwzmATRaqcINyRCt0R4gWUBvWf+emLvJAAAAAAAA

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


Envelope-to: [e-mail]
Delivery-date: Thu, 20 Mar 2008 16:40:55 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 20 Mar 2008 12:38:36 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <000f01c88aa8$d858dba0$1f0a0a0a@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciKn4xm8ty5zqCISRyEMXDGEca5YwACJTiw

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. 



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


Envelope-to: [e-mail]
Delivery-date: Thu, 20 Mar 2008 15:28:30 +0000
From: Stefan Winter <[e-mail]>
Organization: Fondation RESTENA
To: [e-mail]
Subject: Re: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 20 Mar 2008 16:27:26 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1702924.Uq3jKHCrxv"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

--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: [e-mail] =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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQBH4oJi+jm90f8eFWYRAtENAJ93OHdZmAayVvb4Yv0GC2t/2rHumQCdGFXE
dArqiidJ6m83kxbcZzds64Q=
=rKF1
-----END PGP SIGNATURE-----

--nextPart1702924.Uq3jKHCrxv--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 20 Mar 2008 06:06:13 +0000
From: Mudit Goel <[e-mail]>
To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Wed, 19 Mar 2008 23:05:29 -0700
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item 
Thread-Topic: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item 
Thread-Index: AciKUGY2X5d2k/MYRSy6O3/8nyRWaQ==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_456A5146F9319946A179B523B9FC91D60D9E28CBC5NAEXMSGC114re_"
MIME-Version: 1.0

--_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_--

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


Envelope-to: [e-mail]
Delivery-date: Wed, 19 Mar 2008 17:06:44 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Wed, 19 Mar 2008 10:04:32 -0700
Message-ID: <[e-mail]>
Thread-Topic: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Thread-Index: AciI+4VNmdt/HWadRXW9P8XdQbBvhQAxM7OA
From: "Matthew Gast" <[e-mail]>
To: <[e-mail]>

+1

Matthew

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Mike McCauley
Sent: Tuesday, March 18, 2008 6:17 AM
To: [e-mail]
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                               [e-mail]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia
http://www.open.com.au
Phone [phone]                       Fax   [phone]

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.

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

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


Envelope-to: [e-mail]
Delivery-date: Tue, 18 Mar 2008 13:18:49 +0000
From: Mike McCauley <[e-mail]>
To: [e-mail]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Tue, 18 Mar 2008 23:17:27 +1000
User-Agent: KMail/1.8.2
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>

I support taking on RADSEC as a WG work item.


-- 
Mike McCauley                               [e-mail]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone [phone]                       Fax   [phone]

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.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Mar 2008 19:17:34 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: <[e-mail]>
Subject: Consensus at IETF 71 on RADIUS Extended Attributes
Date: Mon, 17 Mar 2008 12:17:05 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01C88828.D08AB600"

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


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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Mar 2008 14:41:57 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: <[e-mail]>
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Mon, 17 Mar 2008 07:41:18 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

I support taking on RADSEC as a WG work item.

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

 I support this.

--------------------------------------------------------------------------------
From: "Klaas Wierenga" <[e-mail]>
Sent: Saturday, March 15, 2008 7:55 AM
To: <[e-mail]>
Cc: <[e-mail]>
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: [e-mail] ; [e-mail]
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: [e-mail] [mailto:[e-mail]] On 
Behalf Of [e-mail]
Sent: Friday, March 14, 2008 11:10 AM
To: [e-mail]
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. 


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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Mar 2008 13:46:39 +0000
Date: Mon, 17 Mar 2008 13:45:42 +0000 (GMT)
From: David Mitton <[e-mail]>
Reply-To: [e-mail]
To: [e-mail]
Message-ID: <674181075.31221205761551672.JavaMail.mail@webmail04>
Subject: List test
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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

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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Mar 2008 07:24:43 +0000
From: Stefan Winter <[e-mail]>
Organization: Fondation RESTENA
To: [e-mail]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Mon, 17 Mar 2008 08:23:46 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1233012.Pi5lrI9jgL"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

--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: [e-mail] =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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQBH3hyG+jm90f8eFWYRAty0AJ9QwhDHyfFRjzCMEoIqBEqCBAkIWwCeLBh4
G2rx+LHa3vKBKm4U3XOmSm8=
=zq8m
-----END PGP SIGNATURE-----

--nextPart1233012.Pi5lrI9jgL--

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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Mar 2008 06:06:00 +0000
Message-ID: <[e-mail]>
Date: Mon, 17 Mar 2008 07:01:44 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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


Envelope-to: [e-mail]
Delivery-date: Mon, 17 Mar 2008 01:21:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SjxuvuEYsW2QDO8Smwa1nKkok8kVKYDn36ecz6Vk7/U=; b=LxpeYBEuPJFnKYTLdaksDpApIaLn0L+I/Qr/DPdTVQoHwqHAqkQPCN1fObrldOHsuKvX9Jvj6O0IDdmrdq9GWOuDVJ5i8aTJCZKFeFE6po8FU0hJww1puMxvQMePXOptLBrfoe/v8ovP9ZeebdFh3HlRjBpwQ/lArZdQvpBMPkc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=d/mC91tg2J7TL84LVNcVJswb2492H/+MxKBznwRqaBXOqxgZQnRR5rmG2nnvLjww3GLpwshkhoMxIrCeZFBVSCdiX8PxSSjTK48+JpgO07jVwvW/eCulAyRrTxqUt83MOAtKvD5uid+M3ZYabG2EhavgQUSRz68K9WU1mpqFNMA=
Message-ID: <[e-mail]>
Date: Sun, 16 Mar 2008 18:21:17 -0700
From: "Clint Chaplin" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I support this.

On 3/14/08, [e-mail] <[e-mail]> 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

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


Envelope-to: [e-mail]
Delivery-date: Sun, 16 Mar 2008 23:53:52 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Stephen Hanna'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Sun, 16 Mar 2008 19:53:09 -0400
Message-ID: <003601c887c0$e3607840$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciF5WwMSgHnkOAeQTKrz+oQvOLYNgB2OXIAAACHuVA=

[e-mail] <> 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.

...



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


Envelope-to: [e-mail]
Delivery-date: Sun, 16 Mar 2008 23:41:36 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C887BE.33BB65C2"
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Sun, 16 Mar 2008 19:35:57 -0400
Message-ID: <[e-mail]>
Thread-Topic: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Thread-Index: AciF5WwMSgHnkOAeQTKrz+oQvOLYNgB2OXIA
From: "Stephen Hanna" <[e-mail]>
To: <[e-mail]>, <[e-mail]>

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: [e-mail] [mailto:[e-mail]]
On Behalf Of [e-mail]
Sent: Friday, March 14, 2008 11:10 AM
To: [e-mail]
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> [e-mail]=20
[mailto:[e-mail]] <B>On Behalf Of=20
</B>[e-mail]<BR><B>Sent:</B> Friday, March 14, 2008 =
11:10=20
AM<BR><B>To:</B> [e-mail]<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--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Mar 2008 19:58:08 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-radext-extended-attributes-03.txt 
Message-Id: <[e-mail]>
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:     <[e-mail]>

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Mar 2008 19:28:28 +0000
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-radext-extended-attributes-02.txt 
Message-Id: <[e-mail]>
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:     <[e-mail]>

--NextPart--

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Mar 2008 14:56:27 +0000
Message-ID: <[e-mail]>
Date: Sat, 15 Mar 2008 15:55:49 +0100
From: Klaas Wierenga <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Authentication-Results: ams-dkim-1; header.From=[e-mail]; dkim=neutral

[e-mail] 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

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Mar 2008 09:44:27 +0000
Message-ID: <[e-mail]>
Date: Sat, 15 Mar 2008 10:39:56 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

[e-mail] 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.

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


Envelope-to: [e-mail]
Delivery-date: Sat, 15 Mar 2008 05:02:43 +0000
From: "Glen Zorn" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Sat, 15 Mar 2008 01:01:20 -0400
Message-ID: <006601c88659$9c210480$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciF5hpIG4IdwDx2RsiQpDHvluIQ5gAc3bJA

[e-mail] <> 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.



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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Mar 2008 16:13:37 +0000
Date: Fri, 14 Mar 2008 12:12:42 -0400
From: Yoshihiro Ohba <[e-mail]>
To: Lakshminath Dondeti <[e-mail]>
Cc: [e-mail], Tim Polk <[e-mail]>, [e-mail], [e-mail], "'eap-WG'" <[e-mail]>
Subject: Re: [eap] [HOKEY] ERX fraud issue
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)

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, [e-mail] 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
> > [e-mail]
> > 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
> 

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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Mar 2008 15:10:07 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG Consensus call on acceptance of RADSEC as a work item
Date: Fri, 14 Mar 2008 08:09:31 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0118_01C885AA.BB6852D0"

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


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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Mar 2008 12:32:33 +0000
Message-ID: <[e-mail]>
Date: Fri, 14 Mar 2008 13:28:43 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: 'eap-WG' <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [HOKEY] ERX fraud issue
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Mar 2008 11:58:18 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_87a1e66f-8fdd-4385-a35c-fcdc94aa87da_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>
CC: 'eap-WG' <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [HOKEY] ERX fraud issue
Date: Fri, 14 Mar 2008 04:57:33 -0700
MIME-Version: 1.0

--_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_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 14 Mar 2008 09:57:12 +0000
Message-ID: <[e-mail]>
Date: Fri, 14 Mar 2008 10:52:37 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: [e-mail]
CC: 'eap-WG' <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [HOKEY] ERX fraud issue
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

[e-mail] 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.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 23:35:27 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>, "'Lakshminath Dondeti'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Charles Clancy'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 13 Mar 2008 19:33:48 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <002f01c88562$b06a8800$091716ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciFYVEobo92qnlVTHaWcPTCGzR/6AAAAXOA

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



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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 23:20:39 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "'Lakshminath Dondeti'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, "'Charles Clancy'" <[e-mail]>, <[e-mail]>
Subject: Re: draft-gaonkar-radext-erp-attrs-03
Date: Thu, 13 Mar 2008 16:20:27 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

> 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? 
 

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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 23:03:48 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: "Alan DeKok" <[e-mail]>
Cc: "'eap-WG'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: [HOKEY] ERX fraud issue
Date: Thu, 13 Mar 2008 16:03:28 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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


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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 19:11:14 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT session materials
Date: Thu, 13 Mar 2008 15:09:33 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <000801c8853d$c60b2ea0$091716ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciFPcWiArr8iyPbT+2uVU1f7PU4Xg==

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:

[e-mail]



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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 18:54:50 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG session agenda for IETF-71 (final)
Date: Thu, 13 Mar 2008 14:52:31 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <000001c8853b$652c5cf0$091716ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciFO2Ryr3pvbM7wRt6OHka89Cvgaw==

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



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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 15:04:15 +0000
Message-ID: <[e-mail]>
Date: Thu, 13 Mar 2008 15:59:54 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: 'eap-WG' <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [HOKEY] ERX fraud issue
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 14:21:54 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_c8d6ec3d-b615-4b60-b3f3-7eafd34ca75b_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>
CC: 'eap-WG' <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [HOKEY] ERX fraud issue
Date: Thu, 13 Mar 2008 07:20:25 -0700
MIME-Version: 1.0

--_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_--

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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 09:06:34 +0000
Message-ID: <[e-mail]>
Date: Thu, 13 Mar 2008 10:02:02 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: [e-mail]
CC: 'eap-WG' <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [HOKEY] ERX fraud issue
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

[e-mail] 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.

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


Envelope-to: [e-mail]
Delivery-date: Thu, 13 Mar 2008 03:34:15 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: New ID on Crypto-Agility Requirements
Date: Wed, 12 Mar 2008 23:31:56 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <006801c884ba$ca0de1b0$091716ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciEusm6vYayPlK6SZyHc/9S8ACJXQ==

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



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


Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 21:43:05 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: "'eap-WG'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: ERX fraud issue
Date: Wed, 12 Mar 2008 14:43:03 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0142_01C8844F.60346B30"

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


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


Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 21:36:59 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: "Narayanan, Vidya" <[e-mail]>, "Jari Arkko" <[e-mail]>, "Dondeti, Lakshminath" <[e-mail]>, <[e-mail]>, "[e-mail]" <[e-mail]>, "Sam Hartman" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, "'eap-WG'" <[e-mail]>, <[e-mail]>
Subject: Re: [eap] Re-review of draft-ietf-hokey-erx-13.txt
Date: Wed, 12 Mar 2008 14:36:32 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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

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


Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 18:56:39 +0000
Message-ID: <[e-mail]>
Date: Thu, 13 Mar 2008 03:58:24 +0900
From: Hiroaki Sato <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Request for review of "AAA Framework for Multicasting"
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:[phone] ([phone])
FAX:[phone] ([phone])
************************************


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


Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 17:13:25 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG session agenda for IETF-71 (take two)
Date: Wed, 12 Mar 2008 13:11:17 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <001101c88464$15d7cf40$091716ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciEZBUuATPP/P7aR+GePmx1b0K5sQ==

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?



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


Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 15:03:56 +0000
Message-ID: <[e-mail]>
Date: Wed, 12 Mar 2008 17:03:03 +0200
From: Hannes Tschofenig <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Hiroaki Sato <[e-mail]>
CC: [e-mail], [e-mail],  "Romascanu, Dan \(Dan\)" <[e-mail]>, [e-mail], [e-mail],  [e-mail], [e-mail]
Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 [e-mail] 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" <[e-mail]>
>>> Sent: Tuesday, March 11, 2008 3:30 PM
>>> To: <[e-mail]>
>>> Cc: "Hiroaki Sato" <[e-mail]>; "Romascanu, Dan 
>>> (Dan)" <[e-mail]>; <[e-mail]>; 
>>> <[e-mail]>; 
>>> <[e-mail]>; <[e-mail]>
>>> 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:[phone] ([phone])
>>>>> FAX:[phone] ([phone])
>>>>> ************************************
>>>>>
>>>>> _______________________________________________
>>>>> ANCP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ancp
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


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


Envelope-to: [e-mail]
Delivery-date: Wed, 12 Mar 2008 14:48:16 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: "Jari Arkko" <[e-mail]>, "'eap-WG'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "[e-mail]" <[e-mail]>, "Sam Hartman" <[e-mail]>, <[e-mail]>
Subject: Re-review of draft-ietf-hokey-erx-13.txt
Date: Wed, 12 Mar 2008 07:47:23 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C88415.4ED969B0"

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


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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Mar 2008 23:48:08 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: "Hannes Tschofenig" <[e-mail]>, <[e-mail]>
Cc: "Hiroaki Sato" <[e-mail]>, "Romascanu, Dan \(Dan\)" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: [ANCP] mboned multiaa-framework reflecting the ancp framework draft, request for review
Date: Tue, 11 Mar 2008 16:47:23 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
Sent: Tuesday, March 11, 2008 3:30 PM
To: <[e-mail]>
Cc: "Hiroaki Sato" <[e-mail]>; "Romascanu, Dan (Dan)" 
<[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; 
<[e-mail]>
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:[phone] ([phone])
>> FAX:[phone] ([phone])
>> ************************************
>>
>> _______________________________________________
>> ANCP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ancp
>>
>
> 

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


Envelope-to: [e-mail]
Delivery-date: Tue, 11 Mar 2008 13:34:36 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG session agenda for IETF-71 (first take)
Date: Tue, 11 Mar 2008 09:32:08 -0400
Organization: Elbrys Networks, Inc.
Message-ID: <002f01c8837c$4df7fbe0$091716ac@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciDfE17v43kw1hTTs2Ew0HEr02KMg==

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?



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


Envelope-to: [e-mail]
Delivery-date: Mon, 10 Mar 2008 15:48:36 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: <[e-mail]>
Subject: Review of draft-ietf-radext-management-authorization-02.txt
Date: Mon, 10 Mar 2008 08:46:19 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0075_01C8828B.35D95640"

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


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


Envelope-to: [e-mail]
Delivery-date: Sun, 09 Mar 2008 19:56:10 +0000
Message-ID: <[e-mail]>
Date: Sun, 09 Mar 2008 20:51:45 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: 'Alan DeKok' <[e-mail]>,  'Bernard Aboba' <[e-mail]>, [e-mail]
Subject: Re: Consensus call and conclusion of RADEXT WG last call on draft-ietf-radext-extended-attributes-00.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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


Envelope-to: [e-mail]
Delivery-date: Sun, 09 Mar 2008 18:23:30 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>, "'Bernard Aboba'" <[e-mail]>
Cc: <[e-mail]>
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
Message-ID: <000801c88212$60f832c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciBSN8PbI0pMJOwQfS0t2umh+w4mgAyAthw

[e-mail] <> 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?

...



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


Envelope-to: [e-mail]
Delivery-date: Sat, 08 Mar 2008 21:49:34 +0000
From: Avi Lior <[e-mail]>
To: Bernard Aboba <[e-mail]>, Alper Yegin <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Sat, 8 Mar 2008 16:49:02 -0500
Subject: RE: Re-auth failure
Thread-Topic: Re-auth failure
Thread-Index: AciAiwqs+mhXJ+cAToKEWySQTQoQOQA2eTog
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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.


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Bernard Aboba
> Sent: Friday, March 07, 2008 2:38 PM
> To: Alper Yegin; [e-mail]
> 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" <[e-mail]>
> Sent: Friday, March 07, 2008 7:48 AM
> To: <[e-mail]>
> 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
> [e-mail] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >
>
> --
> to unsubscribe send a message to
> [e-mail] with the word 'unsubscribe' in
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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


Envelope-to: [e-mail]
Delivery-date: Sat, 08 Mar 2008 21:38:57 +0000
From: Avi Lior <[e-mail]>
To: Alper Yegin <[e-mail]>, "'David B. Nelson'" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Sat, 8 Mar 2008 16:37:55 -0500
Subject: RE: Re-auth failure
Thread-Topic: Re-auth failure
Thread-Index: AciAaqrRmkCovI1PRJGtcnGbBpzWBwAAL7ZAAAHE+UAAPHtXIA==
Message-ID: <[e-mail]>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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



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


Envelope-to: [e-mail]
Delivery-date: Sat, 08 Mar 2008 18:16:23 +0000
Message-ID: <[e-mail]>
Date: Sat, 08 Mar 2008 19:12:27 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: Consensus call and conclusion of RADEXT WG last call on draft-ietf-radext-extended-attributes-00.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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


Envelope-to: [e-mail]
Delivery-date: Sat, 08 Mar 2008 17:43:23 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_e1323898-a6cc-47ef-bad6-0b9acc05171f_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
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
MIME-Version: 1.0

--_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_--

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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 19:38:39 +0000
Message-ID: <[e-mail]>
From: "Bernard Aboba" <[e-mail]>
To: "Alper Yegin" <[e-mail]>, <[e-mail]>
Subject: Re: Re-auth failure
Date: Fri, 7 Mar 2008 11:37:53 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

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" <[e-mail]>
Sent: Friday, March 07, 2008 7:48 AM
To: <[e-mail]>
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 [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 19:17:44 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 14:16:00 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <003a01c88087$ae187d80$1f0a0a0a@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciAcRTgWe5zp8dcSyWyAh1GpMz/fAAAvjXwAASjgwA=

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



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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 18:34:09 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alper Yegin'" <[e-mail]>, "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 10:33:48 -0800
Message-ID: <003a01c88081$c9a63a70$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciAcRTgWe5zp8dcSyWyAh1GpMz/fAAAvjXwAAM5FGA=

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



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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 18:27:39 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alper Yegin'" <[e-mail]>, "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 10:26:26 -0800
Message-ID: <003901c88080$c2240990$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciAaqrRmkCovI1PRJGtcnGbBpzWBwAAL7ZAAAHE+UAAA3nHcA==

[e-mail] <> 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.

...



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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 17:03:01 +0000
From: "Alper Yegin" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 19:02:40 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciAcRTgWe5zp8dcSyWyAh1GpMz/fAAAvjXw
Message-Id: <[e-mail]>

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


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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 16:54:58 +0000
From: "Alper Yegin" <[e-mail]>
To: "'David B. Nelson'" <[e-mail]>, <[e-mail]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 18:54:11 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciAaqrRmkCovI1PRJGtcnGbBpzWBwAAL7ZAAAHE+UA=
Message-Id: <[e-mail]>

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




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


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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 16:31:12 +0000
Message-ID: <[e-mail]>
Date: Fri, 07 Mar 2008 17:27:25 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (X11/20080227)
MIME-Version: 1.0
To: Alper Yegin <[e-mail]>
CC: [e-mail]
Subject: Re: Re-auth failure
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.

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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 16:06:52 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RADEXT Meeting Slot (was RE: Call for Agenda items for IETF 71 RADEXT WG meeting)
Date: Fri, 7 Mar 2008 17:06:23 +0100
Message-ID: <[e-mail]>
Thread-Topic: RADEXT Meeting Slot (was RE: Call for Agenda items for IETF 71 RADEXT WG meeting)
Thread-Index: AciAYOeMu26NgyaWQbymEMf8Kll0FQAA+vogAAIM60A=
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "David B. Nelson" <[e-mail]>, <[e-mail]>

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

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of David B. Nelson
> Sent: Friday, March 07, 2008 5:10 PM
> To: [e-mail]
> 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
> [e-mail] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 16:02:08 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Re-auth failure
Date: Fri, 7 Mar 2008 11:00:31 -0500
Organization: Elbrys Networks, Inc.
Message-ID: <001201c8806c$5f15d9f0$1f0a0a0a@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciAaqrRmkCovI1PRJGtcnGbBpzWBwAAL7ZA

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.



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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 15:49:07 +0000
From: "Alper Yegin" <[e-mail]>
To: <[e-mail]>
Subject: Re-auth failure
Date: Fri, 7 Mar 2008 17:48:20 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciAaqrRmkCovI1PRJGtcnGbBpzWBw==
Message-Id: <[e-mail]>

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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 15:11:52 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
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.
Message-ID: <000701c88065$549a9c10$1f0a0a0a@xpsuperdvd2>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AciAYOeMu26NgyaWQbymEMf8Kll0FQAA+vog

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.



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


Envelope-to: [e-mail]
Delivery-date: Fri, 07 Mar 2008 14:47:39 +0000
From: Stefan Winter <[e-mail]>
Organization: Fondation RESTENA
To: "David B. Nelson" <[e-mail]>
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
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2154255.J7eF34IJCU"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

--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: [e-mail] =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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQBH0VNe+jm90f8eFWYRAtPyAJ0cRt/1E4BpJQSRClWUddqhwSUejwCfUQAO
X0aU/KscJKZvOTpxRzpmqC0=
=WjRK
-----END PGP SIGNATURE-----

--nextPart2154255.J7eF34IJCU--

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