Subject: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme)

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 10 Oct 2014 09:26:26 -0400

Hi,

During the IETF conference in London and as a response to my presentation
of the update to the SIP Digest, there was interest in the room for
exploring better schemes than the existing Digest scheme.

I have just submitted an draft that describes a new proposal for an
authentication scheme that is based on the PBKDF2 function, to replace the
Digest scheme used by SIP today.

I would really appreciate it if people review it and provide comments.

Regards,
 Rifaat

---------- Forwarded message ----------
From: <[email-masked]>
Date: Fri, Oct 10, 2014 at 9:19 AM
Subject: New Version Notification for
draft-yusef-sipcore-key-derivation-00.txt
To: Rifaat Shekh-Yusef <[email-masked]>

A new version of I-D, draft-yusef-sipcore-key-derivation-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:           draft-yusef-sipcore-key-derivation
Revision:       00
Title:          Key-Derivation Authentication Scheme
Document date:  2014-10-10
Group:          Individual Submission
Pages:          8
URL:
http://www.ietf.org/internet-drafts/draft-yusef-sipcore-key-derivation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-yusef-sipcore-key-derivation/
Htmlized:
http://tools.ietf.org/html/draft-yusef-sipcore-key-derivation-00

Abstract:
   This document defines a Key-Derivation Authentication Scheme, based
   on the PBKDF2 Key Derivation Function (KDF), that could be used with
   the challenge-response authentication framework used by SIP to
   authenticate the user.

   The scheme allows two parties to establish a mutually authenticated
   communication channel based on a shared password, without ever
   sending the password on the wire.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 10 Oct 2014 14:48:34 -0400

> Name:           draft-yusef-sipcore-key-derivation

It's an interesting proposal.  The most important thing is that I'd
like to see a section that describes the motivation, that is, why this
is method better than the current digest scheme.  (Laying out the case
is something that could progress before tidying the technical
presentation.)

There are a bunch of parameters to this algorithm, and it would be
helpful to know what are the considerations that drive the choice of
parameter values.  This is especially true for the iteration-count;
the NIST document proposes a range of 1,000 to 10,000,000, but the
computation power that a typical phone can apply to the problem is
limited.  (Also, is the master-key recomputed just once when the phone
is reconfigured with a new password, or with every message?  For that
matter, how does the phone obtain the salt and iteration count when it
is configured?)

Given the large number of parameters, it would be helpful to have a
small number of particular choices/combinations that are proposed for
use.

I see:

- nonce length
- the hash function used in the KDF
- the salt length
- the iteration count
- the length of the generated master key

Looking at the diagram on page 4, it appears that message 2
(Challenge) contains "pop" which is computed as
"HMAC-SHA256(master-key, digest-string + nonce)".  Message 3
(Response) contains "pop" which is also shown being computed as
"HMAC-SHA256(master-key, digest-string + nonce)", which the server is
supposed to verify, even though it appears that that value was
transmitted in the clear in message 2.  I'm pretty sure that the issue
is that the first "digest-string" is the digest string of message 1
(the original request), whereas the second one is the digest string of
message 3.  But the notation should make that clear.  For that matter,
the notation should make clear which bulleted items are computations,
which are tests, which data items are retrieved from local memory,
which are random numbers constructed at the moment, etc.

Message 4 contains "token", but there is no definition of that.
Indeed, if this scheme is meant only to provide mutual agreement on a
cryptographically stronger key to be input to digest authentication,
there isn't any "token", is there?

Dale

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 11 Oct 2014 06:57:41 -0400

Hi Dale,

Thanks for a thorough review and great feedback, as always.
Please, see my reply inline...

Regards,
 Rifaat

On Fri, Oct 10, 2014 at 2:48 PM, Dale R. Worley <[email-masked]> wrote:

> Agree. Will add a new section to the next version of the draft.

> limited.

Agree.

> (Also, is the master-key recomputed just once when the phone
> is reconfigured with a new password, or with every message?

Yeah, there are few options here:
I was thinking of creating a new master-key every time the phone refreshes
registrations.
Other options is to tie it to some timer, or the number of times that the
master-key was used.
There is a need for some discussion around this.

> For that
The phone obtains these from the Challenge request.

> - the length of the generated master key
Ok.

> (the original request),

No, this is the pop for the Challenge sent by the server.

The idea is that the server uses the master-key to compute the pop over the
Challenge to prove to the client that it is in possession of the
master-key. When the client receives the Challenge, it will be able to
create the master-key based on the Challenge and then locally compute the
same pop over the Challenge to compare it to the pop received in the
challenge.

The client then creates a pop for the Response to prove to the server that
it is in possession of the password/master-key, and sends it to the server.
When the server receives the response, it will be able to locally compute
the pop of the response and compare it to the pop received from the client.

I will try to clarify this in the next version of the draft.

> whereas the second one is the digest string of
Agree.

> there isn't any "token", is there?
Yes, you are right; no tokens here. Copy & paste mistake.

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Oct 2014 11:43:48 -0400

Rifaat,

Thanks for taking a crack at this. I have a lot of questions.

Is it your plan to use the existing sip authentication headers with a 
new auth-scheme? (IMO that is the preferred path unless there are 
reasons it won't work.) If so, it would be very helpful to show the call 
flows using those terms.

You show an initial-request, then a response, then an confirmation. IIUC 
the challenge will be carried in the sip response to the 
initial-request. Verification of the pop from the server will require 
the digest-string from the initial request - not the response. Is that 
what you want? Then the "response" will be carried in a new sip request, 
that has a different digest-string. I don't think the existing text is 
consistent with this usage.

Note that RFC4474 hasn't been a great success. Part of the trouble is 
that the digest-string includes stuff that often is disturbed in 
existing deployments. STIR is proposing to reduce what is included in 
the digest. That might be the right thing to use here, or it might not 
be enough. Needs consideration.

	Thanks,
	Paul

On 10/10/14 9:26 AM, Rifaat Shekh-Yusef wrote:
> Hi,
>
> During the IETF conference in London and as a response to my
> presentation of the update to the SIP Digest, there was interest in the
> room for exploring better schemes than the existing Digest scheme.
>
> authentication scheme that is based on the PBKDF2 function, to replace
> the Digest scheme used by SIP today.
>
> From: ** <[email-masked] <mailto:[email-masked]>>
> To: Rifaat Shekh-Yusef <[email-masked]
> <mailto:[email-masked]>>
>
>
>
> Status: https://datatracker.ietf.org/doc/draft-yusef-sipcore-key-derivation/
> Htmlized: http://tools.ietf.org/html/draft-yusef-sipcore-key-derivation-00
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org
> <http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 13 Oct 2014 13:24:07 -0400

Thanks Paul,

Regards,
 Rifaat

On Mon, Oct 13, 2014 at 11:43 AM, Paul Kyzivat <[email-masked]>
wrote:

> Is it your plan to use the existing sip authentication headers with a new
> auth-scheme? (IMO that is the preferred path unless there are reasons it
> won't work.)

Definitely Yes.

> If so, it would be very helpful to show the call flows using those terms.
>

Ok.

> the challenge will be carried in the sip response to the initial-request.
> Verification of the pop from the server will require the digest-string from
> the initial request - not the response. Is that what you want?

No. I want the client to validate the pop (the digest-string of the
Challenge) sent by the server in the Challenge to prove to the client it is
in possession of the master-key, and later for the server to validate the
pop (the digest-string of the Response) sent by the client in the Response
to prove to the server that it is in possession of the password/master-key.

I will clarify this point.

> Then the "response" will be carried in a new sip request, that has a
> different digest-string. I don't think the existing text is consistent with
> this usage.
>
> Note that RFC4474 hasn't been a great success. Part of the trouble is that
> the digest-string includes stuff that often is disturbed in existing
> deployments. STIR is proposing to reduce what is included in the digest.
> That might be the right thing to use here, or it might not be enough. Needs
> consideration.
>

Ok. I will take a look at STIR.

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Oct 2014 14:15:29 -0400

On 10/13/14 1:24 PM, Rifaat Shekh-Yusef wrote:
> On Mon, Oct 13, 2014 at 11:43 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Rifaat,
>
>     Is it your plan to use the existing sip authentication headers with
>     a new auth-scheme? (IMO that is the preferred path unless there are
>     reasons it won't work.)
>
>
> Definitely Yes.
>
>     You show an initial-request, then a response, then an confirmation.
>     IIUC the challenge will be carried in the sip response to the
>     initial-request. Verification of the pop from the server will
>     require the digest-string from the initial request - not the
>     response. Is that what you want?
>
>
> Challenge) sent by the server in the Challenge to prove to the client it
> is in possession of the master-key, and later for the server to validate
> the pop (the digest-string of the Response) sent by the client in the
> Response to prove to the server that it is in possession of the
> password/master-key.

Then this will require creating a digest-string over a response. RFC4474 
only defines it for a request, though all the fields it contains are 
also present in a response, so it is straightforward to define.

>     different digest-string. I don't think the existing text is
>     Note that RFC4474 hasn't been a great success. Part of the trouble
>     is that the digest-string includes stuff that often is disturbed in
>     existing deployments. STIR is proposing to reduce what is included
>     in the digest. That might be the right thing to use here, or it
>     might not be enough. Needs consideration.
>
>
>         From: ** <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>         draft-yusef-sipcore-key-__derivation-00.txt
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__>
>
>
>
>         A new version of I-D, draft-yusef-sipcore-key-__derivation-00.txt
>         Name:           draft-yusef-sipcore-key-__derivation
>         Revision:       00
>         http://www.ietf.org/internet-__drafts/draft-yusef-sipcore-__key-derivation-00.txt
>         <http://www.ietf.org/internet-drafts/draft-yusef-sipcore-key-derivation-00.txt>
>         Status:
>         https://datatracker.ietf.org/__doc/draft-yusef-sipcore-key-__derivation/
>         <https://datatracker.ietf.org/doc/draft-yusef-sipcore-key-derivation/>
>         Htmlized:
>         http://tools.ietf.org/html/__draft-yusef-sipcore-key-__derivation-00
>         <http://tools.ietf.org/html/draft-yusef-sipcore-key-derivation-00>
>
>
>         Abstract:
>         until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>
>         <http://tools.ietf.org>.
>
>         The IETF Secretariat
>
>
>
>
>         _________________________________________________
>         sipcore mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/sipcore
>         <https://www.ietf.org/mailman/listinfo/sipcore>
>
>
>     _________________________________________________
>     sipcore mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/sipcore
>     <https://www.ietf.org/mailman/listinfo/sipcore>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 Oct 2014 18:42:11 +0000

Hi Rifaat,

What do you mean by "uniquely generated" (for the nonce value)?

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Rifaat Shekh-Yusef
Sent: 10 October 2014 16:26
To: [email-masked]
Subject: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme)

Hi,

During the IETF conference in London and as a response to my presentation of the update to the SIP Digest, there was interest in the room for exploring better schemes than the existing Digest scheme.

I have just submitted an draft that describes a new proposal for an authentication scheme that is based on the PBKDF2 function, to replace the Digest scheme used by SIP today.

Regards,
 Rifaat

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Fri, Oct 10, 2014 at 9:19 AM
Subject: New Version Notification for draft-yusef-sipcore-key-derivation-00.txt
To: Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>>

URL:            http://www.ietf.org/internet-drafts/draft-yusef-sipcore-key-derivation-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 13 Oct 2014 14:58:53 -0400

Hi Christer,

It means that the client/server must generate a new unique nonce for each
request/response.
A good example would be a time-stamp that includes micro or even nano
seconds.

I will add more text around this.

Regards,
 Rifaat

On Mon, Oct 13, 2014 at 2:42 PM, Christer Holmberg <
[email-masked]> wrote:

> *From:* sipcore [mailto:[email-masked]] *On Behalf Of *Rifaat
> Shekh-Yusef
> *Sent:* 10 October 2014 16:26
> *To:* [email-masked]
> *Subject:* [sipcore] Key-Derivation Authentication Scheme proposal (to
> replace Digest scheme)
>
>
>
> Hi,
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 13 Oct 2014 18:59:04 +0000

Hi,

A minor editorial comment, related to Paul's request for some flows: 

I think it would be useful to separate between "SIP response" and "challenge response".

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 13 October 2014 21:15
To: Rifaat Shekh-Yusef
Cc: [email-masked]
Subject: Re: [sipcore] Key-Derivation Authentication Scheme proposal (to replace Digest scheme)

On 10/13/14 1:24 PM, Rifaat Shekh-Yusef wrote:
> Challenge) sent by the server in the Challenge to prove to the client 
> it is in possession of the master-key, and later for the server to 
> validate the pop (the digest-string of the Response) sent by the 
> client in the Response to prove to the server that it is in possession 
> of the password/master-key.

Then this will require creating a digest-string over a response. RFC4474 only defines it for a request, though all the fields it contains are also present in a response, so it is straightforward to define.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 13 Oct 2014 16:43:41 -0400

> From: Rifaat Shekh-Yusef <[email-masked]>

> There is a need for some discussion around this.

As the processing is shown in the draft, the phone doesn't get to
choose when to calculate a master key, it must do so whenever the
parameters presented in the challenge change.

> The phone obtains these from the Challenge request.

There are a number of inputs to the generic key-derivation function.
This one is presumably configured into the phone by whatever means are
now used for configuring passwords into the phone:
- password

These are presented by the UAS in the 401/407 challenge:
- the identity of the HMAC hash algorithm
- salt
- key-size
- iteration-count

The phone has to do a lot of computation to produce the master key
from these data.  The advantage that is gained is that the master key
is more resistant to a dictionary attack because of the additional
entropy provided by the salt, and the master key is cryptographically
random, providing less opportunity to attack the hash that computes
the message digest.

But at least in this form, the last four data items could vary on a
request-by-request basis, which is probably computationally infeasible
for the phone to deal with.  At the least, you'd want the phone to
cache the results of one master key computation and hope that the
parameters don't change from request to request.

Given that phones are now generally configured by automated means, I'm
wondering if it would not be equally effective to have some process in
the configuration system compute a master key using the NIST method
and then deliver the master key to the phone by the existing
configuration mechanisms.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Oct 2014 23:55:12 -0400

> configuration mechanisms.

That puts the master key on the wire. To make it safe you would have to 
encrypt it.

	Thanks,
	Paul

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 14 Oct 2014 08:28:18 -0400

Hi Dale,

The master-key is tied to the password selected by the user and it changes
only when the user changes his password.
If we want to be able to change keys on the fly, e.g. during registration
refresh, then a new key must be created that is derived from the
master-key, e.g user-key, which will be used to calculate the pop.
This means that the master-key will only be used to create user-keys, which
will be updated every once in a while.
This will complicate things a bit, but is doable. I will try to capture the
idea in the new version of the draft so we could discuss this.

Regards,
 Rifaat

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 14 Oct 2014 16:26:09 -0400

> From: Christer Holmberg <[email-masked]>

> I think it would be useful to separate between "SIP response" and

Yes.  I was losing track of that myself.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 14 Oct 2014 16:31:23 -0400

> A good example would be a time-stamp that includes micro or even nano

I don't think you want to say it that way.  (1) It assumes that the
device knows what time it is.  (2) It assumes that there is only one
message sent during a micro- or nano-second.

As written, a sequence number would suffice.  (You'd need some way of
initializing the sequence number on bootup to ensure you didn't start
counting from zero each time.)  But that raises the question, does the
nonce have to be pseudo-random, or perhaps even cryptographically
random?

My guess is that you want the nonce to be pseudo-random (to prevent
exploitation of regularities in the nonces) but don't need
crypto-random (predictability is not a problem).  So hashing a
sequence number with some sort of per-device identifier would suffice.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 14 Oct 2014 16:36:07 -0400

> From: Paul Kyzivat <[email-masked]>
> 

You're stating that a requirement is that the master key does not pass
on the wire in plaintext.

My understanding is that most phones these days (at least in
enterprise settings) obtain their passwords via some sort of
configuration system that runs at boot time -- the password is *not*
entered by the user into the user interface.  And the password passes
over the wire in plaintext.  (Or it might as well be in plaintext, if
we allow the attacker to modify traffic, because the phone has no
prior secret identifier.)

If we really want key secrecy, we'll need more specifications than are
now described in the draft, and they will have to include how the
phone is configured.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 14 Oct 2014 16:42:11 -0400

> only when the user changes his password.

As shown in the draft, the master-key depends on the KDF, salt,
key-size, and iteration-count.  All four of those are presented in the
challenge by the UAS.  If the master-key "changes only when the user
changes his password", then there must be a requirement that the UAS
(and every UAS in that authentication realm) must always use the same
values for those parameters (until the password changes).

> idea in the new version of the draft so we could discuss this.

The NIST document demands that the master-key is only used to generate
shorter-lived keys, although we don't necessarily have to follow that.

As far as I can tell, the -00 doesn't discuss "changing keys on the
fly".  What are the motivations for that?

Dale