Subject: [kitten] WG Adoptions

From: Shawn M Emery <[email-masked]>
Date: Fri, 12 Nov 2010 06:49:01 -0700

This starts a WG consensus call for the adoption of two new work items 
to the charter:

SASL-SAML-EC
http://tools.ietf.org/html/draft-cantor-ietf-kitten-saml-ec

SASL-OAuth:
http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth

1. Adopt with no pre-conditions
2. Adopt with the assumption that there be a CB option specified for 
each mechanism
3. Adopt after the security considerations/assumptions of each mechanism 
is fully understood
4. Both 2 and 3.

Please provide feed-back to me or the list no later than 11/19/10.

Shawn.
kitten co-chair
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Nov 2010 11:47:31 -0600

On Fri, Nov 12, 2010 at 06:49:01AM -0700, Shawn M Emery wrote:
> 
> This starts a WG consensus call for the adoption of two new work
> items to the charter:
> 
> SASL-SAML-EC
> 3. Adopt after the security considerations/assumptions of each
> mechanism is fully understood
> 4. Both 2 and 3.
> 

I believe these would require a re-charter.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Nov 2010 17:05:05 -0600

> Please provide feed-back to me or the list no later than 11/19/10.

IMO, (1) is out.

(3) is too strong a requirement.  If KITTEN is to work on mechanisms it
might be a good idea for the WG charter to state the minimal threat
model that those mechanisms must meet, and the minimum feature
requirements for them as well.  That is, it's OK to demand a threat
model a priori, but a security considerations treatment seems a bit
silly to require a priori.

These are the requirements I would demand of any mechanism in order to
be adopted by KITTEN:

 - the mechanism MUST state what threat model it will meet
    - this must be at least a minimum threat model, as yet to be
      determined, but with at least these elements:
       - resistance to passive attacks (no passwords sent in the clear)
	 (unless stacking over a mechanism that provides the necessary
	 protection is expected)
       - resistance to MITM attacks (so that channel binding can be
	 meaningful)

 - the mechanism MUST provide the following GSS-API mechanism features:
    - mutual authentication (in the sense that the initiator and
      acceptor are named, and also in the sense of confirmation)
    - channel binding
    - the GSS PRF 
    - GSS_C_NT_HOSTBASED_SERVICE naming MUST be supported for acceptors[*]

 - authentication and channel binding MUST provide a reasonable level of
   cryptographic protection (say, not less than SCRAM)

For example, a mechanism that does not aim to defeat eavesdroppers
(e.g., passwords are sent in the clear, not even tunneled over TLS) is
not desirable for Internet protocols.  A mechanism that purports to meet
a threat model that is appropriate for Internet protocols might
eventually fail to deliver, in which case it likely won't make it on the
standards-track, but at least it can be designed in and reviewed by the
WG.

[*] Note that the host-based naming requirement can be fairly weak in
    that the acceptor principal can be "imaginary", so to speak, as in
    SCRAM (where the acceptor isn't named anywhere outside the API, but
    nonetheless can play a useful role).

Nico

---

From: William Mills <[email-masked]>
Date: Fri, 12 Nov 2010 15:39:17 -0800

I think requiring the initiator to be "named" as well as the acceptor is going to be too high a bar.  There are a lot of use cases that won't be able to meet that without some trivializing of the initiator naming.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Nicolas Williams
> Sent: Friday, November 12, 2010 3:05 PM
> To: Shawn M Emery
> Cc: [email-masked]
> Subject: Re: [kitten] WG Adoptions
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Nov 2010 18:20:19 -0600

On Fri, Nov 12, 2010 at 03:39:17PM -0800, William Mills wrote:
> I think requiring the initiator to be "named" as well as the acceptor
> is going to be too high a bar.  There are a lot of use cases that
> won't be able to meet that without some trivializing of the initiator
> naming.

I should clarify that GSS_C_NT_ANONYMOUS initiators should be OK (though
if that's all that's provided then the mechanism will not be terribly
useful).  Also, the name of the initiator needn't be anything
particularly meaningful, as long as, in the non-anonymous case, it's
something that can be compared or "exported".

The primary naming requirement is that host-based service acceptors must
be supported.  Initiator names can be of any type, including types for
which there is no generic syntax.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 12 Nov 2010 18:31:46 -0600

> which there is no generic syntax.

The reason, incidentally, for requiring support for host-based service
acceptors is that most Internet application protocols that use the
GSS-API use it with host-based service acceptors.  SSHv2, NFSv4, DNS
(GSS-TSIG), LDAP, IMAP, ... -- all require host-based service naming for
acceptors.

Note that treating all service names as equivalent would be fine,
yielding host-based naming.  (i.e., [email-masked] could be treated as
just foo.example).

The form of the initiator principal name is much less important.  In the
traditional API what matters is that a) you be able to call
gss_import_name() to import an initiator principal from a string, b) be
able to gss_compare_name() names of the given name type, c) be able to
gss_export_name() an MN of the given name type, d) be able to
gss_import_name() the exported name tokens resulting from
gss_export_name().

If all of the preceding  parargraph is gobbledeegook to you, don't
worry, we'll make sure to explain it :)  (just not right this minute).

Given naming extensions an anonymous initiator whose name nonetheless
includes naming attributes such as SAML assertions and what not would be
a lot more useful than just anonymous initiator naming.

Lacking meaninful non-anonymous initiator naming may limit the
usefulness of a mechanism in the case of some applications _as
implemented_.  But that's not as big a problem as the lack of host-based
service naming because Internet application protocols require the
latter, but don't require any particular initiator name forms.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Sat, 13 Nov 2010 05:25:52 +0100 (MET)

Nicolas Williams wrote:
> (1) - mutual authentication (in the sense that the initiator and
> (2) - channel binding
> (3) - the GSS PRF 
> (4) - GSS_C_NT_HOSTBASED_SERVICE naming MUST be supported for acceptors[*]

I have some serious problems with these requirements in this order
of seriousness:  (4), (3), (2), (1)

For me (4) is an absolute NO GO.  From the ~15 gssapi mechanisms that
I know only 2 (Kerberos and DCE) support that nametype.  Basically
none of the SPKM-like (see rfc2025) gssapi mechanisms supports
hostbased service names.  The way hostbased service names are
defined in rfc-2743 (and had been implemented in Kerbeors 5 like
that for at least a decade) are a REAL security problem.

Doing GSS-API and mutual authentication without hostbased service
names is pretty normal, and it is more secure.

Look at the beautiful EV-certificates.  The weakest attribute in
an EV cert is the DNS name.  The attributes that are verified
with much more scrutiny are all the others.  So from the security
standpoint, matching only the DNS name and ignore all the other
attributes is non-sensical.

Similarly, GSS PRF is an fairly new optional feature, and it is
difficult to find implementatiosn that support it (I haven't
met any).

The GSS-API channel bindings facility is also a underused feature,
and GSS-API is *MUCH* more usable without it.  Lots of gssapi
mechanisms do not implement it and even fewer apps use it.
The only time where I have seen channel bindings to be useful,
is for a clear abuse of GSS-API, where the Kerberos authentication
exchanges is misappropriated into an OTP-scheme.

If the gssapi mechanism provides the message protection for the
entire communication, which is what GSS-API was originally
designed for, then there is absolutely no need for channel bindings
(and no need for GSS-PRF).

The mutual authentication thing is a little funny.  Kerberos actually
has a design flaw, in that one always has to provide a target name,
even when not requesting mutual authentication.  This could have
been implemented in a fashion that does not require a target name
for gss_init_sec_context(), but would have incurred another round-trip.

I haven't looked at how exactly the Microsoft implementation of
user2user authentication works, but it should be possible to
make that work without a target_name parameter to gss_init_sec_context().

Another possibility, for gss-api mechanisms that offer only unidirectional
authentication of the client to the server, is that these mechanisms
simply ignore the value of the target_name parameter.  The difficulty
here concerning hostbased service names: the target_name parameter
is an opaque type "gss_name_t" that must first be created through
calling gss_import_name() and it is much less obvious how to
"simply ignore the target name", because that means that trying
to import a hostbased service names is very likely to fail with an error.

Bottom line, an application that blindly expects "hostbased service names"
to be available for use as target names for gss_init_sec_context()
is NON-portable(!) gssapi-aware application.

-Martin

---

From: Eliot Lear <[email-masked]>
Date: Sat, 13 Nov 2010 09:15:56 +0100

Before we get into a discussion of solutions, can we please have a
serious conversation about what channel binding means in the context of
federated identity and multiparty exchanges, where we consider it from
the angle of each party?  That is, the IdP, the SP/RP, the principal,
and the application(s)?

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 13 Nov 2010 02:50:57 -0600

> the angle of each party?  That is, the IdP, the SP/RP, the principal,

Channel binding here means exactly what RFC5056 says.  It's the client
and the rp that authenticate mutually and bind some other channel
(typically also with the same two entities as end-points, else proxies
for them as end-points) into that authentication.

Whether the IdP, KDCs, or whatever other third parties, are involved in
the process of binding the channel is not important -- except as a
detail of the mechanism, of course.  There is no requirement that third
parties be involved in channel binding.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 13 Nov 2010 02:59:34 -0600

> that for at least a decade) are a REAL security problem.

Martin, you have said this before, and sorry, but _Internet_ application
protocols that exist today (I listed some) _require_ hostbased service
names.  This doesn't mean that you cannot have Standards-Track
mechanisms that don't support hostbased service names.  But it could
mean that KITTEN WG may not host such work (emphasis on the "could" --
we're deciding on that, aren't we?).

I believe it is perfectly appropriate for an IETF WG considering work on
Standards-Track GSS-API mechanisms to require features that are required
by Internet application protocols.

Note, incidentally, that I didn't express a desire for per-message
tokens even though most existing Internet applications that use the
GSS-API depend on them.  There's a reason for this: I asked for PRF
support, which implies keying, which implies that per-message tokens are
definitely feasible.

Let me then re-phrase my request for PRF support as: a request for
keying.  Given keying one can trivially add per-message tokens and PRF
support (say, by borrowing the ones from the Kerberos V5 mechanism).

> names is pretty normal, and it is more secure.

Of course it is (except for the "more secure" part).  I didn't say that
it's not.

> difficult to find implementatiosn that support it (I haven't

That's true, and yet _I_ want that as a requirement.  I have my reasons,
namely: it makes the GSS-API much easier to use in contexts where you
can't use per-message tokens.  In any case, see above.

> exchanges is misappropriated into an OTP-scheme.

This is no longer true, or it's about to no longer be true.  See
SASL/GS2, SCRAM, ABFAB WG's work.

> (and no need for GSS-PRF).

It'd be nice if the world was so simple that this were true.  But it's
not.  The fact is that the SASL community doesn't want to bother with
SASL security layers because most Internet SASL apps already have an
option to use TLS -- to support two security layer protocols is a pain,
yet TLS doesn't have the user authentication mechanisms that SASL and
the GSS-API have, so the obvious solution (enshrined in SASL/GS2) is to
do channel binding.

> for gss_init_sec_context(), but would have incurred another round-trip.

I agree regarding Kerberos, but that says nothing as to whether
requiring mutual authentication is a good or bad idea.

> make that work without a target_name parameter to gss_init_sec_context().

Sure.  But again: what's the point?

> to import a hostbased service names is very likely to fail with an error.

One could provide GSS_C_NO_NAME.  But if you do this then channel
binding loses meaning.

> is NON-portable(!) gssapi-aware application.

Portability is not the issue.  Interoperability is.  All Internet GSS
applications that I can think of require support for hostbased service
names as acceptors (which is not to say that they require that acceptors
always be hostbased services).

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Sat, 13 Nov 2010 12:57:58 +0100

Nico,

> parties be involved in channel binding.

Thank you for that clarification.  That was what I was trying to understand.

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 13 Nov 2010 08:58:27 -0600

> Thank you for that clarification.  That was what I was trying to

Also, note that there is no requirement that third parties not be
involved.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 14 Nov 2010 13:20:54 -0500

>>>>> "Shawn" == Shawn M Emery <[email-masked]> writes:

    Shawn> This starts a WG consensus call for the adoption of two new
    Shawn> work items to the charter:

    Shawn> SASL-SAML-EC
    Shawn> http://tools.ietf.org/html/draft-cantor-ietf-kitten-saml-ec

    Shawn> SASL-OAuth:
    Shawn> http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth

2. Adopt with the assumption
    Shawn> that there be a CB option specified for each mechanism

I support this option.
My rationale is that we have explored both mechanisms enough that we
believe we can do CB.

I don't think it would be desirable to come up with a solution that is
significantly less secure than what we've convinced ourselves we can
already accomplish.
IF we were to get to a point where we found we were unable to do a CB
mechanism for these it would indicate that a lot of our reasoning in
evaluating these mechanisms was flawed and we would need to rethink a
lot more than just CB.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 14 Nov 2010 13:23:11 -0500

Nico, do you think making the PRF a strict requirement is desirable?
For example it seems like SAML EC could probably do CB but I'm not sure
about PRF.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 14 Nov 2010 13:30:03 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Nicolas Williams wrote:
    Martin> For me (4) is an absolute NO GO.  From the ~15 gssapi
    Martin> mechanisms that I know only 2 (Kerberos and DCE) support
    Martin> that nametype.  Basically none of the SPKM-like (see
    Martin> rfc2025) gssapi mechanisms supports hostbased service names.
    Martin> The way hostbased service names are defined in rfc-2743 (and
    Martin> had been implemented in Kerbeors 5 like that for at least a
    Martin> decade) are a REAL security problem.

Martin, note that Nico is only talking about what the IETF should work
on here in kitten.  He correctly argues that without hostbased services
names, the mechanism will be useless for IMAP, SSH, NFS,XMPP, LDAP and
HTTP.

In short, he's arguing that the IETF should only work on mechanisms that
will be useful for IETF application protocols.

I support that argument.

If you want to do work or encourage others to do work for
backwards-compatible support for other name forms in these applications,
I encourage you to do so.  If you succeed in that work, I think it would
be fine to relax this restriction.  I also think it's fine to work on
GSS-API mechanisms that do not support hostbased service names outside
of the IETF.  I just think it's reasonable and desirable for the IETF to
focus on mechanisms that work with its protocols.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 14 Nov 2010 13:35:52 -0500

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Before we get into a discussion of solutions, can we please
    Eliot> have a serious conversation about what channel binding means
    Eliot> in the context of federated identity and multiparty
    Eliot> exchanges, where we consider it from the angle of each party?
    Eliot> That is, the IdP, the SP/RP, the principal, and the
    Eliot> application(s)?

channel binding: the software acting on behalf of the principal and the
software acting on behalf of the SP MUST verify channel binding data
consistency.
The IDP and other parties may assist as desired; it is best if minimal
to no assistance is required.

That is, the user's software passes in channel binding data in
accordance with SASL or GSS. It's better defined for GSS, so I'll use
that context, although we do have code for the SASL case as well.  In
that case, the initiator passes in channel binding data to
gss_init_sec_context.

If the acceptor (SP/RP) passes in non-null channel binding data to
gss_accept_sec_context, the authentication MUST fail if these two
strings are not identical.

There is a lot of discussion of what data you should pass in.  That's
the same for federated and non-federated applications.

Note that I'm going to be proposing to expand these semantics slightly
in a couple of days in order to better support applications with HTTP as
a substrate.  That expansion will also be independent of federated vs
non-federated.

It's my belief that SAML EC and oauth can clearly meet this definition.

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 14 Nov 2010 19:43:00 +0100

>     Shawn> http://tools.ietf.org/html/draft-mills-kitten-sasl-oauth
...
> My rationale is that we have explored both mechanisms enough that we

How would CB for OAuth work?

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 14 Nov 2010 13:36:11 -0600

> For example it seems like SAML EC could probably do CB but I'm not sure

As I clarified, I want some form of key exchange because many Internet
application protocols depend on per-message tokens, and to me supporting
the PRF means being able to support per-message tokens.  However, I
think I'd be happy to use stacking and channel binding to achieve that.

Therefore, I'm willing to drop that element.  But maybe we should add a
work item to get the minimal TLS w/ anon DH + stacking mechanism done.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 14 Nov 2010 13:42:10 -0600

On Fri, Nov 12, 2010 at 05:05:05PM -0600, Nicolas Williams wrote:
>    [...]

After some thought I am dropping my requirement for PRF (or per-message
token) support.  The reason is that we could easily take a CB-only
mechanism and stack it on a mechanism that provides anonymous-anonymous
key exchange.

Nico
--

---

From: Jeffrey Altman <[email-masked]>
Date: Sun, 14 Nov 2010 18:56:46 -0500

> For example it seems like SAML EC could probably do CB but I'm not sure

I would strongly prefer that there be both CB and PRF capabilities for
any new GSS mechanism.  Any mechanism that does not support PRF will not
be usable with the AFS rxgk security class.  There has been some
interest in using OAuth to authenticate AFS in the future.

Thank you.

Jeffrey Altman

---

From: Sam Hartman <[email-masked]>
Date: Sun, 14 Nov 2010 18:59:23 -0500

>>>>> "Simon" == Simon Josefsson <[email-masked]> writes:

    Simon> Sam Hartman <[email-masked]> writes:
    Shawn> SASL-SAML-EC
    Shawn> http://tools.ietf.org/html/draft-cantor-ietf-kitten-saml-ec
    Shawn> SASL-OAuth:
    Simon> ...
    >> My rationale is that we have explored both mechanisms enough that
    >> we believe we can do CB.

    Simon> How would CB for OAuth work?

oauth has two "signature" modes.  The first involves a "base string"
signed by an hmac. The second involves asymmetric signatures.  For the
first, include the channel binding data in the base string.  For the
second, it's not clear that it works well.  The hmac-based approach is
definitely preferred by the parts of the oauth community that use
signatures, Hannes says.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 14 Nov 2010 19:01:22 -0500

OK.  I strongly support your original list of requirements with the PRF
a strong SHOULD instead of a MUST.

I  have specifically considered Martin's comments.
I agree we should add a comment that mechanisms MUST NOT depend on
insecure DNS for hostbased service suport, but disagree that we can drop
hostbased service names as a strong requirement.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Nov 2010 10:53:43 +0100

> definitely preferred by the parts of the oauth community that use

Are you talking about OAuth 1.0 aka RFC 5849?  OAuth 1.0 also supports
the "PLAINTEXT" signature mode.  I don't see any way to get a CB with
the PLAINTEXT mode.  So in the general case it seems difficult.

Note that draft-mills-kitten-sasl-oauth refers to OAuth 2.0 and not to
OAuth 1.0.  OAuth 2.0 does not support signatures but instead uses HTTP
authentication.

/Simon

---

From: William Mills <[email-masked]>
Date: Mon, 15 Nov 2010 08:08:39 -0800

> Behalf Of Simon Josefsson
> Sent: Monday, November 15, 2010 1:54 AM
> To: Sam Hartman
> Cc: [email-masked]

Signatures are very probably going to be part of the final OAuth 2.0 spec.  The draft design should allow 1.0a type OAuth as well, but it's outside the scope of the draft.

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Nov 2010 17:23:06 +0100 (MET)

> will be useful for IETF application protocols.

GSS-API has always been about **REAL** authentication.

I'm not aware of any protocol involving TLS for encryption of the
communication channel to perform authentication of the server.

What there is for HTTPS is an extremely weak "server endpoint identification"
as described in rfc2818 which identifies only a _host_, not a service,
and most protocols employing TLS are sharing that "server endpoint
identification" instead of defining an approach to securely authenticate
a server.

When you're using Kerberos, then the situation is less worrysome as
with X.509 certificate based authentication schemes, because in theory
it _should_ be possible to perform a secure canonicalize from a
hostbased service name into a Kerberos principal name (either locally
our through your trusted KDC), and after canonicalizing the name
into a Kerberos principal name, there is no more difference in
authenticating peers between servers and users.

When you create interrealm trust with other Kerberos realms, it is
essential for secure authentication of servers that you retain
strict control over the canonicalization of a hostbased service name
into a Kerberos principal -- so that admins realm A can
not subvert server authentication of servers in realm B by creating
suitable host credentials in _their_own_realm_.

The situation with TLS and a list of >100 omnipotent CAs, on the other
hand, is completely foobar as far as authentication of servers is
concerned.  Unless you ditch **ALL** of those pre-trusted RootCAs
that come with most TLS implementations, and add only _one_single_
organizational CA (with ZERO cross-CA weirdness) as trusted, it is
impossible to securely authenticate peers with TLS.  And the way
it is currently done with TLS, there is no distinction between
services, everything is a extremely naive matching of hostnames
with certificate attributes, and the whole "faith on TLS"  is
vitally dependent on WHOIS-lookups, open SMTP-E-Mail and the
procedures of a large number of CAs that bear ZERO liability towards
99.9999% of the internet users.

I would find it very sad if whe would lower the original security
value of GSS-API authentication to the faith&obscurity level of
todays "TLS PKI".

In its original design GSS-API performs name-based authentication,
so there is a requirement for strict control of the entire namespace
by a single administrative entity.  For Kerberos, the REALM name is
part of the (canonical) Kerberos principal name, so GSS-API does
work cross-realm as well.

For GSS-API mechanism based on X.509, like SPKM (rfc2025), names
are often the subject DName of the certificates, which requires
that either there is only _one_single_CA_ involved, or a
centrally administrated CA hierarchy with strict Name Constraints
to ensure that there can not be collisions between identities,
i.e. that _no_ two CAs may create a valid credential for the
same entity, independent wether that entity represents a user
or a server.

Artificially matching only parts of a hostbased service name
to attributes of an X.509 certificiate is a clear, significant and
serious breah of the GSS-API architecture, and one of important
GSS-API features that breaks when doing this is the capability
to canonicalize the name of the communication peer.  That is a
significant impediment for distributed computing, where
many components may need to establish communication channels
arbitrarily in either direction, and therefor need to pre-populate
ACLs with peers name ahead of time, locally canonicalizing the
name that they use when they are initiator for storing it in
the ACL for situations where they are acceptor.

Personally, I think it would be a very bad idea to adopt the
lack-of-server-authentication known from TLS for GSS-API. 

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Nov 2010 18:48:23 +0100 (MET)

Nicolas Williams wrote:
> names.

That is NOT true.  They use hostbased service names, but they do _NOT_
require them.  If there are specs that contain such a requirement,
that that specs contain an obvious defect.  And you seem to confuse
a birth defect of the Kerberos GSS-API mechanism to not work at all
in absence of an a-priori target name with GSS-API architecture.

Technically, if both communication peers use X.509 certs, it it would
be possible that both peers authenticate each other first, and then
both look up the peers name and decide after context establishment
whether the authenticated peer is the one each want to talk to.
(that is what TLS actually does at the protocol level).

A portable GSS-API application does _not_ have a problem with services
that use hostbased service names, but it will work just fine with
services that do not have such a requirement.

There also was never such a requirement in any version of TLS
as it is clearly indicated in the last sentence of section 1 of
every TLS spec:

  http://tools.ietf.org/html/rfc5246#page-5

                          The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

Considering how badly most TLS clients are configured (trusting hundreds
of completely independent and liability-free omnipotent CAs), it would
be clearly a defect of application specs to preclude a secure authencation
of servers based on their public key (alternatively the full server cert)
whenever the certificate attribute that is used to authenticate a server
could have been created by more than one of the trusted CAs.

>
> This doesn't mean that you cannot have Standards-Track

It would be very sad if kitten would blindly adopt the oversimplification
called "server endpoint identification" from what is done in TLS today.

> by Internet application protocols.

The lack-of-depency to a particular nametype is a feature required
by GSS-API.

What you are asking for is not a new requirement, but the abolishment
of an existing key architecture principle of GSS-API.

> can't use per-message tokens.  In any case, see above.

But requiring message protection would make a lot more sense than PRF.
With the message protection primitive, you know that the gss-api
mechanism provides them with a sensible set of characteristics, and
the application on top of GSS-API does not need to be higly skilled
in cryptographic engineering to use the GSS-API message protection.

PRF, on the other hand, means that the application needs access to
low-level crypto functions and roll-its-own cryptographic engineering
to apply protection to data involving PRF output.  To me, that looks
EXTREMELY dangerous.

> support (say, by borrowing the ones from the Kerberos V5 mechanism).

Once you are applying GSS-API per-message protection to all application
data, there is absolutely no need for anything else, in particular
Channel-Bindings becomes a meaningless obscurity artifact.

As I previously wrote, the only time when GSS-API channel bindings
becomes useful, is when you are actually ABusing GSS-API, like
using only GSS-API authentication and doing message protection
with a completely different technology.  Only then it is necessary
to provide a cryptographic binding between the outsourced message
protection facilities with the original GSS-API authentication.
But in many cases it is the same as with outsourcing in the real world:
it is a bad idea that increases complexity and cost.

PRF_output from GSS and PRF_input to TLS could be used in a much more
efficient fashion for binding GSS-API authentication with a TLS channel
than what rfc4559 does today.  You could define a TLS extension that
can accomodate GSS-API initial context tokens and a modified
ClientKeyExchange handshake message that accomodates a third-leg
context token plus a protected message token (over the client and
server random) plus whatever this handshake message would normally
carry for the chosen TLS cipher suite.   That would work for
2-token and 3-token GSS-API authentications within the regular
TLS full handshake.  It would not provide confidentiality for the
GSS-API authentication exchange, and wouldn't work for GSS-API
mechanisms that can not provide message protection primitives.
The TLS session cache would have to carry the GSS-API authenticated
peer name along with potential other attributes that an application
might want to access on TLS session resume.  For vanilla GSS-API
and a single mechanism this should be easy and straightforward.

The more esoteric features an application would want to use from
GSS-API, the more difficult it becomes for maintaining the GSS-API
state for TLS session resume and for "authentication forwarding"
in case that TLS is terminated at an entry node of a distributed
backend system.

> SASL/GS2, SCRAM, ABFAB WG's work.

The point is that when you're doing GSS-API _correctly_, i.e. with
message protection, then GSS-API channel bindings is a real
obscurity artifact.  It provides _no_ security benefit, but may
create unnecessary problems for application level message routing
to achieve real end-to-end security.

I know that users of Kerberos don't see these kinds of problem,
since they can not work across arbitrary application proxies anyway,
they always need low-level direct connectivity to the KDC in order
to work.  IAKERB was one attempt to overcome this Kerberos shortcoming
for specific scenarios, but I don't know whether it has been implemented
yet.

> the GSS-API have, so the obvious solution (enshrined in SASL/GS2) is to

If you want vanilla GSS-API (abused as OTP-scheme) on top of vanilla TLS,
then I do not currently understand why you need PRF.  Passing tls-unique
channel bindings should be sufficient for that.

> One could provide GSS_C_NO_NAME.  But if you do this then channel

I currently fail to follow.  Where do you see a dependency between target
name and channel bindings.  tls-unique channel bindings should be secure
with only one communication peer being named/authenticated at GSS-API level.
tls-unique will even work securely with _fully_ anonymous GSS-API, but
that look somewhat like a silly waste of resources (unless you're
actually doing "blend-within-closed-group" instead of anonymous).

> always be hostbased services).

Which indicates that those application are all limited to
a very specific mechanism and simply won't work with the vast majority
of existing GSS-API mechanism.

But fixing them should be easy, just let the callers provide a
seperate parameter identifying the communication peer instead of
guessing it from the given network communication endpoint.  And
for GSS-API mechanisms that do not authenticate the server, get
rid of the assumption that a hostbased service name nametype_oid
is going to be recognized.

Assuming that users can authenticate pure ASCII hostname is already
dangerous.  But assuming users can authenticate IDNS hostnames from
the visual representation of unicode glyphs would be pretty naive,
and definitely insecure.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Nov 2010 13:05:18 -0600

> in absence of an a-priori target name with GSS-API architecture.

 - SSHv2 w/ GSS-API (indicative language) requires hostbased service
   names for acceptors.

 - NFSv4 w/ RPCSEC_GSS requires (normative language) hostbased service
   names for acceptors.

 - SASL/GS2 requires (indicative language) hostbased service names for
   acceptors.

 - SASL/GS1 requires (indicative language) hostbased service names for
   acceptors.

 - DNS GSS-TSIG requires (indicative language) hostbased service names
   for acceptors (though it doesn't actually say anything about acceptor
   name types, it does use host-based service name syntax).

 - Only SOCKSv5 uses language that is not just not normative, but not
   even indicative (section 3.1, "For example, ..."), and, like DNS
   GSS-TSIG, doesn't even mention name types.

 - I believe SMB requires hostbased acceptor names (but then, SMB is not
   an Internet application).

> (that is what TLS actually does at the protocol level).

Yes, that's true.

> services that do not have such a requirement.

Assuming that services have hostbased service names is a very nice
simplification for applications because hostnames (and implied service
names) are all users are likely to know.

Yes, apps could prompt the user as to whether to accept an acceptor's
name, and then record {hostname, exported GSS acceptor name} in an
ssh_known_hosts-like file.  Or they could look up the acceptor name in a
directory and see if it is allowed to respond for the hostname given by
the user.  Apps could even use the naming extensions to get at
attributes that can be used as inputs for the acceptor-name-to-hostname
authorization decision.  But I know of no implementations of any of the
apps listed above that do that.  I do agree with you that it'd be nice
if GSS apps did work as you suggest (and that it'd be nice to have a
version of the krb5 mech that doesn't require knowing the acceptor's
name a priori).

Again, note that I'm not saying that mechanisms can't be on the
Standards-Track unless they support host-based service names.  I'm
saying that I don't care to work on such mechanisms at KITTEN WG.

I'm prepared to be on the rough side of consensus on this, and I won't
be upset either -- it'll just be more work to do on SunSSH, for example.

But note that for some applications it will be very difficult to make
them work the way you say they should work.  NFS and SMB clients, for
example, are typically implemented in such a way that it's very hard to
go prompt a user as to whether a given acceptor name is acceptable for a
path a user was trying to access!

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 15 Nov 2010 14:38:51 -0500

> path a user was trying to access!

Nor would that be a win!  If you prompt the user, the answer will be "yeah, 
sure, I don't care; do whatever you want, just let me use my damn 
file/email/web page/whatever".

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Nov 2010 14:59:04 -0600

On Mon, Nov 15, 2010 at 02:38:51PM -0500, Jeffrey Hutzelman wrote:
> On Monday, November 15, 2010 01:05:18 PM -0600 Nicolas Williams wrote:
> Nor would that be a win!  If you prompt the user, the answer will be
> "yeah, sure, I don't care; do whatever you want, just let me use my
> damn file/email/web page/whatever".

I know.  I do see how this could be "useful" (as in: better than
outright failure) in some cases, mainly those where your services have
certificates with no dNSName SAN, no fqdn in the subjectName.

But for me the bottom-line is that whenever a user only has a hostname
to work with, the application should be able to use that to name its
peer (here: the acceptor).

It's OK if some deployments can't handle that, and it's OK if some
implementations of apps can prompt the user or lookup the acceptor name
in a directory.  And I'd even be OK with recommending that implementors
support that.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Nov 2010 22:11:09 +0100 (MET)

>    name types, it does use host-based service name syntax).

Where these are requirements, they are obviously _invalid_,
because they violate a fundamental design principle behind GSS-API.
The vast majority of folks active in the IETF dealing with GSS-API
is focused entirely on Kerberos on fairly blind to how GSS-API is
used outside of the IETF.  Implementations outside of the IETF
are fortunately much more aligned with the original GSS-API design.

Service based hostname have always been a purely optional part of the
GSS-API (which is why the nametype OID for it is from the MIT Kerberos
nametype tree).

The two early X.509 / PKI-based gssapi mechanisms (DEC DASS rfc1507
and SPKM rfc2025) work _completely_ without hostbased service names,
see e.g.:

  https://tools.ietf.org/html/rfc1507#section-1.2.5
  https://tools.ietf.org/html/rfc1507#page-24

  https://tools.ietf.org/html/rfc2025#section-3.1.1

and even DCE, which was derived from Kerberos, can work _without_
hostbased service names, relying on a secure directory service
to translate an abstract service name into a connection parameter
tuple (node-address, port, protocol, service principal).
DEC DASS similarly appears to rely on a secure directory (CDC)
for translating an abstract name into target-specific information.

>    an Internet application).

Which is funny, because NTLM is a unidirectional authentication scheme...

> names) are all users are likely to know.

Actually, this in twisting facts.  Hostbased service names imply
that people do not know abstract service names and auxiliary information
that would enable them authenticate a service (like ALL the carefully
checked attributes _other_ than the hostname in TLS EV server certs),
and that clients are too dumb to memorize server identies authenticated
by end users and admins, and therefore clients blindly supply the
target network endpoint address as the server/service name.

> ssh_known_hosts-like file.

As SSH has been doing with host keys all the time -- correct!

>
> Or they could look up the acceptor name in a directory and see
> if it is allowed to respond for the hostname given by the user.

Correct, another option would be a protected tranformation of an
abstract service name through a _trusted_ naming service.
(DNSSEC does not quite fit, because only the lookup is protected,
 but the DNS contents can not be considered trusted, and there
 is no standard for apps to distingish a handful of trusted
 DNSSEC keys from millions of untrusted DNSSEC keys).

>
> Apps could even use the naming extensions to get at
> apps listed above that do that.

DCE was one such solution.  It wasn't particularly successful, but
not because of that specific solution detail, but rather it was killed
early in its infancy with an agressive license fee scheme.
(Similar to how EC-crypto is suffocated by licensing).

>
> I do agree with you that it'd be nice if GSS apps did work as you
> suggest (and that it'd be nice to have a version of the krb5 mech
> that doesn't require knowing the acceptor's name a priori).

It would be a bad idea to preclude protocols around GSS-API to
ever work in a really secure fashion.  Seeing how completly
negligent Kerberos and TLS have been about server authentication
is quite sad and disturbing.

When Kerberos started out, it was added into _many_ protocols in
an abusive fashion that reduced an originally secure architecture into
a unidirectional OTP-scheme.  NO ONE cared about server authentication.
But in order to obtain a Kerberos ticket for the server, one needs
to tell the KDC who one wants to talk to, so out of technical necessity
the hostbased service names were adopted.  And many services simply
shared the host key.

In order to demonstrate just how insignificant authentication of the
server was, a lot of protocols neither used message protection facilities
nor an AP_REP token in response to an AP_REQ.

But if you never authenticate your peers, just mechanically copy the
network endpoint address, then you also never get true mutual authentication,
even when you later decide to request and process AP_REQ and use
message protection facilities, unless you also fix your scheme to
match the identity of the target with the intent of the end user
of the technology.

And while the hostbased service principals used by Kerberos can
theoretically provide some protection, provided that the canonicalization
from hostbased service names can be performed in a protected and
trusted fashion (which rules out 100% of DNS and 99.9999% of DNSSEC),
the approach taken by TLS for X.509 server certs is a lost cause
as soon as there are independent trust anchors involved,
i.e. the lack-of-security shipping with every Web Browser.

> be upset either -- it'll just be more work to do on SunSSH, for example.

I think that the IESG should wake up on this.

It is as if WGs would submit IPv4-protocol that will be absolutely
incompatible with IPv6.  Bad idea.

A security protocol that can only be used in an insecure fashion
is a bad idea.  I know that even the most secure protocols will be
configured and used in various insecure fashions.

But defining protocols so that they can not even be configured
in a secure fashion should be considered a serious problem.

GSS-API and hostbased service names are mutually exclusive
whenever local canonicalization of the service name into the
server principal name can not be performed in a trusted fashion,
independent of established security contexts.

A simplified unidirectional authentication scheme client->server
could decide to provide dummy transforms and ignore the target_name
parameter on gss_init_sec_context(), but that would result in
authentication failures due to invalid ACLs whenever such an
unidirectional authentication scheme is used in distributed
environments when that dummy name gets not only used as a target_name
but also for validating incoming requests established in the
reverse direction during the communication within a distributed
application infrastructure.

> path a user was trying to access!

When the user is authorized to cause the mounts himself, then he can
supply the name with the mount call.  Otherwise it is the admins task.

With smbmount on Linux, it is the default that you have to specify
even the _client_ name (plus "workgroup") on EVERY mount and obtain
an interactive prompt, whereas the server identity is completely
ignored because the server can not authenticated to the client with
NTLM.  For specifying an _arbitrary_ server principal, it would be
much easier, since you only have to provide the name, and that could
be easily written into /etc/mount.map because it does not need a
password/passphrase in contrast on one's own credential.

So for NFS and SMB, no such problem exists.  An arbitrary server's identity
is just another mount option.

-Martin

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Nov 2010 22:22:10 +0100

Nico,

> version of the krb5 mech that doesn't require knowing the acceptor's

Sam and I had an exchange very much along these lines as a possible
addition to security considerations, in a slightly different context,
for the sasl-openid draft in particular.  My thought was perhaps
slightly rougher than this- which was when calling a browser for a
service that was already provisioned, perhaps have a parameter or an
option where the SASL application can request that certs not be
overriden.  This would be in Security Considerations, to allow for this
sort of experienced-based identity.  This takes into consideration that
many non-web-based applications are pre-provisioned.

I'd be curious what the group thinks about that.

Eliot

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Nov 2010 15:25:02 -0600

> because they violate a fundamental design principle behind GSS-API.

Well, right here, today, in KITTEN, Sam, Jeff H. and myself disagree
with you.

> are fortunately much more aligned with the original GSS-API design.

The issue is NOT the need to know the acceptor name a priori (a
krb5-ism).  The issue is that the app needs a trivial authorization
function for deciding whether a given acceptor name is allowed to
represent a host named by the user.

> GSS-API (which is why the nametype OID for it is from the MIT Kerberos

Optional for the GSS-API.  Not optional for the applications I listed.
There's a difference between "framework" and "application" (and
"mechanism").

> and SPKM rfc2025) work _completely_ without hostbased service names,

I understand.  Of course, today people manage to encode hostnames into
PKIX certificates just fine, so I don't think I care at all about what
SPKM allowed (besides the fact that there's no SPKM implementations in
the wild, none that any of our customers use, and besides the fact that
there's a replacement for SPKM: MSFT's PKU2U).

You're fighting the war before the last war.  PKIX has moved on.

Are there any mechanisms not based on PKI that you support and that
can't handle hostbased service naming?  I suspect the answer is no, but
I'm curious.

> Which is funny, because NTLM is a unidirectional authentication scheme...

SMB also supports Kerberos.

> checked attributes _other_ than the hostname in TLS EV server certs),

Indeed, hostbased service names imply exactly that.

> target network endpoint address as the server/service name.

Also that users are not capable of doing the relevant authorization
decision.

> As SSH has been doing with host keys all the time -- correct!

And which I don't ever have to do given the nice Kerberos infrastructure
that I use.  The same is true for many of our customers.  Why should we
take a step backwards?

> abstract service name through a _trusted_ naming service.

There's no such directories in place, however.

>  DNSSEC keys from millions of untrusted DNSSEC keys).

Please explain.

> I think that the IESG should wake up on this.

It's a bit early to involve the IESG.  At some point there will have to
be a consensus call on a charter modification for KITTEN WG.  If you end
up on the rough side of that consensus call then you could appeal.

> supply the name with the mount call.  Otherwise it is the admins task.

That's... not how the world works Martin.  Users don't "make mount
calls".  They don't run the "mount" command.  Users simply access
transparently automounted paths, some of which happen to by convention
be based on server names -- think of /net/server/path (standard fare on
Unix-type systems) or \\SERVER\Path (Windows UNCs).

> So for NFS and SMB, no such problem exists.  An arbitrary server's
> identity is just another mount option.

To me the above shows that you're not using the same real-world systems
that I do.  At best we have different real-world scenarios.  However,
I'm pretty sure that users normally don't expect to be involved in
making server name authorization decisions.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Nov 2010 22:34:33 +0100 (MET)

> Unix-type systems) or \\SERVER\Path (Windows UNCs).

That is _exactly_ how the world works.
On all the Unix machines that I have ever used or touched filesystems
are only mounted if they have an explicit entry either in /etc/fstab
or in /etc/mount.map.

Our Unix admins here maintain /etc/mount.map for every machine,
and are currently ~1060 explicit entries in /etc/mount.map with mount options.
Distributing a server name along with the mount options is a no-brainer.

Having your machine "transparently mount" remote directories is
what is currently haunting so many folks all over the internet
with "DLL injection vulnerabilities".

I definitely want my machine to only import/mount what I explicitly ask
for, just as I want my machine to export/share only what I explicitly
ask for.  Doing anything like that automatically is asking for trouble!

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 15 Nov 2010 15:42:01 -0600

> are only mounted if they have an explicit entry either in /etc/fstab

You've.. not met the automounter?  You've not met the special -hosts
automount map?

> with "DLL injection vulnerabilities".

Who said you should be able to execute anything from /net automounts?

> ask for.  Doing anything like that automatically is asking for trouble!

So, WebDAV is bad too, yes?  Browsers in general are bad too, I suppose.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 15 Nov 2010 17:48:35 -0500

--On Monday, November 15, 2010 03:42:01 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> > > > But note that for some applications it will be very difficult to
>> > > > make them work the way you say they should work.  NFS and SMB
>> > > > clients, for example, are typically implemented in such a way that
>> > > > it's very hard to go prompt a user as to whether a given acceptor
>> > > > name is acceptable for a path a user was trying to access!
>> > >

Or AFS, which supports (requires, really) objects in the filesystem that 
are references to other volumes?  Or Microsoft dfs, which does something 
similar?  Or NFSv4, which I believe also has something similar?

Or... the list goes on.

Also, we're talking about "the world", or at least the Internet, not just 
UNIX.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Mon, 15 Nov 2010 23:52:36 +0100 (MET)

> > > Unix-type systems) or \\SERVER\Path (Windows UNCs).

Windows has NEVER EVER cared about authenticating servers.
Windows UNC pathes \\Server\Path were designed for and with NTLM
where there is not even a protocol element to authenticate the server.

And while it might be theoretically possible to use Kerberos
with SMB, I have never seen any Windows installations using it.
In particular, I find myself completely unable to cause my Win2K3 as well
as my Win7 VMware image to even try using it when accessing production
Windows servers.  Even if it would work, I assume that causing a
fallback to NTLM wouldn't be that difficult.

Looking at the wireshark trace, I wonder whether an empty "signature"
field in the SMB header indicates what the name suggests ...

> You've.. not met the automounter?  You've not met the special -hosts

"/etc/mount.map" _IS_ used by the automounter,
and probably known to everyone who is using the automounter securely.

That is an obvious security problem.
Maybe not as bad as doing "xhost +", "echo * > .rhosts",
"echo '/ *(rw)' > /etc/exports", but just marginally.

> Who said you should be able to execute anything from /net automounts?

The method known to secure a wildcard automounting facility
is to disable all networking and make it a single user machine.

Everything else amounts to varying levels of obscurity.

> So, WebDAV is bad too, yes?

You mean the transparent mounting that makes the "DLL injection" and
"EXE injection" vulnerabilities such a huge problem on Windows?

Yup.  BAD BAD BAD idea.  Every day I learn new reasons why it has
been a good idea that during all those years I have never revealed
to MSIE/winhttp of those machines I administrate the address of the
internet proxy.

>
> Browsers in general are bad too, I suppose..

Not all of them in the same way.  The ability to reliably disable
active content is important.

More and more websites are much worse than browsers, because they're
barely usable, if at all, when active content in the browser is disabled.
So I sometimes need a secure virtualization with a throw-away
(or un-doable) installation when there is a need to access something
over the internet that absolutely doesn't work with active content disabled.

But since practising any meaningful level of internet hygiene far
exceeds the skill level of Joe Average, security of the internet at
large appears to be a long lost cause.

But that doesn't mean that the IETF should impair the security technologies
so badly that those who care about security can no longer get it working
securely because implementations do no longer offer the necessary
configurability and are instead hardwired to an epsilon close to zero,
similar to what was inflicted on web browsers ~15 years ago.

-Martin

---

From: Luke Howard <[email-masked]>
Date: Tue, 16 Nov 2010 10:35:46 +1100

> with SMB, I have never seen any Windows installations using it.

That doesn't correspond with my experience; it does support mutual authentication, too.

> fallback to NTLM wouldn't be that difficult.

Do you have Active Directory setup and the machines joined to a domain?

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Nov 2010 18:39:00 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:
    Martin> Artificially matching only parts of a hostbased service name
    Martin> to attributes of an X.509 certificiate is a clear,
    Martin> significant and serious breah of the GSS-API architecture,
    Martin> and one of important GSS-API features that breaks when doing
    Martin> this is the capability to canonicalize the name of the
    Martin> communication peer.  That is a significant impediment for
    Martin> distributed computing, where many components may need to
    Martin> establish communication channels arbitrarily in either
    Martin> direction, and therefor need to pre-populate ACLs with peers
    Martin> name ahead of time, locally canonicalizing the name that
    Martin> they use when they are initiator for storing it in the ACL
    Martin> for situations where they are acceptor.

I understand this limitation.
Your argument is certainly valid.

The problem here is that we've both been using GSS-API for a number of
years but we've been using it in different contexts, depending on
different aspects of the architecture.

I think we're forced to maintain either the canonicalization ability
above, or the ability to work with existing IETF uses of GSS-API.

My personal opinion is that while I agree with you that there are
drawbacks, the IETF needs to maintain the ability to work with its
applications.

I believe that we can and should mandate secure canonicalization of
GSS-API hostbased service names, although I do not guarantee that
gss_canonicalize_name will do what you like.  We're about to have a
discussion of that behavior for gss-eap on the [email-masked] mailing
list.  I'd urge you to understand the constraints we're working with
(and am happy to volunteer my time to help you do so) and help us come
up with the best solution to that issue that we can.

My current best solution is to maintain security but to lose the
guarantee that gss_export_name is always useful.  I suspect we can
maintain that gss_export_name on the acceptor will produce a canonical
result for names received from the initiator.

--Sam

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 15 Nov 2010 17:11:52 -0800

> with SMB, I have never seen any Windows installations using it.

As I understand it Argonne uses Kerberos exclusively, and has shut down NTLMv2 (not just NTLMv1).  That would imply they are using Kerberos with SMB.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 15 Nov 2010 17:21:42 -0800

Both.  Option 1 for discussion (and charter update).

I think that a standards-track RFC should be able to support all the options that people have been discussing (CB, PRF, message security, mutual auth, secure host name canonicalization, etc.).  This is a stronger requirement than 4.  

I'm OK with an informational RFC if it's something people are going to do anyway, in spite of security issues.  No sense in encouraging bad practices, but still encourage interoperability.  Give them a path to get better and an explanation of what "better" is.

On Nov 12, 2010, at 5:49 AM, Shawn M Emery wrote:

> 
> This starts a WG consensus call for the adoption of two new work items to the charter:
> 
> SASL-SAML-EC
> 2. Adopt with the assumption that there be a CB option specified for each mechanism
> 3. Adopt after the security considerations/assumptions of each mechanism is fully understood
> 4. Both 2 and 3.
>

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Nov 2010 05:09:29 +0100 (MET)

Luke Howard wrote:
> That doesn't correspond with my experience;
> it does support mutual authentication, too.
> 

After further experiments the cause for this problems appears to
be that the DNS domain where the server's hostnames are assigned
are _not_ managed by an Active Directory (and the zones are not enabled
for dynamic DNS update).

What is weird: SPN -L hosta gives me a list of only 4 SPNs
nfs/hosta.f.q.d.n, nfs/hosta, HOST/hosta.f.q.d.n, HOST/hosta

and although I _do_ find tickets for cifs/hosta.f.q.d.n in my
windows ticket cache after trying to access shares on hosta.f.q.d.n,
the SMB negotiate datagrams on the network as captured by wireshark
contain only NTLM dialects...

Weird.

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 16 Nov 2010 08:37:21 -0600

> As I understand it Argonne uses Kerberos exclusively, and has shut down NTLMv2 (not just NTLMv1).  That would imply they are using Kerberos with SMB.

No, we still have NTLMv2 enabled. As Martin pointed out,
I also see cifs/hostname tickets, but have not looked to see
if SMB is actually using them.

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444