Subject: [KEYPROV] Do we need "One-pass" support in DSKPP?

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 19 Nov 2007 01:55:10 -0800

In one of email thread discussions with Hannes's comments, we exchanged
discussion about whether we should keep One Pass in this spec. I also
post this here for broad discussion and feedbacks.

There are a few concerns puzzling me about "One-pass" case.

1. Which use case listed in the spec does it try to address?

2. It looks to me that it increased complexity for interop and
documentation.

When we mention about binding with HTTP, for example, one pass is much
useful with HTTP. Two-pass could be used. As a client server protocol, a
Client always sends something to request; why not always send the hello
message.

Thomas's email today again asks for clarification what a client should
send with HTTP. I would feel that two-pass can be simply used instead.

3. If we don't use HTTP with One Pass, then what is it?
   
A different transport would obviously be necessary to make the "one
pass" really a "one pass".

I would prefer to simplify the spec by not supporting one-pass case. Or
we need to specify something for recommendation, and current spec lacks
it. Or I may haved missed some sections about its powerness.

Comments? Thanks,

- Ming

_______________________________________________
KEYPROV mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/keyprov

---

From: "Salah Machani" <[email-masked]>
Date: Mon, 19 Nov 2007 09:15:18 -0500

Ming, 

The use case for 'one pass' is described in section 3.8 - SMS based
transport use case.  I agree with the assessment that 'one pass' is
redundant when using HTTP transport.  We should clarify in the spec that
the 'one pass' variant is applicable when SMS is used as transport and
revisit the definition of 'ServerFinished' message in 'one pass' to
ensure that the formatting and size is suitable for SMS transport.  

Regards,

Salah
   
-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Monday, November 19, 2007 4:55 AM
To: [email-masked]
Subject: [KEYPROV] Do we need "One-pass" support in DSKPP?

   

Comments? Thanks,

- Ming

Notice to Recipient:  The information in this message is meant only for the intended recipient of the transmission and may contain confidential or privileged information. 
Any copying, retransmittal, taking of action in reliance on, or other use of the information in this communication by persons other than the addressees is prohibited.  
If you received this email in error, please immediately notify us and please delete or destroy all copies of this message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors.  Thank you.

---

From: "Pei, Mingliang" <[email-masked]>
Date: Mon, 19 Nov 2007 11:35:21 -0800

Salah,

Thanks. Use case 3.8 was from earlier OATH DSKPP draft. In this case, a
user triggers a requesst from a wired client (e.g. desktop) to do
authentication, and asks a response to be sent via SMS. We had the
"SharedSecretDeliveryMethod" in a request to indicate whether a response
should be sent back in SMS or HTTP for this purpose. Considering the
complexity that additional information may need to be submitted in a
request with SMS preference, we decided to remove this negotiation. So I
thought that SMS support was going to be out of scope for the complexity
for now.

To clarify and complete the "one-pass" case in the spec associated with
SMS, shall we specify the additional information in ClientHello for the
wired side? I incline to think that the typical flow in this case is a
combo of two-pass HTTP and one-pass SMS response.

- Ming

> From: Salah Machani [mailto:[email-masked]] 
> Sent: Monday, November 19, 2007 6:15 AM
> To: Pei, Mingliang; [email-masked]
> Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP?
> 
> Ming, 
> 
> The use case for 'one pass' is described in section 3.8 - SMS 
> based transport use case.  I agree with the assessment that 
> 'one pass' is redundant when using HTTP transport.  We should 
> clarify in the spec that the 'one pass' variant is applicable 
> when SMS is used as transport and revisit the definition of 
> 'ServerFinished' message in 'one pass' to ensure that the 
> formatting and size is suitable for SMS transport.  
> 
> Regards,
> 
> 
> Salah
>    
> Notice to Recipient:  The information in this message is 
> meant only for the intended recipient of the transmission and 
> may contain confidential or privileged information. 
> 
> Any copying, retransmittal, taking of action in reliance on, 
> or other use of the information in this communication by 
> persons other than the addressees is prohibited.  
> 
> If you received this email in error, please immediately 
> notify us and please delete or destroy all copies of this message.
> 
> This message may have been altered without your or our 
> knowledge and the sender does not accept any liability for 
> any errors.  Thank you.
> 
> 
>

---

From: "Salah Machani" <[email-masked]>
Date: Tue, 20 Nov 2007 06:00:01 -0500

Ming,

If there was a consensus to drop SMS support then we should remove the
use case in 3.8.  Otherwise, we need to have considerations in
specification for dskpp run over SMS.  Note that the SMS push with
ServerFinished data does not necessary need to be triggered by a
ClientHello from a desktop computer.  This could be sent to the phone as
a result of the user registering with the provisioning service through
the web or other channels. It will be a true 'one pass' as specified in
the draft.

Regards,

Salah

-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Monday, November 19, 2007 2:35 PM
To: Salah Machani; [email-masked]
Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP?

Salah,

- Ming

---

From: "Doherty, Andrea" <[email-masked]>
Date: Tue, 20 Nov 2007 13:40:05 -0500

Salah is correct that we should remove use case 3.8 from the DSKPP doc.
As was agreed at the meeting in Chicago, if someone wants to pick up the
use case and define how DSKPP can be extended/implemented to support it,
then they can create a separate document.
Andrea

-----Original Message-----
From: Salah Machani [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2007 6:00 AM
To: Pei, Mingliang; [email-masked]
Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP?

Ming,

Regards,

Salah

-----Original Message-----
From: Pei, Mingliang [mailto:[email-masked]] 
Sent: Monday, November 19, 2007 2:35 PM
To: Salah Machani; [email-masked]
Subject: RE: [KEYPROV] Do we need "One-pass" support in DSKPP?

Salah,

- Ming

> it. Or I may haved missed some sections about its powerness.

Notice to Recipient:  The information in this message is meant only for
the intended recipient of the transmission and may contain confidential
or privileged information. 

Any copying, retransmittal, taking of action in reliance on, or other
use of the information in this communication by persons other than the
addressees is prohibited.  

If you received this email in error, please immediately notify us and
please delete or destroy all copies of this message.

This message may have been altered without your or our knowledge and the
sender does not accept any liability for any errors.  Thank you.