Subject: Re: comments on draft-houseley-aaa-key-mgmt-07.txt

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Feb 2007 16:31:41 -0500

Speaking as an individual:

I believe the attack Dan is concerned about is very important and I
believe it is important that this draft make it clear that
distributing keys to the wrong parties does not meet the requirements
of the draft.

I take no position on whether the draft does accomplish that already.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 16 Feb 2007 17:44:51 -0800

I have not seen an email from Dan posted to the IETF list here, but,
having participated in the HOKEY discussions from which this seems to
have appeared, I think I understand the context.  

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Friday, February 16, 2007 1:32 PM
> To: Dan Harkins
> Cc: [email-masked]; [email-masked]
> Subject: Re: comments on draft-houseley-aaa-key-mgmt-07.txt
> 
> I believe the attack Dan is concerned about is very important 
> and I believe it is important that this draft make it clear 
> that distributing keys to the wrong parties does not meet the 
> requirements of the draft.
> 

I think we need to look at what it means by "distributing keys to the
wrong parties" and there are two points for consideration. 

1) The peer and the server need to have a common understanding of the
identity of a third entity to which a key may be distributed. When the
server is unambiguously able to verify the identity of that entity (as
would be feasible with Diameter secured with TLS, for e.g.), it can
actually be concluded that the third entity is what it claims to be.
Now, there are possible RADIUS models, where such guarantees may not be
available. There, the only thing that can be ensured is that the peer
and the server both "think" the third entity is what it claimed to be.
However, in both cases, it is feasible to ensure that the third entity
doesn't get away with claiming one identity to the peer and a different
identity to the server. 

2) The second point is that no two such "third" entities must obtain the
same key. When the server can actually detect impersonation (say,
because the SA was bound to the identity), this would actually translate
to the fact that the key given to that entity can be guaranteed to be
meant for it. When the server cannot detect impersonation, this only
translates to the fact that a key given to an entity is not the same as
any other key given to any other entity, with no guarantees on whether
the key was meant for it or not. 

Translating this to an example: Consider authenticators in ISP1 and ISP2
that want to obtain a key each for a peer, except, ISP1 is impersonating
to be ISP2. 

Peer attaches to ISP1, but, thinks it is attached to ISP2. At the
backend, if the server is able to detect the impersonation, the problem
is solved and no keys are given out. But, if the server also believes
that it is ISP2, a key might be given to it and peer goes about its
communication. 

Now, the peer attaches to the real ISP2. If it attempts to use the same
key, that will fail. If it tries to fetch another key from the server,
the server MUST ensure that the key given out, although may still be to
"ISP2" in its view, is not the same as the key that was given out
earlier. In other words, a static derivation like "Transported Key = PRF
(Some Master Key, "ISP/authenticator ID") is insufficient in such cases,
since, the resultant key will be the same when the IDs are the same.
Hence, we can use some random data to ensure that even if the IDs are
"perceived" to be the same, the same key is never generated. Of course,
this example is just making a point, not trying to design a particular
solution. 

The above is sufficient to ensure that a lying entity cannot use a key
to cause any damage to sessions with other entities, regardless of the
fact that the lying couldn't be detected due to the shortcomings of the
key transport protocol. 

> I take no position on whether the draft does accomplish that already.

To me, the draft is clear. However, if it can perceived to be unclear to
some others, then, that may be a problem and the text may be worth
fixing. In short, I think it comes down to something like the following:

"It is RECOMMENDED that the key transport protocol be able to detect
impersonation. When it is not feasible to guarantee that, every key
handed out from the server to an entity for a given peer MUST be
different from every other key handed out for a given peer." 

If people feel like that might be useful, perhaps that could be added to
the document. 

Vidya

---

From: Sam Hartman <[email-masked]>
Date: Sat, 17 Feb 2007 10:46:02 -0500

Vidya, I found the model you proposed didn't fit what Dan was talking
about very well.  In particular, Dan wants to focus on problems
resulting from the fact that the name of the authenticator used
between the peer and the authenticator may be different than the name
of the authenticator used between the authenticator and the AAA
server.  That distinction did not figure prominently enough in your
argument that I could tell whether you and Dan are talking about the
same thing nor whether I could even tell if I agreed with you.  I'd
recommend refocusing your model on this distinction; I think once you
do we may well make significant progress on discussing a long-standing
issue.

--Sam

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 17 Feb 2007 09:35:39 -0800

Sam,

The problem of an entity in the middle giving disparate information to 
the peer and the server is in fact easier to solve than the problem 
Vidya summarized.  The disparate information problem has been described 
in the EAP Keying Framework document and elsewhere too.

To my understanding, we are beyond that point in the discussion in HOKEY 
and considering the new case of the entity in the middle lying to both 
sides and attempting to get a key that another entity in the middle is 
supposed to get.

Let me put it this way, both issues are considered problems to 
address/solve in this case.

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 17 Feb 2007 23:43:38 -0800

Yes, the problem of an authenticator providing different identities to
the peer and the server is the typical channel binding problem and can
be detected by simply doing a protected exchange of the identity between
the peer and server. When such a discrepancy is detected, then, keys
won't be handed out or if the identity is part of the key derivation,
then, it will result in a key mismatch anyway. Hence, there is no
problem there. 

In my understanding, Dan's claim is that the server is unable to detect
that an authenticator is claiming an incorrect identity and by virtue of
that, if the authenticator claims the false identity to both the peer
and the server, a key will be provided to the authenticator and that
will match the key that the peer derives, even if the identity was part
of the key derivation. This is the problem that I have detailed in my
earlier email and I belive that can be resolved with the text I
proposed. 

Regards,
Vidya

> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Saturday, February 17, 2007 9:36 AM
> To: Sam Hartman
> Cc: Narayanan, Vidya; [email-masked]; Dan Harkins; 
> [email-masked]
> The problem of an entity in the middle giving disparate 
> information to the peer and the server is in fact easier to 
> solve than the problem Vidya summarized.  The disparate 
> information problem has been described in the EAP Keying 
> Framework document and elsewhere too.
> 
> To my understanding, we are beyond that point in the 
> discussion in HOKEY and considering the new case of the 
> entity in the middle lying to both sides and attempting to 
> get a key that another entity in the middle is supposed to get.
> 
> Let me put it this way, both issues are considered problems 
> to address/solve in this case.
> 
> regards,
> Lakshminath
> 
> Sam Hartman wrote:

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 18 Feb 2007 13:31:42 -0800

Dan,

We are discussing the case of the authenticator providing a different 
identity to the peer and the server here.  Sam raised that issue.

Earlier Vidya described the problem you raise below: that of an 
authenticator (or an entity in the middle) providing the wrong identity, 
but the same wrong identity, to the peer and the server and proposed a 
key distribution requirement that would address the problem.  See 
http://www1.ietf.org/mail-archive/web/ietf/current/msg45291.html.

Please provide your thoughts on whether her proposed text covers the 
issue adequately.  Otherwise, please provide text.

thanks,
Lakshminath

Dan Harkins wrote:
>   Hi Vidya,
> 
> On Sat, February 17, 2007 11:43 pm, Narayanan, Vidya wrote:
>   No, there is a problem even if the identity is part of the key
> derivation. The reason is that this is a _symmetric_ key that is used
> by the client to gain network access. If it is possible for some
> entity to lie about its identity to obtain one of these keys, then that
> key can be used to impersonate the client to the authenticator whose
> identity was lied about and/or attack a connection the client makes to
> the authenticator whose identity was lied about.
> 
>   Any security properties you're trying to assign to this key have been
> thrown out the window.
> 
>   Dan.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 18 Feb 2007 22:26:06 -0500

> earlier email and I belive that can be resolved with the text I

Yes, this is a problem that should not happen.  If this happens, the
peer may send out data that is specific to ISP2 to the lying
authenticator (which is actually an ISP1 entity but claiming itself
to be an ISP2 entity) that is not supposed to see the ISP2-specific
data.

Going back to your proposed text: 

I think that detection of impersonation is part of the "Authenticate
all parties" *requirement* (not a recommendation).

By the way, recent discussion on 3-party key distribution over HOKEY
mailing list made me think more about the following text in Section 5
(I don't know whether this is part of Dan's comment as I did not see
his original comment on this mailing list):

"
   The authenticator is also a trusted party.  The authenticator is
   trusted not to distribute keying material provided by the AAA server
   to any other parties.  If the authenticator uses a key derivation
   function to derive additional keying material, the authenticator is
   trusted to distribute the derived keying material only to the
   appropriate party that is known to the peer, and no other party.
   When this approach is used, care must be taken to ensure that the
   resulting key management system meets all of the principles in this
   document, confirming that keys used to protect data are to be known
   only by the peer and authenticator.
"

I understand that the authenticator is a trusted party for the EAP/AAA
server.  On the other hand, I don't think we can say that it is a
trusted party for the peer before running EAP, unless the link between
the peer and the authenticator is already secured or the peer and the
authenticator have already a shared key to believe before running EAP.

Regards,
Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 18 Feb 2007 23:20:54 -0800

Hi Yoshi, 

> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Sunday, February 18, 2007 7:26 PM
> To: Narayanan, Vidya
> Cc: Dondeti, Lakshminath; Sam Hartman; 
> [email-masked]; Dan Harkins; [email-masked]
> > be detected by simply doing a protected exchange of the identity 
> > between the peer and server. When such a discrepancy is detected, 
> > then, keys won't be handed out or if the identity is part 
> of the key 
> > derivation, then, it will result in a key mismatch anyway. Hence, 
> > there is no problem there.
> > 
> > In my understanding, Dan's claim is that the server is unable to 
> > detect that an authenticator is claiming an incorrect 
> identity and by 
> > virtue of that, if the authenticator claims the false 
> identity to both 
> > the peer and the server, a key will be provided to the 
> authenticator 
> > and that will match the key that the peer derives, even if the 
> > identity was part of the key derivation. This is the problem that I 
> > have detailed in my earlier email and I belive that can be resolved 
> > with the text I proposed.
> 
> Yes, this is a problem that should not happen.  If this 
> happens, the peer may send out data that is specific to ISP2 
> to the lying authenticator (which is actually an ISP1 entity 
> but claiming itself to be an ISP2 entity) that is not 
> supposed to see the ISP2-specific data.
> 
> I think that detection of impersonation is part of the 
> "Authenticate all parties" *requirement* (not a recommendation).
> 

I don't think it is a "requirement" - and the reason I believe that is
due to the second sentence in that text above. This is what I tried to
explain in much greater detail in my first response to Sam on this
thread. As long as no two keys distributed from the server are the same,
even to the same perceived identity, there is nothing that a lying
entity can do to sessions with other entities. So, as long as a solution
satisfies that criteria, it is not a MUST to detect impersonation. But,
I do agree that it would be much better if the detection was done by the
key transport mechanism - hence, I think "RECOMMENDED" is appropriate :)

> 
> By the way, recent discussion on 3-party key distribution 
> over HOKEY mailing list made me think more about the 
> following text in Section 5 (I don't know whether this is 
> part of Dan's comment as I did not see his original comment 
> on this mailing list):
> 
> "
> I understand that the authenticator is a trusted party for 
> the EAP/AAA server.  On the other hand, I don't think we can 
> say that it is a trusted party for the peer before running 
> EAP, unless the link between the peer and the authenticator 
> is already secured or the peer and the authenticator have 
> already a shared key to believe before running EAP.
> 

I agree. In my understanding, the text above is talking about the fact
that the authenticator is a trusted party to the server and because the
peer trusts the server, it trusts the authenticator after it has proven
possession of the right key. So, in that sense, the text seems fine to
me. 

Vidya

> information 
> > > to the peer and the server is in fact easier to solve than the 
> > > problem Vidya summarized.  The disparate information problem has 
> > > been described in the EAP Keying Framework document and elsewhere 
> > > too.
> > > 
> discussion in 
> > > HOKEY and considering the new case of the entity in the 
> middle lying 
> > > to both sides and attempting to get a key that another 
> entity in the 
> > > middle is supposed to get.
> > > 
> > > > server.  That distinction did not figure prominently enough in 
> > > > your argument that I could tell whether you and Dan are talking
> > > about the
> > > > same thing nor whether I could even tell if I agreed with you.  
> > > > I'd recommend refocusing your model on this distinction; I
> > > think once you

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Feb 2007 09:26:33 -0500

>>>>> "Lakshminath" == Lakshminath Dondeti <[email-masked]> writes:

    Lakshminath> Dan, We are discussing the case of the authenticator
    Lakshminath> providing a different identity to the peer and the
    Lakshminath> server here.  Sam raised that issue.

This is probably the last message you'll hear from me for the next
week.  I'm supposed to be on vacation but I made the mistake of
reading my ietf mail.

However, I was so disgusted by your message that I had to reply.  I
will not make the mistake of reading ietf mail until I return again.

We're discussing Dan's last call comment.  There's no way Dan can be
wrong about what problem we're discussing.H We may not understand him,
but it is completely inappropriate to correct him and tell him that
he's bringing up the wrong problem.

Please stop trying to refocus the discussion.  Bringing up a model to
think about an issue can be a useful tool, but it can also be a tool
used to add obscurity.  In this instance, I think you and Vidya may be
having the ladder effect.

--Sam

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 19 Feb 2007 09:45:37 -0500

Vidya,

On Sun, Feb 18, 2007 at 11:20:54PM -0800, Narayanan, Vidya wrote:
(snip)
> key transport mechanism - hence, I think "RECOMMENDED" is appropriate :)

I believe this is a requirement.  If a particular AAA key management
framework is hard to satisfy this requirement in a particular usage, I
think that the right way to do is to have some text in the
corresponding framework document about the potential vulnerability in
that usage, rather than trying to relax the requirement itself.

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 19 Feb 2007 19:35:01 -0800

Sam,

Please read the thread again and make a convincing case as to why my 
message -- and please consider the entire message -- is disgusting, and 
I shall apologize.

Some notes inline:

> he's bringing up the wrong problem.

First, a fact to consider: Dan's last call comment never really made it 
to my mailbox and it is not available in the archive (perhaps he was/is 
not subscribed to the IETF list; I have 1 message from him in my mailbox 
that was cc'ed to the IETF list, but that is not in the archive either).

This thread started with your message calling the list's attention to 
Dan's message; unfortunately, Dan's message was not included in your 
message either.  Vidya was kind enough to summarize the problem for the 
list based on the long discussion on this topic in the HOKEY list.

You responded to Vidya's message saying that "the model you proposed 
didn't fit what Dan was talking about very well."  You went on to 
summarize the problem as "Dan wants to focus on problems
resulting from the fact that the name of the authenticator used
between the peer and the authenticator may be different than the name
of the authenticator used between the authenticator and the AAA
server."

Now I haven't seen Dan's original message and so I don't know whether 
you are capturing the entirety of Dan's message.  In my response, I was 
in fact bringing in Dan's concern (as I understood it on the HOKEY list) 
back into the discussion.

I responded to you and noted that there are two problems, 1) the entity 
in the middle giving a different identity to the peer and the server 
(which may be solved by including the identity in the key derivation; 
there are other solutions) and 2) the entity in the middle giving the 
same wrong identity to both sides.

I went on to say "Let me put it this way, both issues are considered 
problems to address/solve in this case."

By the way, I think #2 above briefly and correctly summarizes what Dan 
is describing.  Below is the attack in his own words.

Here is Dan's summary of the problem: "No, there is a problem even if 
the identity is part of the key
derivation. The reason is that this is a _symmetric_ key that is used
by the client to gain network access. If it is possible for some
entity to lie about its identity to obtain one of these keys, then that
key can be used to impersonate the client to the authenticator whose
identity was lied about and/or attack a connection the client makes to
the authenticator whose identity was lied about.

   Dan."

My message that you were so "disgusted" by was in response to Dan's 
email above.

I was attempting to say to Dan that the reference to including the 
identity as part of key derivation came about as a response to your 
summary of the problem.  I went on to talk about the problem he has 
described in the HOKEY list as well in this thread in the second 
paragraph and concluded "Please provide your thoughts on whether her 
proposed text covers the issue adequately.  Otherwise, please provide 
text. "

I did not correct him, I was merely saying the focus of the thread at 
that moment was on a slightly different problem (and that was from your 
summary of the issue, btw) than the one he has described.

I did not "tell him that he's bringing up the wrong problem."  What gave 
you that impression?

So where do I think we are?  At the risk of repeating myself, there is 
the problem of an entity in the middle giving different identities to 
the peer and the server and there is the problem of the entity in the 
middle giving the wrong identity to the server and the peer (giving the 
wrong identity to the server alone may also be sufficient in some cases, 
but requiring that the peer trigger the key delivery mitigates that 
aspect of it).

This is my opinion; last I checked I can express my opinion on any of 
the IETF lists, just as anyone else.  I am also quite fallible.

I look forward to other summaries of where we are in the discussion and 
what needs to be added to draft-housley-aaa-key-mgmt.  I may have overly 
simplified something or understood the threat incorrectly; please point 
out what I got wrong.

Finally, if someone cares to explain in what way my messages (I sent all 
of two in this thread) are sidetracking (I guess that's what Sam is 
saying below) or otherwise disrupting the discussion, I am willing to learn.

thanks,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 19 Feb 2007 21:19:03 -0800

Hi Bernard, 

________________________________

	From: Bernard Aboba [mailto:[email-masked]] 
	Sent: Sunday, February 18, 2007 6:49 AM
	To: Narayanan, Vidya; Dondeti, Lakshminath; Sam Hartman
	Cc: Dan Harkins; [email-masked]
	Subject: RE: comments on draft-houseley-aaa-key-mgmt-07.txt

	Vidya said:
	
	"In my understanding, Dan's claim is that the server is unable
to detect
	that an authenticator is claiming an incorrect identity and by
virtue of
	that, if the authenticator claims the false identity to both the
peer
	and the server, a key will be provided to the authenticator and
that
	will match the key that the peer derives, even if the identity
was part
	of the key derivation. This is the problem that I have detailed
in my
	earlier email and I belive that can be resolved with the text I
	proposed. "
	
	This problem will exist whenever the peer does not receive an
	indication of whether an authenticator is authorized.  For
example,
	where the AAA exchange is bypassed, the backend server does not
receive
	the authenticator identity claim so that there is no mutual
authentication
	between the authenticator and server, no verification of the
	authenticator identity by the server, and no channel binding
exchange.  

<Vidya>

Yes. Also, when RADIUS proxies are present, for instance, the AAA
exchange and protection may only be hop-by-hop, right? In that case, I
would think that the SA is not tied to the NAS ID - would the result of
that also not be that the authenticator identity ends up not being
explicitly authenticated? 

Thanks,
Vidya

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 18 Feb 2007 11:24:15 -0800 (PST)

Hi Vidya,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 16 Feb 2007 13:16:15 -0800 (PST)

Hi,

  I understand this draft is in IESG evaluation and would like to register
some comments. I apologize for the tardiness of this email.

  This draft is well-written and much needed but I feel it does not
completely address the issue of using AAA for key distribution. Let me
summarize the problematic scenario in mind, why I think the draft does
not address this, and suggested additions to the draft to address my
concern.

  PROBLEM

  It is desired to use AAA to distribute keys for network access and what
is basically a 2 party model is applied to a 3 party protocol.

  A client authenticates through an authenticator to a AAA server. Upon
successful completion of the 2 party authentication protocol between the
client and AAA server a key derived from a shared secret is delivered to
the authenticator. (Known channel binding issues here). Then, a new key
hierarchy, built off another shared secret, is derived and keys from
it are sent, using AAA, to other authenticators to faccilitate fast
handoff. These keys typically have an "identity" of the authenticator
mixed into the key derivation function.

  The explaination given by proponents of this type of scheme on why
this is secure is that the authenticators all have a security association
with the AAA server, the distributed keying material is sent under the
protection of that security association, and the AAA server is trusted.
This, again, takes a 2 party model and attempts to apply it to what is
essentially a 3 party problem.

  The concern is that the security associations are most likely based on
some identity that is not known to the client and therefore is not bound
into the key, for example an IP address. The authenticator's identity mixed
into the key is a NAS Identifier and the security association it has with
the AAA server is based on its IP address. This allows an authenticator
to lie about its identity to the AAA server, through it's secure and
trusted link to the AAA server, and obtain a key intended for another
authenticator.

  Since this key is symmetric it can be used to impersonate the client
to the entity to whom it should've been delivered.

  If a key distribution protocol cannot guarantee that a key will not be
sent to the wrong entity then it is flawed.

  Also, the client is not involved in the distribution of this secret
that it shares. It just notices that some new entity has the key and
must just assume that possession of the key implies authorization to hold
the key.

  WHY IS THIS NOT ADDRESSED IN THE DRAFT

  Two groups, IEEE 802.11 Task Group "r" and the HOKEY working group,
are discussing using such a 2 party model in a 3 party key distribution
scheme. They are coming up with schemes that suffer from the problem
described above and justify them by saying that the authenticators share
a security association with the server and that the key being distributed
has the "identity" of the new authenticator mixed into it.

  People in both these groups advocating this type of flawed scheme are
well aware of the "Housley Criteria" and this draft. In fact, they point
to "Authenticate all parties" and "Bind key to its context" as specific
requirements they meet.

  (In the case of HOKEY the problem is more compound as they wish to
distribute keys from a "home" domain to visited domains and a server in
verizon.net could request a key for the sprint.net domain).

  If this draft explicitly discussed this type of flawed scheme I presume
these groups would not persist in advancing them, but persist they do.
So I would like to see some explicit guidance in this draft to direct
people away from them. Some guidance on how to ensure that this type of
subtle flaw is not perpetuated in future systems would be most helpful.

  SUGGESTED ADDTIONS TO THE DRAFT

  In "Limit Key Scope" it says, "parties MUST NOT have access to keying
material that is not needed to perform their role." In the problem above
the role of the entity lying about its identity is an authenticator and
it is obtaining keying material necessary to perform the role of an
authenticator, it's just that it has obtained a key for a different
authenticator. I would like to see an additional requirement stating "Key
distribution protocols MUST ensure that keying material is not given to
the wrong party."

  In "Authenticate all parties" it specifically mentions different
identities being used in the AAA protocol. This is in the context of
establishment of session keys and the only problem it notes with different
identities is one of difficulty with authorization decisions. I suggest
the following paragraph be added to "Authenticate all parties":

    When a security association is used to distribute keying material
    the security association SHOULD be bound to a unique identity that
    can be commonly known by all the parties-- including the peer. If the
    security association cannot be based on such an identity then it MUST
    be statically configured to be an attribute of the security
    association.

  Then I would like to see a new section entitled "Confirm identities
when distributing keying material" which contains the following:

    When another party requires access to keying material the
    identity of that party MUST be authenticated prior to distribution
    of the keying material. The distributor MUST ensure that the
    keying material is not disclosed to the wrong party. This can be
    accomplished, for example, by verifying the identity of the party
    to whom the keying material is being disclosed with the identity
    bound to the security association under which it will be sent.

    When keying material is disclosed the other party on whose behalf
    it is being disclosed MUST confirm disclosure. For example, a peer
    MUST acknowledge disclosure of keying material from a AAA server
    to an authenticator and the identity of the authenticator MUST be
    confirmed by the peer and AAA server.

This paragraph should appear after "Authenticate all parties".

  If any of my writing is in need of wordsmithing I would be happy if
it was fixed up. But I really think something to address this subtle flaw
is needed in this draft prior to its publication as an RFC. Once again,
I apologize in not bringing my desires to the authors' attention before
it reached the IESG.

  I would appreciate hearing any comments on my suggestions and whether
they will be accepted or denied.

  thanks,

  Dan.