Subject: Re: [Ietf-krb-wg] OTP - Is encrypting AS-REP with Armor Key ok?

From: "Srinivas Cheruku" <[email-masked]>
Date: Fri, 10 Jul 2009 14:29:57 +0530

Hi,

When otp-value is specified in PA-OTP-REQUEST which is meant for S/Key
support, there is no Client Key and Reply Key generation and Armor Key would
be used wherever these keys are needed. 

The draft says:

This FAST factor provides the following facilities (as defined in
   [ZhHa09
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-ZhHa09> ]):
client-authentication, replacing-reply-key and KDC-
   authentication.  It does not provide the strengthening-reply-key
facility.

So, as part of replacing-reply-key, the AS-REP would be encrypted using the
Reply Key which is nothing but the Armor Key.

Is using Armor Key ok for encrypting the AS-REP? I think the same security
concern might be applicable here also as Greg Hudson said in
https://lists.anl.gov/pipermail/ietf-krb-wg/2009-March/007550.html

Maybe, strengthen-reply-key should be used instead of replacing-reply-key in
this case?

Thanks,
Srini

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Mon, 13 Jul 2009 05:07:27 -0400

Srini,

Section 6.1 in the Security Considertations of the OTP pre-auth ID
currently recommends that anonymous PKINIT not be used to establish the
Aromor Key with OTP algorithms that require the OTP value to be sent to
the KDC.  Does this help with some of your concerns.

--Gareth

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Srinivas Cheruku
	Sent: 10 July 2009 10:00
	To: [email-masked]
	Subject: Re: [Ietf-krb-wg] OTP - Is encrypting AS-REP with Armor
Key ok?	

	Hi,

	When otp-value is specified in PA-OTP-REQUEST which is meant for
S/Key support, there is no Client Key and Reply Key generation and Armor
Key would be used wherever these keys are needed. 	 

	The draft says:

	This FAST factor provides the following facilities (as defined
in
	   [ZhHa09
<http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-10#ref-ZhHa09>
]): client-authentication, replacing-reply-key and KDC-
	   authentication.  It does not provide the
strengthening-reply-key facility.

	So, as part of replacing-reply-key, the AS-REP would be
encrypted using the Reply Key which is nothing but the Armor Key.

	Is using Armor Key ok for encrypting the AS-REP? I think the
same security concern might be applicable here also as Greg Hudson said
in https://lists.anl.gov/pipermail/ietf-krb-wg/2009-March/007550.html

	Maybe, strengthen-reply-key should be used instead of
replacing-reply-key in this case?

	Thanks,
	Srini

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 15 Jul 2009 10:22:57 +0530

Gareth,

Its fine when using anonymous PKINIT. I am concerned about ticket based
armors got using the host keys. Maybe better to ask Sam on this.

Sam,
Do you think that it's ok to use armor key (generated using the armor ticket
using host keys) for encrypting the AS-REP?

Thanks,
Srini

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 13 July 2009 14:37
To: [email-masked]; [email-masked]
Subject: RE: [Ietf-krb-wg] OTP - Is encrypting AS-REP with Armor Key ok?

Srini,

--Gareth

	Hi,

	The draft says:

	Thanks,
	Srini

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Jul 2009 03:34:36 -0400

>>>>> "Srinivas" == Srinivas Cheruku <[email-masked]> writes:

    Srinivas> Gareth, Its fine when using anonymous PKINIT. I am
    Srinivas> concerned about ticket based armors got using the host
    Srinivas> keys. Maybe better to ask Sam on this.

    Srinivas> Sam, Do you think that it's ok to use armor key
    Srinivas> (generated using the armor ticket using host keys) for
    Srinivas> encrypting the AS-REP?

I've been thinking about this.

As I understand things, what is going on is that there are some OTP
cases where the token does not expose keying material to one end of
the connection.  For example,a server on the KDC may act as an oracle
for OTP responses, but not be willing to tell the KDC what the next
response is.

So, we need something to encrypt the AS reply in.

We choose the armor key.

I have reasonably high confidence that this does not suffer from the
attacks we've considered recently with regard to FAST.

The armor key is bound to the inner request, not the outer request.
We use inner request data This is a fast factor; there is no way that
you can get a client to send you this padata item outside of fast.
So, there is no concern about this and inconsistency between the outer and inner request.

This mechanism is vulnerable to man-in-the-middle attacks.  If the
client sends the OTP value to a party who turns out not to be the KDC,
then that party can gain access to the resulting ticket and session
key.  I believe that's already documented in the security
considerations section.  I don't think that depends on armor type,
although it's easier to get into a MITM situation with anonymous
pkinit than with other host armor types.

This mechanism is vulnerable to the concerns Greg Hudson raised that
caused us to move from replace reply key to strenthen reply key: an
attacker who later gains access to the host key can gain access to the
resulting ticket.  I think that's a fine residual threat provided it
is documented in security considerations.

I don't think this suffers from the problems related to TGS request
armor selection.  There' we had an issue that the TGS request requires
that the client authentication be bound to the entire request and the
ap-request armor does not provide that.  By encrypting the client
authentication in a FAST factor, as done by the OTP mechanism, the
client authentication is properly bound to the request.

So, I don't see any known attacks against this mechanism that are
problematic.  

--Sam

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Wed, 22 Jul 2009 10:21:20 +0530

From: Sam Hartman [mailto:[email-masked]] 

[Srinivas Cheruku] I am not sure how an attacker can gain access to
resulting ticket when he knows the host keys. He can gain access only when
he knows client long-term key also along with the host keys as we now use
strengthenkey in FAST response. 

>From the extract of what Greg Hudson said:
____
If a ticket-based armor is used to protect the exchange--say, using the host
key of the client machine--then anyone with knowledge of the long-term key
of the armor ticket can observe and decrypt the exchange, read the reply key
in the KrbFastResponse message, and decrypt the returned credentials without
knowledge of the user's long-term key.  In many cases knowing the armor
ticket long-term key is synonymous with being root on the client's host,
which would grant access to the decrypted credentials anyway, but at a
minimum this relationship should be made clear in the security
considerations.
____

My explanation/concern:

Anyone with knowledge of long-term key of armor ticket was able to generate
armor key and able to decrypt the KrbFastResponse message and get its
contents like reply key (which is now being replaced with strengthenkey) and
using this reply key he was able to decrypt AS-REP and able to get the
credentials without knowing users long-term key. In order to mitigate this
risk, we now use strengthenkey in KrbFastResponse and this strengthenkey
along with the client long-term key can be used to generate the reply key
and AS-REP can be decrypted now only when knowing users long-term key.

So, I think the same risk applies here also e.g. when AS-REP is encrypted
using the armor key, then anyone with knowledge of the long-term key of the
armor ticket would be able to decrypt the AS-REP without the knowledge of
the key derived using the users OTP value. I think just encrypting AS-REP
with armor key is not that safe and we should be able to decrypt AS-REP only
when knowing the key derived from the users secret (e.g. password or OTP
value).

Thanks,
Srini

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jul 2009 04:48:40 -0400

>>>>> "Srinivas" == Srinivas Cheruku <[email-masked]> writes:

    Srinivas> From: Sam Hartman [mailto:[email-masked]] This
> mechanism is vulnerable to the concerns Greg Hudson
> raised that caused us to move from replace reply key to
> strenthen reply key: an attacker who later gains access
> to the host key can gain access to the resulting ticket.
> I think that's a fine residual threat provided it is
> documented in security considerations.

    Srinivas> [Srinivas Cheruku] I am not sure how an attacker can
    Srinivas> gain access to resulting ticket when he knows the host
    Srinivas> keys. He can gain access only when he knows client
    Srinivas> long-term key also along with the host keys as we now
    Srinivas> use strengthenkey in FAST response.

It's my understand that the OTP mechanism does not have a client key
and thus uses replace rather than strengthen.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Sun, 26 Jul 2009 07:04:04 -0400

How does OTP provide kdc-authentication in the s/key case?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Mon, 27 Jul 2009 04:22:29 -0400

Sam,

The PA-OTP-CONFIRM is returned by the KDC to the client containing the
nonce sent by the client to the KDC in the PA-OTP-REQUEST encrypted
under the reply key.  This confirms to the client that the KDC has
generated the same reply key which in the non-s/key case means that the
KDC has been able to obtain the same OTP value as the client but in the
s/key case, the client sent the OTP value to the KDC and so this doesn't
really prove much.	

So it seems as if in the non-s/key case that the mechanism provides
replacing-reply-key and kdc-authentication but for s/key it only
provides replacing-reply-key.

Looks like section 6.6 needs to be updated.

--Gareth

> Sent: 26 July 2009 12:04
> To: Sam Hartman
> Cc: Srinivas Cheruku; Richards, Gareth; [email-masked]
> Subject: Re: [Ietf-krb-wg] OTP - Is encrypting AS-REP with 
> Armor Key ok?
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Jul 2009 06:15:36 -0400

>>>>>   <[email-masked]> writes:

    > Sam, The PA-OTP-CONFIRM is returned by the KDC to the client
    > containing the nonce sent by the client to the KDC in the
    > PA-OTP-REQUEST encrypted under the reply key.  This confirms to
    > the client that the KDC has generated the same reply key which
    > in the non-s/key case means that the KDC has been able to obtain
    > the same OTP value as the client but in the s/key case, the
    > client sent the OTP value to the KDC and so this doesn't really
    > prove much.

    > So it seems as if in the non-s/key case that the mechanism
    > provides replacing-reply-key and kdc-authentication but for
    > s/key it only provides replacing-reply-key.

    > Looks like section 6.6 needs to be updated.

Unfortunately, it is worse than that.
Quoting FAST:

   Any pre-authentication mechanism that sets a new reply key not based
      on the principal's long-term secret MUST either verify the KDC reply
         some other way or indicate that the reply is not verified.  If a
	    mechanism indicates that the reply is not verified then the client
	       implementation MUST return an error unless a subsequent mechanism
	          verifies the reply.  

I believe that the requirement in FAST is reasonable.  Having replies where the KDC is not verified seem a significant change to Kerberos.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Tue, 28 Jul 2009 06:34:48 -0400

> I believe that the requirement in FAST is reasonable.  Having 
> replies where the KDC is not verified seem a significant 
> change to Kerberos.
> 
It is starting to look as if s/key and other systems that require the
OTP to be sent in plain text can either not be supported or can only be
supported if used in conjunction with another mechanism.  

I can't think of any way out of this with s/key since I believe that all
the server has is the previous OTP value.  It authenticates the user by
hashing the OTP sent by the client and comparing it with the stored
value.  
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Jul 2009 09:01:23 -0400

Is s/key secure with host armor?
pkinit armor which is not anonymous?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Tue, 28 Jul 2009 11:17:27 -0400

Sam,

> pkinit armor which is not anonymous?
The security considerations section of the ID has the following text
covering anonymous PKINIT, recommending that it not be used with
algorithms such as s/key due to MITM issues.

   As described in section 6.5 of [ZhHa09], FAST can use an anonymous
   TGT obtained using anonymous PKINIT [ZhLe08] [RFC4556] as the Armor
   Key. However, the current anonymous PKINIT proposal is open to man-
   in-the-middle attacks since the attacker can choose a session key
   such that the session key between the MITM and the real KDC is the
   same as the session key between the client and the MITM.

   As described in Section 3.6, if the OTP value is not being sent to
   the KDC then the Armor Key is used along with the OTP value in the
   generation of the Client Key and Reply Key. If the Armor Key is known
   then the only entropy remaining in the key generation is provided by
   the OTP value.  If the OTP algorithm requires that the OTP value be
   sent to the KDC then it is sent encrypted within the tunnel provided
   by the FAST armor and so is exposed to the attacker if the attacker
   has the Armor Key.

   It is therefore recommended that anonymous PKINIT not be used with
   OTP algorithms that require the OTP value to be sent to the KDC and
   that careful consideration be made of the security implications
   before it is used with other algorithms such as those with short OTP
   values 

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Jul 2009 12:14:41 -0400

> Sam,
    >> 
    >> Is s/key secure with host armor?  pkinit armor which is not
    >> anonymous?
    >> 
    > The security considerations section of the ID has the following
    > text covering anonymous PKINIT, recommending that it not be used
    > with algorithms such as s/key due to MITM issues.

You seem to be responding to the anonymous pkinit cases.  I'm
wondering about the other cases as it happens.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Tue, 28 Jul 2009 12:28:12 -0400

> wondering about the other cases as it happens.

I don't see why it wouldn't be secure in that case.  All the method is
really doing in that case is using the encrypted tunnel provided by
FAST's armor key to send the hashed password value (the OTP) to the KDC.

1) The PA-OTP-CHALLENGE would contain a challenge of the form:
otp-<algorithm identifier> <sequence integer> <seed>

2) The client will then hash the user's passphrase the specified number
of times, using the specified algorithm and seed and send the result to
the KDC in the PA-OTP-REQUEST.

3) The KDC (or s/key server) then just hashes it again and  compares it
to the stored result.

The PA-OTP-REQUEST will be in the encrypted KrbFastReq, encrypted under
the armor key.  The challenge won't be encrypted as it is sent in the
KRB-ERROR from the KDC.

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Jul 2009 13:27:47 -0400

> really doing in that case is using the encrypted tunnel provided
    > by FAST's armor key to send the hashed password value (the OTP)
    > to the KDC.

This makes sense to me.
So, S/KEY with host armor would be OK to allow?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Tue, 28 Jul 2009 14:06:35 -0400

> So, S/KEY with host armor would be OK to allow?

I think it's worth documenting that it would allow someone with the host
key to fool the client, whereas a straight RFC 4120 AS-REQ does not
allow this.

It's not a terribly interesting vulnerability because a compromised host
key normally means a compromised host, which generally gives you more
latitude to mess with the user's activities than impersonating the KDC
does.

---

From: <[email-masked]>
Date: Wed, 29 Jul 2009 04:45:07 -0400

> I think it's worth documenting that it would allow someone 
> with the host key to fool the client, whereas a straight RFC 
> 4120 AS-REQ does not allow this.
> 
> It's not a terribly interesting vulnerability because a 
> compromised host key normally means a compromised host, which 
> generally gives you more latitude to mess with the user's 
> activities than impersonating the KDC does.
> 
> 
I could add something about this to the security considerations.  Want
to suggest some text?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Wed, 29 Jul 2009 04:49:35 -0400

> So, S/KEY with host armor would be OK to allow?

I don't see why not (with the caveat that Greg pointed out).  

However, there is still the issue that you pointed out regarding the
lack of the kdc-authentication facility in these cases.  Do you agree
that these OTP methods could only be supported in conjunction with
another mechanism that supports KDC authentication?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg