Subject: [TLS] Comments on draft-santesson-tls-ume-04/draft-santesson-tls-supp-00

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Apr 2006 22:12:04 -0700

These drafts seem basically sound. Minor comments below.

-tls-supp:
You should state that only one SupplementalData field may 
be used per handshake.

Somewhere you should note that this data SHOULD NOT be 
processed by TLS but just passed up to the application.

-tls-ume:
Why is this draft going to Proposed? ISTM that it's pretty 
hard to interpret without a bunch of MS-proprietary 
information. There's no need for it to go to Proposed, since
both extensions and Supp-data allow code points to be 
issued via informational.

S 3: 
Should the UMDL type be 2^24-1 rather than 2^16-1.

S 4:
You can do the UPN hint extension exchange and then NOT
send supp_data? That seems wrong.

S 5:
I don't really understand this bit about "if the server 
belongs to a domain to which the client intends to
authenticate". What does that mean in practice? How
would you know?

-Ekr

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Apr 2006 17:10:36 -0400

>You should state that only one SupplementalData field may

I agree.  This was pointed out by the Gen-ART reviewer too.

>processed by TLS but just passed up to the application.

I agree.  This was also raised by Cullen.

>issued via informational.

This is being discussed.  The reason that I would like to see it as 
standards-track is that the structure supports more than just 
Microsoft names.  The Microsoft names are simply the first ones that 
are supported.

>send supp_data? That seems wrong.

I agree, if the negotiation is successful, then the supplemental data 
should be sent.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 17 Apr 2006 16:09:40 -0700

> Microsoft names.  The Microsoft names are simply the first ones that

I'm sympathetic to this, but I'm also uncomfortable with having a PS
that's not really implementable in part. That said, this is probably
part of a higher level IETF/IESG policy discussion rather than
a TLS one.

> I agree, if the negotiation is successful, then the supplemental data

This should be a MUST, IMO. I.e., the peer can and probably
should detect it and throw an error. If it's a SHOULD,
then the document needs to explain how.

Best,
-Ekr

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 18 Apr 2006 18:56:59 +0100

In, line;

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: den 17 april 2006 13:11
> To: Eric Rescorla
> Cc: [email-masked]; [email-masked]
> Subject: [TLS] Re: Comments on
draft-santesson-tls-ume-04/draft-santesson-
> tls-supp-00

[Stefan] I've put this on my change log. To be precise in words, should
the text state that "The client and server MUST NOT send more than one
supplementalData handshake message each."?

> I agree.  This was also raised by Cullen.

[Stefan] On my change log

> Microsoft names.  The Microsoft names are simply the first ones that
[Stefan] A agree to the proposed path of the reason stated by Russ. I'm
willing to tune down the mentioning of Microsoft as it isn't necessary
for the syntax definitions of this document.

> I agree, if the negotiation is successful, then the supplemental data
[Stefan] I don't see much value in this direction as the server MUST be
prepared for the case where the client chooses not to send any hint. It
may have come to the conclusion that this is not the right server to
send the hint it intended for some reason. Another reason may be that
the user has declined sending his user name to this server in a user
dialog box.

I view sending of hints as completely voluntary at the discretion of the
client. Even after extension exchange.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Apr 2006 11:05:29 -0700

> supplementalData handshake message each."?

Yes, I think that's right.

> for the syntax definitions of this document.

That doesn't really resolve my issue, because it still results in
incompletely specified semantics.

> client. Even after extension exchange.

Then that that needs to be stated clearly in the specification.

-Ekr

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 18 Apr 2006 19:07:11 +0100

In line;

Stefan Santesson

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: den 17 april 2006 15:10
> To: Russ Housley
> Subject: [TLS] Re: Comments
ondraft-santesson-tls-ume-04/draft-santesson-
> part of a higher level IETF/IESG policy discussion rather than

[Stefan] What part is not implementable? If you are referring to the
fact that normalization of the user name part of the UPN hint is not
fully defined, that does not make this specification un-implementable.

Anny client/server based system that currently is using TLS for user
authentication must have an understanding of how names they use to
access accounts are formed. This standard makes it possible for them to
send that username in that form. If we enforce specific character
normalization on the user name then they may not be able to use this
standard anymore as it may conflict with how they encode usernames.

Many standards define fields that higher level protocols and apps can
use in multiple ways. That does not make those standards
un-implementable. It's just a limitation of scope.

> then the document needs to explain how.
[Stefan] No, this is not an error. Se other response.

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 18 Apr 2006 19:11:04 +0100

Eric,

On last issue, I will add that explanation to my change log.

Stefan Santesson

> From: Eric Rescorla [mailto:[email-masked]]
> Sent: den 18 april 2006 10:05
> To: Stefan Santesson
> Cc: Russ Housley; [email-masked]; [email-masked]
> Subject: Re: [TLS] Re: Comments on draft-santesson-tls-ume-04/draft-
> santesson-tls-supp-00
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Apr 2006 11:24:48 -0700

> un-implementable. It's just a limitation of scope.

I'm not talking about the normalization issue, primarily. I'm talking
about the fact that the UPN part of the specification is incompletely
specified. See, for instance my comments about how the client knows
the domain should get the UPN data. For that matter, the procedure
for determining whether the UPN maps to any given certificate is
unspecified. The first issue in particular makes it very unlikely
that one could interoperably implement this feature in a reasonable
kind of way.

-Ekr

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 18 Apr 2006 19:40:53 +0100

Eric,

It seems that we have a misunderstanding (or disagreement?) on the scope
of this document.

It is not intended to specify the UPN of Active Directory or how user
account names in Active Directory are obtained.

It neither intends to specify how any server environment should map this
hint to any account.

The scope of this document is to specify a _generic_ protocol syntax for
exchanging hints. In addition to this the document specifies one
specific hint type that may be used to send over a domain hint or a
user@domain hint.
Other hint types may be defined in future standards.

Any references to use in a Microsoft environment should only be viewed
as implementation examples.

I've said before that I'm willing to change the name (not using "UPN" at
all as variable name), keeping the same syntax, if that helps clarifying
this.

As a natural follow up I would certainly consider writing an
informational document specifying the exact encoding and matching rules
for a Microsoft UPN. But that would be a separate effort and obviously
Informational.

Stefan Santesson

> Sent: den 18 april 2006 11:25
> To: Stefan Santesson
> Subject: Re: [TLS] Re: Comments ondraft-santesson-tls-ume-04/draft-
> santesson-tls-supp-00
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Apr 2006 11:47:12 -0700

> all as variable name), keeping the same syntax, if that helps clarifying

The problem is that without specifying the semantics, this document
just creates an opaque hole that isn't really implementable in an
interoperable way, for the reasons I indicated. 

-Ekr

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 18 Apr 2006 19:53:25 +0100

Eric,

Just adding that I already have agreed to make changes to the
introduction to clarify the scope.

Stefan Santesson

---

From: Russ Housley <[email-masked]>
Date: Tue, 18 Apr 2006 15:49:58 -0400

>then the document needs to explain how.

I have no problem with the requirement that there be a fatal 
alert.  Do we need to specify a new AlertDescription value for this situation?

Russ

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 19 Apr 2006 00:32:51 +0100

This is a text outline for what I propose to add at the end of the
message flow section.

"The server MUST expect and gracefully handle the case where the client
chooses to not send any supplementalData handshake message even after
successful negotiation of extensions. The client MAY at its own
discretion decide that the user mapping hint it initially intended to
send no longer is relevant for this session. One such reason could be
that the server certificate fails to meet certain requirements."

It may need some improvements but I don't see any need for an error
alert.
The server will simply proceed as if no hint negotiation was initiated.

Stefan Santesson

> Sent: den 18 april 2006 12:50
> To: Eric Rescorla
> Cc: [email-masked]; [email-masked]; Stefan Santesson
> Subject: Re: Comments on
draft-santesson-tls-ume-04/draft-santesson-tls-
> supp-00