Subject: [Sipping] Unofficial communication from ITU-T on T.38

From: Glenn Parsons <[email-masked]>
Date: Thu, 14 Mar 2002 15:35:06 -0500

Folks,

I am not sure if the official communication from ITU-T SG16 on T.38 has been
sent/received on what is now draft-ietf-sipping-realtimefax-00.txt (it was
draft-mule-sip-t38callflows-02.txt.  )

As a result, in order to ensure that the group is aware of this before the
meeting next week, I have attached a copy of the communication below.

Cheers,
Glenn.

_____________________
COMMUNICATIONS STATEMENT
TO:    IETF SIPPING WG
APPROVAL:    Agreed to at SG16 meeting (Geneva, 5-15 February 2002)
(proposed)
FOR:    Action
DEADLINE:    April 2002
    
CONTACT:    Mr. Tom Geary
Rapporteur Q14/16         Tel:+1 949 483 4092
 Fax:+1 714 446 9642
E-mail : [email-masked]
_____________________
1. Introduction

At the ITU-T SG16 held 5-15 February 2002, the facsimile experts of Q14/16
had the opportunity to review the proposed call flow examples of
draft-mule-sip-t38callflows-02.txt.  We have a number of general and
specific comments that we would like to present.

2. General Comments

Q.14/16 is interested in collaborating with the SIPPING WG on the T.38 SIP
call flows work.  We would appreciate if future comments on this Internet
Draft could be copied to our experts mailing list to allow ITU-T fax experts
an opportunity to comment.  The group¹s mailing list is:  [email-masked]

Also, Q.14/16 would like to point out that at our meeting held 5-15 February
2002, a revised Recommendation T.38 was consented (similar to IETF last
call).  As well as fixing minor issues, this revised Recommendation
incorporates all of the pieces of T.38 into one document.  If it is approved
(that is, no negative technical comments are received), this Recommendation
will be available on the ITU-T website in May 2002 at the following URL:
http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-T
.38

IANA has finally registered the requested T.38 SDP extensions.  They can be
viewed at: http://www.iana.org/assignments/sdp-parameters.  Note, however,
that the addition of the image/t38 MIME type is still in process as it
requires the approval of an RFC documenting the registration  (see
draft-parsons-itu-t38-reg-00.txt ).

Q.14/16 would like to suggest adding the call flows of this Internet Draft
to Rec. T.38.  Unfortunately, the ITU-T process will not allow the
referencing of a non-ŒStandards Track¹ IETF RFC in an ITU-T Recommendation.
As a result, we would suggest referencing this document in a future
informative Appendix to Rec. T.38 (similar to the current Appendix
describing H.248 call flows).

We note from the SIPPING WG status web page that the intent is to include
call flows for modems over IP (MoIP) in this document.  V.MoIP is currently
under study in Q.11/16 (the group¹s mailing list is:  [email-masked]).  As
this work is expected to be significantly different, Q.14/16 recommends that
SIP call flows for MoIP be detailed in a separate document.  It would make
sense in this separate document to describe the SIP call flows of V.34
half-duplex T.38 as well as V.MoIP as both will require V.8 control signal
analysis for call discrimination.  This would allow the immediate
publication of the current draft for the benefit of the industry.

2. Specific Comments

We reviewed text on call discrimination in section 4.  We agree with this
process for pre-V.34 implementations.  As a result, the section title should
indicate ³Šand fax detection up to V.17 (14400bps)².  SG16 is currently
working on extensions to T.38 to support V.34 fax, as well as a new
Recommendation to support modems over IP.  We therefore suggest that the
following sentence be added to the end of section 4.1.:

Note that V.34 half-duplex fax (up to 33600bps) over T.38 will require use
of more complex call discrimination methods that will require analysis of
V.8 control signals (that are also used for V.34/V.90 data).  An Amendment
to Rec. T.38 to support V.34 fax, as well as a new Recommendation V.MoIP to
describe data modem over IP are under study in ITU-T SG16.

Further, we confirm that fax detection (of V.21 flags) by the receiving
gateway is the preferred method.  This was our original intent and we have
modified Rec. T.38 section D.2.2.4 to reflect that.  In addition , we have
also indicated that both Œvoice and fax¹ and Œfax replaces voice¹ modes are
possible.  We note that you recommend Œfax replaces voice¹ and would be
interested in understanding the rational for this choice.

In section 4.4 (and at least example 6.2) it is indicated that when falling
back to Œpass-through¹ mode several characteristics should be followed.  You
should note that Q.11/16 is defining specific characteristics for a pass
though mode in V.MoIP that is called Œvoice band data¹.  For your
information, the current definition in V.MoIP is:

For Voice Band Data (VBD) mode of operation, the path between G1 and G2
remains in a voice configuration. The modem signals are encoded using an
appropriate speech codec suitable for the task and the samples are
transported across a packet network.

VBD should:
o Use a voice codec that passes voice band modulated signals with minimal
distortion.
o Have end-to-end constant latency.
o Disable Voice Activity Detection (VAD) and Comfort Noise Generation (CNG)
during the data transfer phase.
o Disable any DC removal filters that may be integral with the speech
encoder used.
o Be capable of tone detection, including mid-call DTMF, as well insertion
of tones, announcements, voice prompts etc.

VBD should consider the appropriate application of:
o The use of echo cancellers on a VBD channel.
o Forward Error Correction (FEC) (e.g. RFC 2733) or other forms of
Redundancy (e.g. RFC 2198).
o Voice packet loss concealment techniques and algorithms that may not be
suitable for VBD.

While SG16 agrees that G.711 is a valid codec that can be used for this, we
are concerned about your the choice of enabling the echo canceller.  You
will note that we have not made a recommendation for enabling or disabling
echo cancellation in VBD.  In T.30 transmission, however, echo cancellers
may be turned off (by the appropriate answer tone) for a more effective fax
transmission.  Hence there are varying perspectives on the most applicable
setting for echo cancellation amongst ITU-T fax and modem experts.  We would
appreciate understanding your rationale for this recommendation.  In
addition, you should note that the presence of adverse network conditions
(notably jitter and delay) will have a significant effect on whether the fax
connection will be successful.

Section 5.1 indicates that the T.38 Annex D is a temporary document  this
is incorrect.  T.38 Annex D should be introduced earlier in this document.
However, in this case, we suggest that a more appropriate description would
simply delete everything after the comma:

The mechanism for supporting T.38 in SIP & SDP is detailed in T.38 Annex D
[9].

In section 5.2, contrary to section 4.1 (and the terminology of Rec. T.38),
the term Œterminating gateway¹ is used instead of Œreceiving gateway¹.  The
document should be consistent and use the terms emitting gateway and
receiving gateway (as defined in Rec. T.38) throughout.

In section 3.1 and before F11 of section 5.2.2 and 5.3.2 it notes that the
CNG (and other tones including V.21 flags) can be sent in-band.  You should
note that CNG and these other tones sent in-band in any codec besides Œtoll
quality codecs¹ like G.711 A or mu-law (and especially in compressed codecs)
will not be recognizable by the receiving fax machines.  This should be
explained in the text.

In section 7 (and in many of the examples in section 5), values of Œ0¹ are
given to the boolean SDP attribute names.  This is incorrect, the attributes
are defined as boolean without values.  That is, their presence on an a=
line indicates that they are true for the session.  As a result, this
informative table requires modifications.  Further, many of the examples
will also need modification.  For example, the SDP in the first example in
section 5.1.2 should be:

F1 INVITE  I.FAX UA -> PROXY
    
      INVITE sip:[email-masked];user=phone SIP/2.0
      Via: SIP/2.0/UDP ifax.here.com:5060
      From: sip:[email-masked];user=phone;tag=ab111
      To: sip:[email-masked];user=phone
      Call-ID: [email-masked]
      CSeq: 17 INVITE
      Contact: <sip:[email-masked]>
      Content-Type: application/sdp
      Content-Length: 320
    
      v=0 
      o=ifaxgw1 2890846527 2890846527 IN IP4 ifax.here.com
      s=Session SDP
      c=IN IP4 ifaxmg.here.com
      t=0 0 
      m=image 15002 udptl t38
      a=T38FaxVersion:0
      a=T38MaxBitRate:14400
      a=T38FaxFillBitRemoval
      a=T38FaxTranscodingMMR
      a=T38FaxTranscodingJBIG
      a=T38FaxRateManagement:transferredTCF
      a=T38FaxMaxBuffer:72
      a=T38FaxMaxDatagram:316
      a=T38FaxUdpEC:t38UDPFEC
      a=T38FaxUdpEC:t38UDPRedundancy

_____________________

---

From: Allison Mankin <[email-masked]>
Date: Thu, 14 Mar 2002 16:05:52 -0500

Glenn,

I did not see any sign of the communication officially yet,
but it should be sent to [email-masked] and/or Scott
Bradner for the official channel.

It's good to see it unofficially (IETF-style) so I can address
two points quickly:

> Note, however,

The i-d appears to be quite complete.  I think it would be
reasonable to do the IETF review process for it now, including
posting for a review on the ietf-types list and in parallel starting a 
4-week IETF Last Call, which is needed for standards track
documents when they are not working group documents.   A MIME type
would normally be a Proposed Standard rather than BCP.  

> referencing of a non-=8CStandards Track=B9 IETF RFC in an ITU-T Recommendation.

The Chairs and ADs have recently changed the plan for the I-D so 
it will be standards track, a BCP, as can be seen on the charter page.
Facilitating the collaboration with ITU-T was one of the reasons.

Allison 
Area Director for SIPPING

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

---

From: John W Noerenberg II <[email-masked]>
Date: Thu, 14 Mar 2002 16:37:48 -0800

Greg Rose has identified a security problem when HTTP-Digest is 
combined with the mechanism proposed in 
draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00.  He's 
outlined this for the 3GPP TSG SA WG3, one of the TSG security area 
working groups.

Essentially the problem is a consequence of using a RES that is 
shorter than the key from which it is derived, typically as small as 
32 bits.  RES's length results from the goal of maintaining backward 
compatibility with existing USIMs.  RES is a choke point that can be 
used to break the authentication.  Instead of using RES, IK has much 
greater entropy, and makes the attack prohibitively difficult.  A 
description of the attack against RES is given below.

The authentication process can be summarized as follows:

1. UE attempts to register.
2. The attempt is rejected because the UE is unauthenticated.  The 
rejection message includes AKA-related information and an HTTP-Digest 
nonce.
3. UE/USIM checks the AKA information and computes RES.
4. RES is now used as the password shared by the UE and the CSCF.
5. UE computes HTTP-Digest response based on RES, and attempts to register.
6. Registration succeeds.

Subsequently

7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest 
method calculates authentication information based on RES. 
(Actually, A1 is used, but it is derived from RES).

Choke Point Attack

An attacker monitoring the traffic would break the scheme as follows:

The attacker has all the messages from steps 2 and 5 above.  All of 
the information used in the calculation of the response in step 5, 
except for the value of RES is present in these messages.  Assuming 
RES is 32 bits, the attacker tries the 2**32 possible values, 
comparing them to the captured response generated for step 5.  With 
very high probability, he will succeed with exactly one candidate 
value for RES, in the time needed to calculate 2**31 MD5 hashes. 
This takes ~5 minutes on a typical laptop.

Once the value of RES is known, the attacker can now forge SIP 
messages or alter them in transit, recalculating the Digest after 
altering the message.

By replacing the use of RES with a higher entropy quantity, this 
attack can be prevented.  As noted above, Greg recommends using IK as 
a replacement for RES.

best,
-- 

john noerenberg
[email-masked]
   --------------------------------------------------------------------------
   The truth knocks on the door and you say, "Go away, I'm looking
   for the truth,"  and so it goes away.  Puzzling.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Mar 2002 08:16:41 +0200

John, Greg,

Thanks for an interesting describing this interesting attack! I believe
while making draft-niemi the authors have been assuming that we do not
use the GSM compatibility mode (which I believe is the reason why the RES
could be only 32 bits). That is, when full AKA is used this isn't a problem.

So, we could either

(1) Require the full use of AKA
(2) Switch to using IK and not RES as input in the Digest process

Greg, is the IK free of similar limitations when GSM compatibility
is used?

Jari

---

From: "Niemi Aki (NET/Espoo)" <[email-masked]>
Date: Fri, 15 Mar 2002 11:43:27 +0200

Hi All,

> (2) Switch to using IK and not RES as input in the Digest process

As far as I understand the authentication/integrity protection schemes 
of 3GPP IMS, the authentication is between the UE and the S-CSCF, and 
the integrity protection is between the UE and the P-CSCF. Therefore I 
can't see a problem in using RES as input for Digest AKA in the 
authentication, and IK as input for the Digest in integrity protection.

The RES would then constitute a one-time password type key, whereas IK 
is a more long term key for integrity protection.

I don't see a need to group the two mechanisms together.

Cheers,
Aki

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Mar 2002 10:52:17 +0200

Greg Rose wrote:
> 
> At 08:16 AM 3/15/2002 +0200, Jari Arkko wrote:
> Regrettably, this is not correct. RES could be as little as 32 bits *even
> in full AKA*.

Yes, but don't we have the choice of *requiring* that
in order to use AKA in Digest, you have to provide
128 bits? Is there a particular reason why less than
128 bits would have to be produced. In particular, as
the draft is currently written, we do not transport the
RES over the air, so its length is not an efficiency issue.

[By the way Vesa: it does not help extending a short user
password, because in the end there's not enough original
bits.]
 
Jari

---

From: Greg Rose <[email-masked]>
Date: Fri, 15 Mar 2002 18:38:30 +1100

>(2) Switch to using IK and not RES as input in the Digest process

IK is the obvious (to me) candidate.

>Greg, is the IK free of similar limitations when GSM compatibility

If I understand your question correctly -- yes. IK is always 128 bits 
coming out of the USIM, even if it is subsequently "dumbed down" for GSM 
compatibility (which should never happen in anything capable of packet data 
and IMS). When a *GSM SIM* is used, you will only get out a 64-bit K_c, but 
even that is a lot better than a 32-bit RES.

regards,
Greg.

Greg Rose                                       INTERNET: [email-masked]
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C