Subject: [Sip] Nit in draft-ietf-sip-gruu-11.txt

From: [email-masked]
Date: Mon, 19 Feb 2007 14:32:01 -0500

There's a nit in draft-ietf-sip-gruu-11.txt:  In Appendix A, it reads:

   When the first contact with a specific instance ID is registered, the
   proxy generates a fresh initialization vector (IV) I. It also notes
   the wallclock time (W) and stores this as part of the registration.
   When the registrar wishes to create a new temporary GRUU, it
   computes:

    EA = E(K_e, AOR || " " || instance_ID || W || T1 || T2 || .. || Tn)

   using initialization vector I where || indicates concatenation, and
   T1, T2, and so on represent the current expiration times (measured in

But the "initialization vector I" does not appear in the computation
of EA.  I suspect something is missing from the concatenation that is
the second argument of E().

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 19 Feb 2007 12:38:12 -0800

> the second argument of E().

It's not missing. The text says "using initialization vector I".
AFAICT common practice is not to have the IV be an explicit argument
when you represent encryption.

-Ekr

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2007 09:41:29 -0500

To be clear, the IV itself is not included in the hash, right? Its 
merely used to seed the process?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: EKR <[email-masked]>
Date: Wed, 28 Feb 2007 06:49:14 -0800

> merely used to seed the process?

Well, it's transitively included in the hash because we're going
to MAC EA.

That said, there's a bit of a race condition here because 
draft-rescorla-stateless-tokens-00 defines a generalized
version of this stateless token technique. It may be best to
simply define GRUU as using that technique.

-Ekr

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2007 10:14:34 -0500

This is a great draft, ekr. I think it will come in handy in lots of 
places.

A couple of questions.

Firstly, what is the current status on this? Are you going to push this 
through as an AD-sponsored individual? Or is it an IAB doc? Or for a WG? 
What is the timeline?

Assuming it will be going forward, I think it would be fine to reference 
it. The reference can be informative since the entire appendix is an 
informational appendix on how to do this. This way GRUU won't block on 
it. So, what we'd need to do is restructure the text in that appendix to 
use your tokens draft.

I *think* that all we need to do there is specify the format for the 
string S, which would be:

AOR || " " || instance-ID || W || T1 || T2 || .. || Tn

and then tell folks to use your draft to construct a state token. I 
think we'd ignore sequence numbers and timestamps; making these zero. 
The reason is that temp-gruu don't have a fixed expiration time, its 
linked to expiration of the contacts and thats why W is in the state 
itself. Similarly for sequence numbers; T1.. Tn form our sequence number 
as part of the state, not in the token itself. Do you agree?

After the token is constructed, the user part becomes

user-part = "GRUU" || BASE64(token)

Is that right?

If so I will draft some text for this right now and post it.

I'm in the process of updating GRUU for the other main change we agreed, 
on how to invalidate temp-gruu on the client side.

Thanks,
Jonathan R.

---

From: EKR <[email-masked]>
Date: Wed, 28 Feb 2007 07:43:11 -0800

> This is a great draft, ekr. I think it will come in handy in lots of

Thanks.

> A couple of questions.
>
> Firstly, what is the current status on this? Are you going to push
> this through as an AD-sponsored individual? Or is it an IAB doc? Or
> for a WG? What is the timeline?

All good questions. I just fired off mail to the SEC ADs and 
Fluffy to ask for advice.

> Assuming it will be going forward, I think it would be fine to
> reference it. The reference can be informative since the entire
> appendix is an informational appendix on how to do this. This way GRUU
> won't block on it.

Ah. Good point!

> think we'd ignore sequence numbers and timestamps; making these
> zero. The reason is that temp-gruu don't have a fixed expiration time,
> its linked to expiration of the contacts and thats why W is in the
> state itself. Similarly for sequence numbers; T1.. Tn form our
> sequence number as part of the state, not in the token itself. Do you
> agree?

Hmm... So, we're assuming there's no way to revoke tokens other
than terminating the underlying registration? I'm trying to decide
if that's really true.

> user-part = "GRUU" || BASE64(token)

Yeah, that sounds right.

-Ekr

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Feb 2007 11:09:49 -0500

inline.

> than terminating the underlying registration? I'm trying to decide

Yes, since we have no way to inform the client that they've been 
revoked, beyond terminating the registration.

I suppose a server could revoke a single temp-gruu without informing the 
client about it, or we could develop mechanisms in the future to inform 
the client. In that case, you would want the sequence number. The text 
could indicate that the sequence numbers would be used in the future if 
such capabilities were added.

The timestamp would still be empty though, unless we had, in the future, 
a mechanism for time-limited temp-gruu. Again the text could say that to 
leave the door open.

-Jonathan R.