Subject: [Ietf-krb-wg] WG Last Call: draft-ietf-krb-wg-otp-preauth-12

From: Larry Zhu <[email-masked]>
Date: Wed, 25 Aug 2010 08:43:39 +0000

This note announces the start of a two-week last call within the Kerberos
Working Group on whether to send the following document to the IESG:

Title:           OTP Pre-authentication
Filename:        draft-ietf-krb-wg-otp-preauth-12.txt
Intended Status: Standards Track

   The Kerberos protocol provides a framework authenticating a client
   using the exchange of pre-authentication data.  This document
   describes the use of this framework to carry out One Time Password
   (OTP) authentication.

This WGLC will expire at 23:59 PDT on September 9, 2010.

Please review this document and send any comments to the Kerberos Working
Group mailing list, <ietf-krb-wg at anl.gov<https://lists.anl.gov/mailman/listinfo/ietf-krb-wg>>, by that date.  The file can be
obtained via http://tools.ietf.org/html/draft-ietf-krb-wg-otp-preauth-12

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

---

From: Larry Zhu <[email-masked]>
Date: Wed, 25 Aug 2010 16:39:45 +0000

--Larry

---

From: Larry Zhu <[email-masked]>
Date: Thu, 26 Aug 2010 03:44:32 +0000

--Larry

---

From: Sam Hartman <[email-masked]>
Date: Thu, 26 Aug 2010 20:38:12 -0400

Hi.
I think this draft provides a valuable protocol.  I have a few issues
I'd like to see addressed, but after that I think we should send this to
the IESG.

My biggest concern is a question about whether this protocol gives us
interoperability.

I don't understand how the following affect client behavior:

* the OTP key-info
* The OTP algorithm ID
* The pin required/not required flag
* The combine flag

As a Kerberos implementation, what should I do with the above?
I'm concerned that we're focusing too much on bits on the wire and not
enough on implementation behavior and so we'll get things that don't
work together.

current draft 
Section 2.3:

We have not traditionally allowed a Kerberos KDC to change the service
principal requested by the client.  There is a mechanism to return a
realm referral error to send the client to a different realm, but
generally in an as-req we don't change the service name.

I don't think adding this capability as part of a pre-auth method is
appropriate.  I think it would be reasonable to give the client the
principal it should request in an error, or to define a more general
mechanism for service name canonicalizationin FAST protected as-reqs in
another document and depend on that document.  My rationale here is that
we don't want to encourage pre-auth mechanisms making changes to the
base protocol because it makes them really hard to implement using a
provider/plugin interface.

Section 3.2:

The error code will not always be preauth_required.  In particular, if
the client included other preauth in the initial as-req I'd expect
KDC_ERR_MORE_PREAUTH_DATA_REQUIRED I think this can really only happen
if the pre-auth is part of an authentication set that was either
optimistically assumed by the client or that was returned at some point.

This can be resolved either by mentioning both errors or by not
mentioning what error code is returned but simply by pointing to the
rules in section 2.2 of the framework.

Section 3.6:
I'd prefer if the string inputs to krb-fx-cf2 included OTP rather than
just combine.
It's possible another standard could use the constant combine1 if we
permit it.

Using the IDNA-2003 name of the KDC in the hash seems particularly
problematic.  First, I'd recommend something based on the realm rather
than a specific KDC.  Second, I think you can avoid introducing an IDNA
reference (and especially one to an obsolete IDNA).  I'd use the octets
of the realm string from the request itself.  You'll need to decide
whether or not to include length and tag (probably not), but that ought
to allow you to side step I18N entirely.

Please either always use base64 or never use base64.  Saying "foo is
binary," is ambiguous.  Also, once you make it non-ambiguous, it is just
another step to perform in a test tree that's unneeded.
I'd recommend always using base64.

Using the etype-info2 to get etypes, salts and s2k params is a bit odd.
In particular that's typically the set of string2key parameters for the
user's long term password. A typical KDC wouldn't include that
information if the user doesn't have a password.
It is a valid way to do thing although I suspect it makes things harder
on the administrator of the protocol.

You should probably point out that if the strengthening key is used in
FAST, it is combined with the new reply key as part of AS-REP
generation.
It is of course not used to generate the otp confirm.

What does the otp-confirm do from a security standpoint? Doesn't the KDC
prove knowledge of the reply key by encrypting the reply in it?  Since
the armor key is already mixed in, even a cut&paste attack between the
fast and non-fast part of the reply seems impossible. It's harmless, I'm
just trying to understand if I'm missing some attack in my security
analysis.

 Section 5:

You need to register your preauth types, I think.

Section 6.1: Anonymous pkinit is no longer vulnerable to the particular
attack described in this section.  It is vulnerable to a MITM attack
under which the armor key between the attacker and client is different
from the armor key between the KDC and attacker.  In the case where the
OTP value is encrypted, I think that's actually good enough to provide
security if the attacker cannot brute-force the OTP value in real time.
However, in the case where the OTP value is sent in the clear, this MITM
attack is still an issue.
This section should be updated to accurately describe the vulnerability.

I'm a bit confused about the concern where a host key is compromised.
It's basically always possible for a client and an attacker to work
together to spoof the KDC if the attacker knows the host key.  This
tends to be one of the least serious concerns that happens when the host
key is compromised.

Section 6.4 on replay attacks should discuss issues introduced when the
client uses different KDCs for each round trip.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Fri, 27 Aug 2010 07:25:31 -0400

Sam,

Responses in-line.
 
> I don't understand how the following affect client behavior:

The otp-keyInfo element in the PA-OTP-REQUEST is intended to allow the
KDC to assist the client in locating the correct OTP token to use,
particularly if connected (i.e. USB) tokens are used.
For example, the otp-vendor element can be used to inform the client of
the token vendor so that it can prompt the user to use the correct
token.  

> * The OTP algorithm ID
If the user has a connected device that contains multiple token records
then otp-algID and otp-keyID can be used by the client to locate the
correct record on the device.	

> * The pin required/not required flag
These flags are used to handle pinless tokens.  
There are three possible combinations
1. If the pin-required flag is set then the client application needs to
collect a PIN as well as the tokencode.
2. If the pin-not-required flag is set then the client application only
needs to collect the tokencode.
3. If neither flag is set the the KDC does not know the PIN requirements
of the token.

In the third case, the KDC does not know whether or not a PIN is
required and so leaves it up to the client to indicate to the user that
they should enter a PIN if required by their token 

> * The combine flag
This flag is only used with challenge-response tokens and controls
whether only the challenge should be used to calculate the response or
whether it should be combined with the internal state of the token (time
or counter).

> provider/plugin interface.
So are you suggesting that if PIN change is required that there should
instead be an error similar to the KDC_ERR_KEY_EXPIRED containing a
PA-OTP-PIN-CHANGE?
This would then istruct the client that the must change their PIN and
provide the information required to do it.

> rules in section 2.2 of the framework.
How about if I change the first paragraph to something like

   If the user is required to authenticate using an OTP then the KDC
   SHALL respond to the initial AS-REQ with a KRB-ERROR as described 
   in section 2.2 of [ZhHa09] with a PA-OTP-CHALLENGE contained within
the
   enc-fast-rep of the armored-data of a PA-FX-FAST-REPLY encrypted
   under the current Armor Key as described in [ZhHa09].

> It's possible another standard could use the constant combine1 if we
How about 

   The octet string parameters, O1, O2, O3 and O4, shall be the ASCII
   string "OTPComb1", "OTPComb2", "OTPComb3" and "OTPComb4" as shown

> to allow you to side step I18N entirely.

Could you suggest some text for that section.

> I'd recommend always using base64.
Agreed, it would be clearer.  How about this text

   If the hash value is not used, then K2
   SHALL be derived from the base64 encoding of the OTP value.

             K2 = string-to-key(Base64(OTP)||"Krb-preAuth")

> on the administrator of the protocol.
I thought that this would be the cleanest way of doing it since I
propose using string-to-key.  Can you suggest an alternative?

> It is of course not used to generate the otp confirm.
Want to suggest some text for this?

> just trying to understand if I'm missing some attack in my security
The PA-OTP-CONFIRM is intended to cover section 4.4 of FAST by allowing
the KDC to verify to the client that the reply key has been changed and
to authenticate itself to the client by returning the client's nonce
encrypted under the new reply key.

> You need to register your preauth types, I think.
I thought that this had been done.
 
> This section should be updated to accurately describe the 
The issue described in 6.1 was a result of reduced entropy in the reply
key if the armor key is known by the attacker.  Is the problem you
describe that the armor key between the attacker and the client can be
weaker and so reduce the entropy in a similar manner? 

> tends to be one of the least serious concerns that happens 
This was added following an issue raised by Greg Hudson

	On Tue, 2009-07-28 at 13:27 -0400, Sam Hartman wrote:
	> This makes sense to me.
	> 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.

> client uses different KDCs for each round trip.

This would only be an issue in the four-pass mode where the client
responds to a challenge returned by the KDC.  The KDC challenge contains
a nonce that the client must encrypt using a key derived from the OTP
and armor key and return to the KDC in a PA-OTP-REQUEST.  If this
message is sent to a different KDC then the authentication will fail
unless that KDC can obtain the nonce value used by the first KDC. 

Thanks

--Gareth

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Aug 2010 09:43:45 -0400

[Tom you're explicitly copied because I'm asking for your help with some text]

During writing this message, I noticed that FAST section numbers have
changed and your references are stale.  Section 6.2 should be 5.2; 4.4
should be 3.4; any reference you have to 3.1 or 3.2 should be 2.1 or
2.2.

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

    > the token vendor so that it can prompt the user to use the correct

OK. There's no text in the draft indicating which of the elements should
be given to the user,  and which would typically be searched on a
connected token.

    > correct record on the device.	

There's no text discussing this.

    > 3. If neither flag is set the the KDC does not know the PIN requirements

What do I as a Kerberos implementation do with this PIN once I have it?

    > whether it should be combined with the internal state of the token (time

How does that change my behavior as a Kerberos implementation with a
disconnected token?  With a connected token?

    > provide the information required to do it.

That would be fine.
You'd presumably also need to indicate that in this case the
authentication to the PIN change service is expected to succeed.

    > under the current Armor Key as described in [ZhHa09].

Looks good.

    > string "OTPComb1", "OTPComb2", "OTPComb3" and "OTPComb4" as shown

Yes.

    > Could you suggest some text for that section.
If we're agreed on direction, I think Tom Yu would probably do a better
job of writing text here.
He's going to be one of the pickiest reviewers  so I'd rather start with
something he will like.
Tom, can you help us with this?

    > K2 = string-to-key(Base64(OTP)||"Krb-preAuth")

looks good.

    > propose using string-to-key.  Can you suggest an alternative?

Use string-to-key with the enctype of the armor key, default salt for
the principal requested in the as-req and default s2kparams for that
enctype

That means you cannot use non-default s2kparams.
I think that's OK: you already have an iteration count mechanism of your
own.

    > Want to suggest some text for this?

If the strengthen-key is present in KrbFastResponse, then it is combined
with the reply key to generate the final AS-REQ as described in
[ZHA09]. The strengthen-key does not influence the client OTP key.

    > encrypted under the new reply key.

I'm not sure I understand what the client nonce buys us.  In particular
the client has already contributed to the armor key. The client needs
the KDC to prove that it can decrypt the OTP value, but it does that by
using the OTP value in the reply key Again, I'm not asking for changes
here: this is security sensitive and the draft is conservative. I'm just
trying to make sure I understand.

    > I thought that this had been done.
 We have values assigned but as it turns out they are noted to you
 personally rather than to this draft.  Even if they were referenced to
 the draft, it makes it much more likely that they would be updated to
 the RFC if you reference them.  I think the registry is off of
 http://www.iana.org/assignments/kerberos-parameters.  You just want to
 mention the registry name and which values should be updated to point
 to this document.  You may avoid an IESG or IANA comment by mentioning
 that key usages and error codes are not currently managed by IANA but
 you have coordinated for these assignments.  Alternatively you can
 respond to that issue if it comes up.

    > key if the armor key is known by the attacker.  

    > Is the problem you

I don't think so.  Let's consider two situations.  First, the OTP value
is sent.  That is vulnerable to a classic MITM issue unless the KDC
certificate is verified by the client.

Here's what happens:
A sends a request that is intercepted by M rather than reaching B.
A and M perform anonymous pkinit and get an armor key ak_AM.
M then contacts B, performs anonymous pkinit and gets AK_MB.
M learns the OTP value because it is sent encrypted in ak_AM. M
re-encrypts the OTP value and the rest of the request in AK_MB.
8She knows the resulting reply key AK_MB and gets the ticket.
She can optionally forward the ticket  encrypted in the reply key ak_AM
on to A if desired.

That's a fairly classic MITM and really isn't about entropy so much as
sending your authentication credential to the attacker.

Now let's consider the case where the OTP value is not sent.  Here, M
can mount the same attack.  However, the encrypted part of the client
request is encrypted in (ak_AM+otp) where opt is the otp key and + is
suitably defined. She needs to present it to the KDC as (ak_MB+otp).  We
hope her best option for doing this is brute forcing the key and we hope
the iteration count makes that a bad option.  So, I guess this version
of the attack is about weaker entropy.  The difference is that before
the change to anonymous pkinit, ak_AM was the same as AK_MB. So M didn't
need to do any work to cause the authentication to happen.
She did need to do work to actually use the ticket.
That's interesting because she has a longer window to do that (say 10
hours instead of a minute) and because you've damaged the integrity of
B's auditing.So, we've reduced resources available to M by a factor of
2**9 or so, which isn't great, but is progress.

    > This was added following an issue raised by Greg Hudson
Ah, thanks, makes sense now.

    > unless that KDC can obtain the nonce value used by the first KDC. 
Quoting fast:

fast>   As discussed in Section 5.2, there is no guarantee that a client will
fast>      use the same KDCs for all messages in a conversation.  The mechanism
fast>         specification needs to show why the mechanism is secure in this
fast>	    situation.  The hardest problem to deal with, especially for
fast>	       challenge/response mechanisms is to make sure that the same response
fast>	          cannot be replayed against two KDCs while allowing the client to talk
fast>		     to any KDC.

This text and the first paragraph of section 5.2 don't actually go so
far as to say that the mechanism MUST work in the situation where the
clientcontacts a different KDC, but I certainly think that was our
intent.  It certainly explicitly permis the client to do so and notes
there are situations where the client may not control this even if it
wanted to.  Here's the sort of attack I'm worried about: A KDC
generates a challenge and includes the expected response encrypted in
its cookie.  The client then goes to one KDC and an attacker goes to a
different KDC; the OTP value gets used multiple times.

There are a couple of strategies for dealing with this:

* Some sort of distributed two-phase commit between KDCs or a
  redundant authentication server

* Include a short expiration time and hash of the armor key in the cookie. That may limit things enough . (i'm not sure whether the armor key is guaranteed to be constant within a conversation)

* Argue that given the structure of this mechanism  it's not a huge problem because of the armor key. Other than the issues in section 6.1 (MITM), clients can only shoot themselves.

I don't think you need to pick one of these options.  I do think it
would be good to call out that the replay issues need to be
considered.  I think you already call out that you need to use a
cookie because the client may go to another KDC.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Fri, 27 Aug 2010 12:59:25 -0400

> 
> 
> During writing this message, I noticed that FAST section 
> numbers have changed and your references are stale.  Section 
> 6.2 should be 5.2; 4.4 should be 3.4; any reference you have 
> to 3.1 or 3.2 should be 2.1 or 2.2.
> 
OK, I'll fix those

> OK. There's no text in the draft indicating which of the 
> elements should be given to the user,  and which would 
> typically be searched on a connected token.
> 
I'll add text clarifying this.

> There's no text discussing this.
I'll clarify this

> What do I as a Kerberos implementation do with this PIN once 
This depends on whether the token is connected or not and on whether it
collects its own PIN.  

Tokens that collect their own PIN have a pinpad on them that the user
uses and the tokens then output the OTP value but if the token does not
collect the PIN and a PIN is required then the client must prompt for
it.  These flags inform the client whether or not it needs to do this.  

If client does collect the PIN then what it does with it will depend on
the token type.  If the token is connected then the client will need to
pass the PIN to the token in the OTP value request but if it is not
connected then the OTP value consists of a concatination of the PIN and
the value from the token entered by the user.

I will clarify this. 

> How does that change my behavior as a Kerberos implementation 
> with a disconnected token?  With a connected token?
>
This only applies in the case of connected tokens and the exact
behaviour would depend on the device used.  For example, if it used
PKCS#11 it would control the values of the flags passed to the OTP
mechanism.  But in general, this flag would be used in a device-specific
way to control the combining of the token state with the challenge.  

> authentication to the PIN change service is expected to succeed.
Yes, and probably that the client would be expected to re-try the
authentication to the KDC once the PIN has been changed.

> If we're agreed on direction, I think Tom Yu would probably 
> do a better job of writing text here.
> He's going to be one of the pickiest reviewers  so I'd rather 
> start with something he will like.
> Use string-to-key with the enctype of the armor key, default 
> salt for the principal requested in the as-req and default 
> s2kparams for that enctype
> 
> I think that's OK: you already have an iteration count 
> mechanism of your own.
> 
> 
The iteration count is only required if hashed OTPs are used and so if
they are not used then we will need a default.
This will mean that in the non-hashed OTP case, only defautl s2kparams
can be used.

> If the strengthen-key is present in KrbFastResponse, then it 
> is combined with the reply key to generate the final AS-REQ 
> as described in [ZHA09]. The strengthen-key does not 
> influence the client OTP key.
> 
OK, I'll add it.

> I'm not sure I understand what the client nonce buys us.  In 
> particular the client has already contributed to the armor 
> key. The client needs the KDC to prove that it can decrypt 
> the OTP value, but it does that by using the OTP value in the 
> reply key Again, I'm not asking for changes
> here: this is security sensitive and the draft is 
> conservative. I'm just trying to make sure I understand.
> 
You are starting to convince me that it might not be needed.
The main thing is that the KDC authenticates the client by decrypting
the server nonce that was sent in the challenge and the KDC
authenticates to the client by demonstrating that it has obtained the
same OTP value and generating the same reply key.  The current method of
doing this is to encrypt the nonce sent by the client but the client
could equally well do this by decrypting any data encrypted using the
reply key that it can confirm.  The only reason I really added the nonce
was because it was data known to the client that the client can know was
decrypted correctly and so could rely on the reply key to decrypt the
other encrypted data.

>  We have values assigned but as it turns out they are noted 
> to you  personally rather than to this draft.  Even if they 
> were referenced to  the draft, it makes it much more likely 
> that they would be updated to  the RFC if you reference them. 
>  I think the registry is off of  
> http://www.iana.org/assignments/kerberos-parameters.  You 
> just want to  mention the registry name and which values 
> should be updated to point  to this document.  You may avoid 
> an IESG or IANA comment by mentioning  that key usages and 
> error codes are not currently managed by IANA but  you have 
> coordinated for these assignments.  Alternatively you can  
OK, I'll add the references to section 5 regarding the
pre-authentication types.

What about key usage types? The draft also includes
KEY_USAGE_OTP_CONFIRM and KEY_USAGE_OTP_REQUEST.

> I don't think so.  Let's consider two situations.  First, the 
> OTP value is sent.  That is vulnerable to a classic MITM 
> issue unless the KDC certificate is verified by the client.
> 
> Here's what happens:
> M learns the OTP value because it is sent encrypted in ak_AM. 
> M re-encrypts the OTP value and the rest of the request in AK_MB.
> She can optionally forward the ticket  encrypted in the reply 
> key ak_AM on to A if desired.
> 
> That's a fairly classic MITM and really isn't about entropy 
> so much as sending your authentication credential to the attacker.
> 
> Now let's consider the case where the OTP value is not sent.  
> Here, M can mount the same attack.  However, the encrypted 
> part of the client request is encrypted in (ak_AM+otp) where 
> opt is the otp key and + is suitably defined. She needs to 
> present it to the KDC as (ak_MB+otp).  We hope her best 
> option for doing this is brute forcing the key and we hope 
> the iteration count makes that a bad option.  So, I guess 
> this version of the attack is about weaker entropy.  The 
> difference is that before the change to anonymous pkinit, 
> ak_AM was the same as AK_MB. So M didn't need to do any work 
> to cause the authentication to happen.
> That's interesting because she has a longer window to do that 
> (say 10 hours instead of a minute) and because you've damaged 
> the integrity of B's auditing.So, we've reduced resources 
> available to M by a factor of
I was really thinking of the second case, where the OTP value is not
being sent.
The first case where the OTP is sent already covered in the security
considerations and it looks as if this is really the same issue.  It
looks as if I'll just need to alter the third paragraph of section 6.1.

> This text and the first paragraph of section 5.2 don't 
> actually go so far as to say that the mechanism MUST work in 
> the situation where the clientcontacts a different KDC, but I 
> certainly think that was our intent.  It certainly explicitly 
> permis the client to do so and notes there are situations 
> where the client may not control this even if it wanted to.  
> Here's the sort of attack I'm worried about: A KDC generates 
> a challenge and includes the expected response encrypted in 
> its cookie.  The client then goes to one KDC and an attacker 
> goes to a different KDC; the OTP value gets used multiple times.
> 
> * Include a short expiration time and hash of the armor key 
> in the cookie. That may limit things enough . (i'm not sure 
> whether the armor key is guaranteed to be constant within a 
> conversation)
> 
> * Argue that given the structure of this mechanism  it's not 
> a huge problem because of the armor key. Other than the 
> issues in section 6.1 (MITM), clients can only shoot themselves.
> 
> I don't think you need to pick one of these options.  I do 
> think it would be good to call out that the replay issues 
> need to be considered.  I think you already call out that you 
> need to use a cookie because the client may go to another KDC.
> 
>
If two responses were played for a single challenge against two KDCs
then it would not be a serious issue (apart from denial of service) for
time or event-based tokens since the OTP replay would be detected by the
OTP server.  (This is already covered in section 6.4.)  It would however
be a potential problem for pure challenge-response tokens that do not
include a time or coutner value in the response calculation. I will add
text to the security considerations regarding this.

---

From: Greg Hudson <[email-masked]>
Date: Fri, 27 Aug 2010 13:13:09 -0400

On Fri, 2010-08-27 at 12:59 -0400, [email-masked] wrote:
> The only reason I really added the nonce

Kerberos encrypted messages use authenticated encryption, so you find
out immediately if you used the wrong key, even if you don't know
anything about the correct plaintext.  (This isn't always a good thing
when you're contemplating off-line dictionary attacks.)

If this element of the draft turns out to be unnecessary, I would prefer
that it be removed--as opposed to Sam who was not making such a request.

I hope to fully review the draft during the last call period but have
not yet done so.

---

From: <[email-masked]>
Date: Fri, 27 Aug 2010 13:20:24 -0400

> > The only reason I really added the nonce was because it was 
> data known 
> > to the client that the client can know was decrypted 
> correctly and so 
> > could rely on the reply key to decrypt the other encrypted data.
> 
> Kerberos encrypted messages use authenticated encryption, so 
> you find out immediately if you used the wrong key, even if 
> you don't know anything about the correct plaintext.  (This 
> isn't always a good thing when you're contemplating off-line 
> dictionary attacks.)
> 
> If this element of the draft turns out to be unnecessary, I 
> would prefer that it be removed--as opposed to Sam who was 
> not making such a request.
> 
> I hope to fully review the draft during the last call period 
> but have not yet done so.
> 
> 
I am now even more convinced that this can probably be removed. 
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 Aug 2010 13:25:43 -0400

It's starting to sound like my concerns about the key-info and other
values would best be addressed by a client behavior section.

If I'm understanding correctly, we have two very different behaviors:

* disconnected: The client presents the vendor string and challenge to
the user. The client ignores the combine flag.  Because the client
doesn't know about the OTP profile really it needs to actually send the
OTP value unless the must-encrypt-OTP flag is set.

If the PIN is required then the client simply concatenates this into the
OTP value.

* connected:
The client uses the vendor-id, key-id, alg-id to find the right
token. The client may display the vendor-id and key-id to the user to
help them if the token is not already inserted.
The client passes the  combine flag to the token.
The client inputs a pin if requested and passes that to the token.

I wonder if the current PIN flags describe the right behavior.  In
particular, is it the need for a PIN that's interesting or the need for
the system to collect a PIN?
Should we say that tokens with PIN pads should be treated as
pin-not-required for this protocol?
    > text to the security considerations regarding this. 

You're assuming the existence of an OTP server that is either not
redundant or that involves a commit protocol.  That's a significant
operational consideration that's not documented in the draft. It's
certainly not a surprise, but it's important to someone doing an
operational/security analysis of this protocol.
I'd probably explicitly call this out in 6.4.

I think the only other issue we have open at this point is s2kparams.
My preference would be to say that if default s2kparams aren't good
enough you should use hashed OTP values.  however the current text is
also acceptable and unless a bunch of other people chime in, the final
decision sholud be yours.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Tue, 31 Aug 2010 11:03:35 -0400

Sam,

> 
> It's starting to sound like my concerns about the key-info 
> and other values would best be addressed by a client behavior section.
> 
> * disconnected: The client presents the vendor string and 
> challenge to the user. The client ignores the combine flag.  
> Because the client doesn't know about the OTP profile really 
> it needs to actually send the OTP value unless the 
> must-encrypt-OTP flag is set.
> 
Yes, the client would display the otp-service if there is one to
identify the purpose of the authentication and then for each otp-keyInfo
it would display the otp-vendor if present to identify the type of token
the user should use and if thereis an otp-challenge then it would also
display that so that the user can enter it into the token.
	
The client should only include the OTP in the PA-OTP-REQUEST if required
by the OTP algorithm (e.g. an S/Key [RFC2289]-like algorithm) and
permitted by the KDC (the must-encrypt-nonce flag is not set).
Generally, a user will only be able to use one token to authentication
to a particular KDC and so the KDC will know whether or not to set this
flag.  However, if a user has multiple tokens of different types that
they can use then the PA-OTP-CHALLENGE that there will be an otp-keyInfo
for each token and this element will contain a must-encrypt-nonce if the
OTP should be hashed for that token.  If there are multiple of these
then the client will need to prompt the user to select the token that
they are going to use so that it can then hash or not hash accordingly.

The current ID is based on the assumption that it will be prfiled for
different tokens based on the oalgorithm ID (otp-algID).  For example,
it might state that a client MUST return OTP values in plain text unless
the KDC sets the must-encrypt-nonce flag.

> If the PIN is required then the client simply concatenates 
> this into the OTP value.
> 
Yes, if the client collects a PIN.

> * connected:
> The client uses the vendor-id, key-id, alg-id to find the 
> right token. The client may display the vendor-id and key-id 
> to the user to help them if the token is not already inserted.
The client only needs to collect the PIN if the pin-required flag is set
for the particular token.

> I wonder if the current PIN flags describe the right 
> behavior.  In particular, is it the need for a PIN that's 
> interesting or the need for the system to collect a PIN?
It is the need to collect a PIN.  The idea is that the two flags
pin-required and pin-not-required inform the client whether or not it
needs to collet a PIN from the user.  Tokens with pin-pads collect their
own PINs and don't affect the client in any way.  Maybe the flags should
be renamed to something like collect-pin and do-not-collect-pin.

> You're assuming the existence of an OTP server that is either 
> not redundant or that involves a commit protocol.  That's a 
> significant operational consideration that's not documented 
> in the draft. It's certainly not a surprise, but it's 
> important to someone doing an operational/security analysis 
> of this protocol.
Yes, I am assuming this and I agree that it should be called out in
section 6.

> My preference would be to say that if default s2kparams 
> aren't good enough you should use hashed OTP values.  however 
> the current text is also acceptable and unless a bunch of 
> other people chime in, the final decision sholud be yours.
> 
> 
I would think that it seems reasonable to use the default string-to-key
paramters for the armor key enctype, but what about the salt?  I am not
sure about using the same default salt (section 4 of RFC4120) for each
authentication.

--Gareth