Subject: [HOKEY] ERX issues

From: Charles Clancy <[email-masked]>
Date: Mon, 17 Mar 2008 20:06:20 -0400

During IESG evaluation, and at the last WG meeting, the following points 
were raised.  I've opened issues to track their progress:

ERX: authorization attack
http://www.ltsnet.net:8080/hokey/issue43

ERX document needs text defining behavior when re-authing across AAA DNS 
domains, and relate that to key management domains and administrative 
domains.  As-is, a re-auth across DNS domains without performing an ERP 
bootstrap results in authorization in a new domain with no accounting 
record of an initial authentication.  This could lead to fraudulent 
charges across AAA domains.

ERX: lower layer support
http://www.ltsnet.net:8080/hokey/issue44

 From Jari's DISCUSS.  ERX needs "truth in advertising" with respect to 
how existing authenticators may deal with a new EAP code.  See:
https://datatracker.ietf.org/idtracker/draft-ietf-hokey-erx/comment/78738/

-- 
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
_______________________________________________
HOKEY mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hokey

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 17 Mar 2008 19:45:10 -0700

> charges across AAA domains.

Any proposed text?  If the domain name changes, there would be a new 
domain specific key.  Why wouldn't we write in the AAA document that 
upon ERP bootstrapping, there should be accounting start or equivalent? 
  In fact, that is what I thought should happen with no changes to ERX.

Next, procedurally, I haven't seen any AD picking this up as a DISCUSS, 
so I guess we are doing due diligence as part of the WG process and 
presumably Tim would support such a change.  Could we make sure that 
this is ok with him?

> https://datatracker.ietf.org/idtracker/draft-ietf-hokey-erx/comment/78738/

I like Glen's take on this.  Ideally, this should require no text 
changes.  Jari thinks otherwise.

regards,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 17 Mar 2008 23:09:20 -0400

> > charges across AAA domains.

I don't think this captures the problem well.  The problem in my
understanding is that a visiting AAA proxy can request a DSRK even if
the peer did not request it.  As a result, the visited domain can make
extra charge regarding the use of ERX optimization, and the home
domain does not have any evidence about the peer had ever agreed with
use of ERX in the visited domain or requested a DSRK.  I don't
understand how accounting record of an initial authentication can
solve the problem.  The accounting record can show that an initial
authentication happened in the visited domain, but it does not carry
anything about peer consent on the use of ERX with DSRK.

Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Mar 2008 09:04:05 +0100

Yoshihiro Ohba wrote:
> the peer did not request it.

  Do you mean an "AAA server in the visited network" ?

>  As a result, the visited domain can make
> use of ERX in the visited domain or requested a DSRK.

  I'm not sure how that conclusion follows from the first statement.

  Any AAA server in the accounting stream can fraudulently edit that
accounting stream.  If billing is per minute, the accounting stream can
be continued until a session timeout.  If the billing is per megabyte,
those numbers can be artificially increased.

  ERX changes nothing here.

>  I don't

  I agree.  Accounting records do not help you detect fraudulent records
sent by a visited AAA server.  But ERX does not give the visited AAA
server any new capabilities for creating fraudulent accounting records.

  Alan DeKok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 Mar 2008 04:38:09 -0400

>   Do you mean an "AAA server in the visited network" ?

Yes.

>   ERX changes nothing here.

Sure.  My point was that peer consent in DSRK key distribution has to
be made prior to accounting, and the peer consent helps validating
accounting records.  This is where KDE protocol with KDE1 and KDE4 can
really solve the problem.

> server any new capabilities for creating fraudulent accounting records.

That's right.

Yoshihiro Ohba

---

From: Charles Clancy <[email-masked]>
Date: Tue, 18 Mar 2008 07:27:22 -0400

The solution discussed in the meeting was to have ERX perform a 
bootstrap in the visited network.  This ensures there is an 
authentication record for the client in that domain before delivery of 
the DSRK.

Specific question from the meeting:

"Is peer consent a property we need to support?
Option 1: technical solution to ensure peer is active in a key 
management domain
Option 2: security considerations for reauthenticating across 
administrative domains, accept unauthenticated key distribution across 
key management domains
Room consensus: option 2"

---

From: Charles Clancy <[email-masked]>
Date: Tue, 18 Mar 2008 07:35:05 -0400

Versions of the text should probably be in both the key management 
document and also ERX.  The key management document should discuss fraud 
issues of delivering a DSRK to a domain without authorization, and 
indicate that performing a full EAP authentication or ERX bootstrap 
would address this issue.  I think there should still be some reference 
to this within the ERX document as well.

Tim, would you support adding such text to the document?

I'll work on proposed text...

Lakshminath Dondeti wrote:
>> During IESG evaluation, and at the last WG meeting, the following 
>> points were raised.  I've opened issues to track their progress:
>>
>> ERX document needs text defining behavior when re-authing across AAA 
>> DNS domains, and relate that to key management domains and 
>> administrative domains.  As-is, a re-auth across DNS domains without 
>> performing an ERP bootstrap results in authorization in a new domain 
>> with no accounting record of an initial authentication.  This could 
>> lead to fraudulent charges across AAA domains.
> 
>>  From Jari's DISCUSS.  ERX needs "truth in advertising" with respect 
>> to how existing authenticators may deal with a new EAP code.  See:

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 18 Mar 2008 08:29:49 -0400

> authentication record for the client in that domain before delivery of  

The authentication record a full authentication just provides an
evidence that the peer entered the visited domain.  It never provides
an evidence that the peer has requested the use of DSRK in the visited
domain, which opens up some security threat which can affect revenue
of operators and subscriber's bill.

It appears that my comment is going to be ignored even if several
people seem to understand the security threat.  In that case, the only
thing we could write down in the security considerations section is to
conclude that DSRK key distribution is broken?

Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Mar 2008 15:02:10 +0100

> of operators and subscriber's bill.

  How?  Please provide an example.

> conclude that DSRK key distribution is broken?

  No.  The accounting fraud issue is unrelated to DSRK key distribution.

  Alan DeKok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Mar 2008 00:47:50 -0400

>   How?  Please provide an example.

Example of DSRK distribution without peer consent: The peer
enters a visited domain.  It runs a full EAP authentication with the
home AAA server via a AAA proxy in a visited domain.  In the case of
implicit ERP bootstrapping, a DSRK key request will be inserted by the
AAA proxy in a AAA message that carries initial EAP.  In the case of
explicit ERP bootstrapping, a AAA message carrying a DSRK request will
be created by the AAA proxy and sent to the AAA server (and this AAA
message does not need to carry EAP).  In both cases, without a proof
of peer consent, the AAA proxy can create a DSRK request even if the
peer did not actually request it, and there is no way for the home AAA
server to tell whether the DSRK request was really generated upon
request by the peer or not.

Depending on service plan, the use of DSRK may require some extra
roaming charge in addition to the normal roaming charge.  The AAA
proxy that requested a DSRK without presenting a proof of peer
consent, can generate forged accounting records that indicate use of
DSRK even if the peer did not actually use it DSRK but just visited
the domain.  The home AAA server does not have a way to verify the
accounting records regarding the DSRK usage.  It can only verify that
the peer was in the visited domain by matching the authentication
record of the full EAP authentication with the accounting records.

As a result, the home domain operator may end up with paying for the
some extra charge to the visited domain operator, and the subscriber
may either deny the extra charge if (s)he realized the extra charge
for unused service (result: loss of home operator's revenue) or pay
for the extra charge if (s)he does not realize it (result: subscriber
gets more charge), both are no good.

If peer consent is supported by DSRK distribution, then the home AAA
server will have a cryptographic evidence (e.g., KDE message 1) that
the peer actually requested a DSRK, such evidence can verify
accounting records generated for the use of DSRK.

>   No.  The accounting fraud issue is unrelated to DSRK key distribution.

I believe it is related.  Please see above.

Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 Mar 2008 07:54:57 +0100

Yoshihiro Ohba wrote:
> ...  In both cases, without a proof

  Yes.  I agree.

> the domain.

  But AAA proxies can do this *today*.  They can:

  1) suppress accounting records entirely
  2) fraudulently increase session time
  3) fraudulently increase data usage

  I do not see how the addition of a DSRK adds anything *new*, and you
have not explained how it adds any new attacks.  The attack you raise
for DSRK is (2) above.  It is known, and (frankly) not a problem for
most home networks.

>  The home AAA server does not have a way to verify the

  This is exactly how accounting works today.

> accounting records generated for the use of DSRK.

  That would be good, yes.  But I do not think it is *necessary*.

  Alan DeKok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Mar 2008 09:26:58 -0400

> for DSRK is (2) above.  It is known, and (frankly) not a problem for

Actually I did not mean any of the above three.  I meant:

4) fraudulently generate accounting records that indicate the use of
Service X which requires additional charge.  

Service X is in this case ERX service within visited domain.

>   That would be good, yes.  But I do not think it is *necessary*.

Why not needed?  I have not seen a key distribution protocol that does
not provide peer consent.  While I understand that you are considering
existing AAA deployments, I am more concerned on designing a less
secure key distribution protocol in IETF.

Regards,
Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 Mar 2008 17:23:15 +0100

> Service X is in this case ERX service within visited domain.

  Visited networks and proxies can do that today, for any "additional
charge" service.  The time/bandwidth examples were just... examples.
The visited networks and proxies have *complete* control over the
accounting traffic, and can generate any kind of accounting records that
they want.

  It is up to the home network to check that the accounting records
match the service that was authorized.  Sometimes these checks are easy,
sometimes they are not.

  And this assumes that the accounting will be set up so that ERX is an
"additional charge" service.  That may be true, but it is not a
*requirement* for networks to set it up that way.

> secure key distribution protocol in IETF.

  I will avoid the discussion of secure key distribution.  I think it's
orthogonal to any accounting fraud issue.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 19 Mar 2008 12:40:31 -0400

> orthogonal to any accounting fraud issue.

Unless, of course, the key distribution service is charging for each key 
that it issues.  I'm not sure that would be an *AAA* accounting issue, 
however.

Depending on the level of fraud that can be committed by unauthorized 
usage of DSRKs, allowing them to be issued to third parties, such as AAA 
proxy servers, without the consent of the account holder (user) might be 
a very Bad Thing (tm).

I agree with Alan that this is not an AAA accounting issue, however.

Regards,

Dave Nelson

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 19 Mar 2008 10:06:08 -0700

> Service X which requires additional charge.  

Are we to assume that a visited domain server might not pad accounting 
records, but just as soon as a DSRK is available start generating 
records for a service that the peer is not using?

How realistic is this attack?  Not realistic in my opinion.  I would 
assume that the failure model would apply to all cases, i.e., the fraud 
is equally likely in today's networks.

What might be a good mitigation strategy?  Proof of peer consent in the 
key request is not an effective solution really, if you think about it. 
  All accounting information is generated within the visited network 
anyway and none of that is verified by the peer and so the possibility 
of disputes will remain pretty much the same even when there is peer 
consent for key delivery.

The only workable solution here is for the peer to also maintain 
accounting information, share it with the home server so the home server 
can reconcile the two sets of accounting records to find discrepancies. 
  That kind of solutions have been discussed elsewhere and operators 
said they don't need that.  They are fine with the current accounting 
model and they plan to rely on contractual agreements.

Fraud in the "core" network, in other words, is not a concern.

thanks,
Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 19 Mar 2008 16:40:16 -0400

> records for a service that the peer is not using?

I have no assumption on a particular way of the fraud.

> is equally likely in today's networks.

That is my question :) A bigger question is: who is the authority to
determine that the fraud is not realistic?

> key request is not an effective solution really, if you think about it.  

I am not sure why peer consent in the DSRK request is not effective,
which can be done within one AAA roundtrip and outside the time period
of handover.  I know you are not convinced with this point made by
Bernard, but I am not convinced with your counter argument.  

> can reconcile the two sets of accounting records to find discrepancies.  

Although I don't think it is the only workable solution, but I agree
that it is not a good idea for the peer to also maintian accounting
information as it may just introduce other security issues.

> That kind of solutions have been discussed elsewhere and operators said 
> they don't need that.  They are fine with the current accounting model 
> and they plan to rely on contractual agreements.
>

It would be difficult to simply accept a statement such as "operators
said something" (it rather makes me suspicious), unless operators
themselves officially make such a statement.

> Fraud in the "core" network, in other words, is not a concern.

Is this your opinion or a fact?

Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 Mar 2008 22:11:53 +0100

> determine that the fraud is not realistic?

  The people who build && run networks that would be vulnerable to this
fraud.  Right now, they just don't care about any of the *existing*
possibilities for fraud.

> I am not sure why peer consent in the DSRK request is not effective,

  The visited network can still disconnect the user after he proves
consent, and then create fraudulent accounting records for that session.

  This attack isn't new.  Proving consent is a waste of time, because it
doesn't prove that the user obtained *access* after consenting.  Even
proving that the visited network gave the user access is a waste of
time, because the visited network can kick the user off as soon as it
has obtained that proof.

> themselves officially make such a statement.

  Go ask the operators yourself.  Or, believe the people who do talk to
the operators.

> Is this your opinion or a fact?

  Fact.

  I think this discussion is done.  You haven't demonstrated any new
attacks.  There is no Hokey-specific vulnerability.

  Alan DeKok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Mar 2008 07:08:22 -0400

> consent, and then create fraudulent accounting records for that session.

In this case, the user will realize disconnection and make a claim to
the visited or home operator immediately after the disconnection, so I
am not seeing this case as a serious problem.

> time, because the visited network can kick the user off as soon as it

Again, I am not seeing this as a serious problem.  

The problem of the accounting fraud without peer consent is that there
is no way for the home network to verify the accounting records about
the use of the service, as I indicated my other email.  This problem
has hokey key distribution dependency, and in that sense it's new.

(snip)
> > Is this your opinion or a fact?

Please bear with me as I am not a AAA operation expert, but your
elaboration on your statement would be appreciated.

> attacks.  There is no Hokey-specific vulnerability.

Respectfully I don't agree with your conclusion.  Please see above and
my other email.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Mar 2008 06:45:32 -0400

> accounting traffic, and can generate any kind of accounting records that

Yes, this part is same as my thought.

> match the service that was authorized.  Sometimes these checks are easy,

No matter how it is easy or difficult, verification of the accounting
records is basically possible by checking authentication/authorization
records for the service, if there is proof of peer consent on the use
of the service in the authentication/authorization records maintained
by the home network.  Perhaps frequent
re-authentication/re-authorization may be needed to improve the
accuracy of verification, but this is not an essential issue.

On the contrary, without peer consent on the use of the service, there
is no way for the home network to verify the accounting records
because there is no authentication/authorization records usable for
verification.  This can make the problem of accounting fraud even
worse than now.

> *requirement* for networks to set it up that way.

Whether it is a requirement or not does not matter, as long as such
service can be *a* deployment scenario.

> orthogonal to any accounting fraud issue.

I don't think so.  The latter has dependency on the former (see
above), but not the other way around.

Regards,
Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Thu, 20 Mar 2008 14:49:29 +0100

Yoshihiro Ohba wrote:
> by the home network.

  I'm sorry, but this is not true.

>  Perhaps frequent

  Yes, it is.  It is the *only* issue that matters.  Verification
happens rarely (minutes to hours between checks).  In between
verification checks, the visited network can do almost anything with the
accounting records.

> verification.  This can make the problem of accounting fraud even

  This isn't true, either.  The current ERX scenario always ties ERX to
an initial EAP authentication.  So there *is* an authentication record,
despite your claims otherwise.

> above), but not the other way around.

  Are you really saying that accounting fraud requires a secure key
distribution?  This is patent nonsense.

  I don't know why you're worried about these potential fraud issues.

> elaboration on your statement would be appreciated.

  This isn't the place to learn about operator business models.

  Alan DeKok.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Mar 2008 11:04:26 -0400

> verification checks, the visited network can do almost anything with the

I believe there are a number of mitigation schemes here, as long as
authentication records exist, and in that sense I mentioned "basically
possible".  However, if no authentication records for the ERX service,
no mitigation is possible.

> despite your claims otherwise.

Let's not mix the discussion on authentication records for two
different services, i.e., network access without ERX, and network
access with ERX.  I am not arguing about authentication records for
the former.  I well know that authentication records for the former
exist.  But authenticaiton records for the latter does not.

> distribution?  This is patent nonsense.

Yes, but for hokey DSRK usage only.  Please note that my focus is not
general accounting fraud issues.  I think this is the major cause of
split opinions.  I am just concerned on accounting fraud issues
relating to HOKEY key distribution.

Yoshihiro Ohba

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 20 Mar 2008 11:13:08 -0400

Yoshihiro Ohba writes...

> relating to HOKEY key distribution.

I admit to not having followed all the development is HOKEY very closely,
however, I am confused by these statements.

HOKEY is all about creating keys for rapid service handover, when roaming
from one access point to another, right?  Where do you see the invocation of
separate services that would require separate authentications?  I thought
the whole idea of HOKEY was to enable a continuous stream of (secure)
service to be provided via seamless and rapid roaming / handover.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 20 Mar 2008 12:16:46 -0400

> service to be provided via seamless and rapid roaming / handover.

Authentication for DSRK distribution, which is separate from initial
EAP authentication performed when entering into the visited domain, is
equivalent to the actual procedure to realize peer consent property.
We are discussing is whether peer consent is needed or not for DSRK
distribution.  If our consensus is that peer consent is not needed, it
means that the authentication for DSRK distribution is not needed,
otherwise it is needed.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 20 Mar 2008 15:52:47 -0700

Yoshi,
I've been meaning to respond to this thread earlier, but, was not so
enthusiastic given how many times we've had this discussion in vain.
This time, yet again, Alan, Glen and Lakshminath have been making the
points and I see that Yoshi still feels that peer consent for DSRK
distribution and AAA accounting are somehow related.  

I'll try one more time and quit after that.  Explicit peer consent or
not, the peer involvement is during the run of EAP or ERX (depending on
which one is happening).  The AAA architecture remains the same for both
EAP and ERX usages.  Also, AAA transactions are not exposed to the peer.
Given that, whether there is a DSRK or not and whether the peer knows
about the DSRK distribution or not, the AAA entities in the path can do
the exact same things, which equally apply to EAP and ERX.
Accounting-Start messages should be tied to an ERX run, much like it is
tied to an EAP run - distribution of a DSRK alone should not be
triggering accounting with that domain.  

It is merely a delusion that ERX introduces a AAA accounting problem
that did not exist with EAP.  As Alan noted, this discussion should have
concluded a while ago - it is simply consuming WG cycles for no good
reason. 

- Vidya

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Yoshihiro Ohba
> Sent: Thursday, March 20, 2008 9:17 AM
> To: David B. Nelson
> Cc: [email-masked]
> Subject: Re: [HOKEY] ERX issues
> 
> > > Yes, but for hokey DSRK usage only.  Please note that my focus is 
> > > not general accounting fraud issues.  I think this is the major 
> > > cause of split opinions.  I am just concerned on accounting fraud 
> > > issues relating to HOKEY key distribution.
> > 
> > I admit to not having followed all the development is HOKEY very 
> > closely, however, I am confused by these statements.
> > 
> > HOKEY is all about creating keys for rapid service handover, when 
> > roaming from one access point to another, right?  Where do 
> you see the 
> > invocation of separate services that would require separate 
> > authentications?  I thought the whole idea of HOKEY was to enable a 
> > continuous stream of (secure) service to be provided via 
> seamless and rapid roaming / handover.
> 
> Authentication for DSRK distribution, which is separate from 
> initial EAP authentication performed when entering into the 
> visited domain, is equivalent to the actual procedure to 
> realize peer consent property.
> We are discussing is whether peer consent is needed or not 
> for DSRK distribution.  If our consensus is that peer consent 
> is not needed, it means that the authentication for DSRK 
> distribution is not needed, otherwise it is needed.
> 
> Yoshihiro Ohba
> 
> 
> > 
> >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 21 Mar 2008 18:04:02 -0400

Vidya,

> enthusiastic given how many times we've had this discussion in vain.

I am wondering why you are making such a statement.  The fact is that
peer consent property for DSRK distribution has been described in
draft-ietf-hokey-key-mgm since (and even before) it became a HOKEY WG
document, and there has been some foundation in the WG to support peer
consent property.

> the exact same things, which equally apply to EAP and ERX.

This is not correct.  If there is no peer consent in ERX bootstrapping
part, that part is actually introducing a new functionality to AAA to
distribute peer's key without peer consent.  On the other hand, I
confirm that peer consent exists for MSK and rMSK distribution, for
which the home EAP server and the (home or visited) ER server can
verify the involvement of the peer, respectively.

> triggering accounting with that domain.  

I am not arguing when accounting start message should be sent.  Yes,
it should be tied to an ERX run.  However, my whole point is that,
without peer consent on the use of DSRK, there is *no* way for home
network to verify accounting records for ERX run.  Too bad.

> concluded a while ago - it is simply consuming WG cycles for no good

I strongly believe that peer consent of DSRK, which is eventually used
by the peer and visited domain to establish link-layer SAs for all
authenticators in the entire visited domain, is important and needed.

Yoshihiro Ohba

---

From: Charles Clancy <[email-masked]>
Date: Sun, 23 Mar 2008 21:36:34 -0400

Yoshi,

 > authenticators in the entire visited domain, is important and needed.

I've added your comments to issue 40 in the tracker, but the WG 
consensus, as measured at IETF 71, is to not implement peer consent for 
DSRK key distribution.  I understand that you feel strongly about this 
issue, but in the interest of making progress on our documents, I 
request that we move on.  Are you willing to make the required changes 
to the key-mgm document?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 24 Mar 2008 13:46:58 -0400

Charles,

I would like to note that this is not only my comment, but also there
are couple of comments from others.

[1] Bernard Aboba mentioned
(http://www.ietf.org/mail-archive/web/hokey/current/msg01151.html):

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

[2] Chunqiang Li mentioned
(http://www.ietf.org/mail-archive/web/hokey/current/msg01173.html):

"
Yes, and it is not compliant with the requirements in RFC4962 if removing
the KDE1 and KDE4.
"

Regards,
Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 24 Mar 2008 20:26:46 +0100

Hi Charles,

For those we could not attend the IETF 71 (like me), could you summarize 
the technical reasons why the peer consent for DSRK key distribution 
should be removed?

At first sight, I see more security problems when peer consent is NOT 
implemented and some of them have been already mentioned. However, i see 
real benefits on providing peer consent to assure the server distributed 
a DSRK only when it was really required by the peer.

Based on this,  i would like to understand the technical reasons to NOT 
implement peer consent.

My best regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------