Subject: [Ietf-krb-wg] Last call issues on anonymous

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jul 2008 10:39:07 +0100

The following is a summary of issues that have been raised on the anonymous
document since draft-ietf-krb-wg-anonymous-05.txt entered IETF Last Call on
Feb 22, 2008.  There are a total of 28 issues, most of which have been
resolved as of draft-ietf-krb-wg-anonymous-07.txt.  There are 9 outstanding
issues which have not been addressed, including a new one I raised as a
result of a change that has crept in since the version that went to IETF
last call (A028).  There are also three items which are resolved by a
change (A016) which requires working group approval, which Sam brought up
on the list.  I would like to discuss these items at this afternoon's
meeting.

I suspect that Larry can respond to most of the outstanding changes without
further discussion; in fact, the only reason there are so many is that he 
seems to have completely missed a message from Sam Hartman and one from Ken 
Raeburn, each of which contained several comments.  However, there are 
several of these that I feel might benefit from discussion at today's 
meeting; specifically, items A019, A020, A022, and A023.

Participants should feel free to comment during today's meeting on any
of these items or on any issue not previously noticed.  However, please
bear in mind that this document is at a fairly late stage and so we
should not be making significant changes without a strong need.

In the text below, '>' indicates comments from the listed commenter,
'@' indicates comments from the document author(s), and '[[' and ']]'
surround comments from the shepherd.

**********************************************************************
*** OUTSTANDING
**********************************************************************

* A005 Mar 03 Paul Leach <[email-masked]>
  > Multiple usage modes:
  > - client discloses identity to KDC, but not service
  > - client discloses identity to neither KDC nor service
  > - with or without crealm in ticket
  > The motivation/need for these is not described; the abstract doesn't
  > even hint at their existence.  Can an implementation do just the
  > first?  It would help to be explicit about the mode, and separate
  > section 4 into two sub-sections, one for processing anonymous AS_REQ
  > and one for TGS_REQ.

==============================

* A019 Apr 04 Sam Hartman <[email-masked]>
  > How should anonymous realms interact with cross-realm policy?

==============================

* A020 Apr 04 Sam Hartman <[email-masked]>
  > In the anonymous AS request, ...  which KDC do you contact for the
  > anonymous ticket?

==============================

* A021 Apr 04 Sam Hartman <[email-masked]>
  > you need to keep track somewhere in your credential cache what KDC
  > you talked to so you can select the right ticket.  [This] issue
  > should be mentioned in the draft but we probably don't want to give
  > requirements for solutions;

==============================

* A022 Apr 07 Ken Raeburn <[email-masked]>
  > First, the GSS-API concept of anonymous session establishment seems to
  > be that the client isn't authenticated at all.  In the WELLKNOWN/
  > ANONYMOUS@SOME-REALM case, *if* anonymous AS requests can only use WK/
  > A@WELLKNOWN:ANONYMOUS as the client name (see Sam's email), then we're
  > giving the server information about the identity of the client.  Maybe
  > not the client's full identity, but at least the realm name.  Should
  > it be treated as anonymous authentication at the GSS-API layer
  > (GSS_C_ANON_FLAG, NT-ANONYMOUS), or not?  The text in krb-wg-anon does
  > imply that realm names may be included in NT-ANONYMOUS names, when
  > discussing the exported name format, but does this match the GSS-API
  > concept of anonymous security context establishment?

==============================

* A023 Apr 07 Ken Raeburn <[email-masked]>
  > Should importing an anonymous Kerberos principal name and calling
  > display_name get NT-ANONYMOUS back as the type, or should NT-ANONYMOUS
  > names only be generated by accept_sec_context?

==============================

* A024 Apr 07 Ken Raeburn <[email-masked]>
  > Oh, yeah: One little nit in the anon-05 draft: In the first paragraph
  > of section 3, "WELLKNOWN:ANONYMOUS" has a line break after the colon.
  > I assume it was intended to not have any whitespace inserted there,
  > but from the .txt file as distributed it's slightly ambiguous.

==============================

* A027 Apr 30 Phillip Hallam-Baker <[email-masked]> (for secdir)
  > Clarification, although the draft mentions traffic analysis, this is a
  > somewhat broad term and the context seems to imply an interception
  > attack by a third party rather than call out the fact that a service
  > that is authenticated by this mechanism may be able to infer the
  > identity of the party by examining and linking quasi-static protocol
  > information such as the IP address from which a request is received.
  >
  > This is a pervasive problem in privacy protocols. Preventing a party
  > from obtaining irrefutable evidence that a particular party was engaged
  > in a particular transaction is rather easier than preventing a party
  > from being able to infer such involvement with a significant degree of
  > probability.

  @ This specific text in security considerations talks about the former
  @ (passive eavesdropping).
  [[ I believe Phillip's point was that the security considerations
  [[ SHOULD Call out the fact that a service that is authenticated by
  [[ this mechanism may be able to infer the identity of the party by
  [[ examining and linking quasi-static protocol information such as
  [[ the IP address from which a request is received.

==============================

* A028 Jul 27 Jeffrey Hutzelman <[email-masked]> (as shepherd)
  > Looking at the first full paragraph on page 7, it appears that a
  > change in requirement level has crept in since the version we
  > sent to IETF last call.  In -05, the KDC MAY remove the
  > AD-INITIAL-VERIFIED-CAS according to local policy; in -07 this
  > has been changed to a SHOULD.  This is a substantive change for
  > which I don't recall any discussion or a consensus.

**********************************************************************
*** PENDING
**********************************************************************

* A004 Mar 03 Paul Leach <[email-masked]>
  > Why is it necessary to have three ways to specify the crealm in an
  > anonymous ticket?

  @ Related to misunderstanding in A001, but [clarification proposed]
  [[ Text present in -07 ]]

  <hartmans> What controls whether you end up with the wellknown
  <hartmans> anonymous realm or something else?
  @ Based on local policy; issuing KDC decides whether to disclose realm.
  <hartmans> That is not clear from the document; I thought...
  <hartmans> - anonymous PKINIT AS_REQ => well-known realm name
  <hartmans> - anonymous TGS_REQ to local KDC => that KDC realm
  <hartmans> - anonymous TGS_REQ to remote KDC => client or remote realm
  <hartmans> concerned that making this policy interacts badly with GSS
  @ It is up to policy [quotes text], but your interpretation turns out
  @ to be what the protocol allows.  Interactions with GSS are no worse
  @ than with referrals; KDC determines what the client's name is in both.
  [[ A016 would make this clear for the anonymous PKINIT case ]]
  [[ Applying A016 should result in removing the new text ]]
  [[ PENDING approval of A016 and appropriate text changes ]]

==============================

* A016 Mar 20 Sam Hartman <[email-masked]>
  > if I call gss_display_name  on an anonymous principal in an
  > acceptor, what do I expect to get back?

  @ Would section 2.1.1 of RFC1964 be sufficient for this purpose?

  > Not really; as Ken points out, there is a mess surrounding GSS and
  > anonymous names.  See RFC2743 section 4.5.  Two anonymous names need
  > to compare not equal; special name type used; etc.
  > Martin said anonymous support in GSS is immature; I agree.
  > Also concerned about multiple ways to specify anonymous names for
  > the AS case; why do we need multiple ways?

  @ Offline discussion... propose to fix this by requiring the returned
  @ realm name MUST be the anonymous realm when anonymous PKINIT is used.
  @ This seems to resolve A016, pending WG consensus.
  [[ New requirement appears in -07 ]]
  [[ PENDING WG approval ]]

==============================

* A018 Apr 04 Sam Hartman <[email-masked]>
  > If I use pkinit for an anonymous AS request, what should the client
  > realm be.  As I read the draft, the only valid answer is the anonymous
  > realm.  However as Ken Raeburn read the draft, the KDC could use
  > either its realm name or the realm name of the anonymous realm.  I had
  > assumed that you only got the realm name of the KDC or client in cases
  > where TGS requests were used to get anonymous tickets.
  [[ A016 answers this ]]
  [[ PENDING approval of A016 ]]

**********************************************************************
*** RESOLVED
**********************************************************************

* A001 Mar 03 Paul Leach <[email-masked]>
  > client's realm is always exposed to server via transited realm; this
  > makes being truly anonymous difficult.  Why must anon realm not be
  > used in transited realms?

  @ This understanding is incorrect [change proposed]
  [[ Subsumbed by moving the relevant text to Section 4 per A009 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A002 Mar 03 Paul Leach <[email-masked]>
  > The fact that the client's realm is always exposed whouls be noted
  > in security considerations

  @ Skipped, based on incorrect A001
  [[ RESOLVED - N/A ]]

==============================

* A003 Mar 03 Paul Leach <[email-masked]>
  > Why is policy needed on KDC to decide whether the crealm in a service
  > ticket is the anonymous realm or the realm of the KDC?  It seems
  > pointless given A001

  @ Skipped, based on incorrect A001
  [[ RESOLVED - N/A ]]

==============================

* A006 Mar 03 Paul Leach <[email-masked]>
  > In section 2 paragraph 2, suggest changing
  > "if the client wishes to authenticate the KDC anonymously"
  > to
  > "If the client does not wish to disclose its identity to the KDC,
  > yet still authenticate the KDC"

  @ Agreed
  @ Except not; this changes the meaning. [alternate text proposed]
  [[ Alternate text appears in -07 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

==============================

* A007 Mar 03 Paul Leach <[email-masked]>
  > Why is it interesting to want to remove AD-INITIAL-VERIFIED-CAS from
  > an anonymous ticket?

  @ Clarification proposed
  [[ New text appears in -07 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

==============================

* A008 Mar 03 Paul Leach <[email-masked]>
  > (re section 5) if an anonymous TGT was obtained, should the client
  > Kerberos library always set the anonymous flag in the KDC options
  > of a TGS request, even if the application does not assert the
  > anonymous flag when calling GSS_Init_sec_context?

  @ Already answered in section 4 [existing text quoted]
  [[ RESOLVED - N/A ]]

==============================

* A009 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 3 1st paragraph says:
  >
  >     An anonymous Kerberos realm name MUST NOT be present in
  >     the transited field of a ticket.
  >
  > and later the third paragraph says:
  >
  >     Note that in this specification, the anonymous principal name and
  >     realm are only applicable to the client in Kerberos messages, the
  >     server MUST NOT be anonymous in any Kerberos message.
  >
  > It came to my attention that this text is part of Section 3: 
"Definitions".
  > However, the above paragraphs are not definitions, but normative text. I
  > would have expected that the Definitions section contains informative
  > definitions that help to understand the draft, but not the normative
  > procedures. I suggest to move the above text elsewhere in the draft.

  @ Agree; proposea moving to the next section.
  [[ Changed in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A010 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 3, anonymous ticket flag:
  >
  > The 4th paragraph in Section 3 misses a context with respect the 
anonymous
  > ticket flag. For example, I would have expected the text to answer these
  > questions: Is the anonymous ticket flag a new flag defined by this 
document
  > or defined elsewhere? What is the purpose of this flag?
  >
  > Perhaps the 4th paragraph should start by saying:
  >
  > "This document defines a new 'anonymous ticket flag' whose purpose is to
  > indicate that a request is being made anonymous" (or something like 
that).

  @ Propose following text to clarify:
  @ > This is a new ticket flag that is used to indicate a ticket is an
  @ > anonymous one.
  [[ I liked Miguel's text better, but whatever. --jhutz ]]
  [[ New text appears in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A011 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 4, 1st paragraph, second line. Is the acronym "AS" correct for
  > "Authentication Exchange" ??? It looks it could be "AE" instead.
  >
  > Later, still in the 1st paragraph, but the 6th and 7th lines, the text
  > says: "... in an AS exchange"
  > So, if I replace "AS" with "Authenticate Exchange" then the sentence 
will
  > read: "... in an Authentication Exchange exchange", which obviously 
looks
  > bad.

  @ It should be "Authentication Service (AS) exchange".
  [[ Missing word "service" appears in -07 ]]
  [[ This could use word reordering, but it's not critical. --jhutz ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A012 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 4, page 6, third paragraph on that page: There is normative 
text
  > in passive voice, and it wasn't immediately clear to me who is the 
subject
  > of the normative text. The text reads:
  >
  >     Identity-based authorization data SHOULD NOT be present in an
  >     anonymous ticket in that it typically reveals the client's identity.
  >
  > Presumably this "SHOULD NOT" strength should apply to the TGS, but I am 
not
  > sure. I would suggest to clarify and turn the sentence into active 
voice.
  > Perhaps the same is also applicable to other parts of the draft.

  @ Propose rewriting as active voice
  [[ Rewritten in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A013 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 5, 1st paragraph on Page 8, reads:
  >
  >     " ... the initiator must NOT send "
  >
  > I guess this should be a normative "MUST NOT". If it isn't, then turn 
it to
  > "must not".

  @ Agreed; should be "MUST NOT"
  [[ Fixed in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A014 Mar 03 Miguel Garcia <[email-masked]> (for Gen-ART)
  > - Section 8, IANA consideration. The text reads:
  >
  >     Section 3 defines the anonymous Kerberos name and the anonymous
  >     Kerberos realm based on [KRBNAM].  The IANA registry for [KRBNAM]
  >     need to be updated to add references to this document.
  >
  >
  > I think IANA will have trouble to parse the above text. I would suggest 
the
  > following:
  >
  >     This document defines a new 'anonymous' Kerberos name and a new
  > 'anonymous' Kerberos realm based on [KRBNAM]. IANA is requested to add
  > these two values to the Kerberos name and the Kerberos real registries 
that
  > are created in [KRBNAM].

  [[IANA reviewed this and had no problem with the existing text]]
  @ Looks ok, propose slight changes
  [[ Text changed in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A015 Mar 20 Sam Hartman <[email-masked]>
  > The following requirement is impossible to implement:
  >
  > >   If a client requires anonymous communication then the client MUST
  > >   check to make sure that the ticket in the reply is actually 
anonymous
  > >      by checking the presence of the anonymous ticket flag.  This is
  >
  > As it turns out, a client cannot check ticket flags: it doesn't actually
  > know the key needed to decrypt the ticket.
  > Perhaps you mean that the client should check the KDC flags.

  @ The KDC duplicates the tickets flag in the EncKDCRepPart and the
  @ client can check that. I would propose the following changes to
  @ clarify this point.
  [[ Changed in -07 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

==============================

* A017 Mar 20 Sam Hartman <[email-masked]>
  > if I provide the anonymous name to a KDC in an AS-REP with the
  > anonymous option set, but don't provide padata, should I expect
  > a preauth_required error from the KDC listing pkinit?

  @ Yes, I would like to propose the following new sentence into
  @ section 4 to make this clear.
  [[ New text added in -07 ]]
  [[ RESOLVED - MINOR SUBSTANTIVE ]]

==============================

* A025 Apr 30 Phillip Hallam-Baker <[email-masked]> (for secdir)
  > Abstract, without revealing the client's identity to whom?

  @ Without revealing the client's identity to the server or KDC.
  @ Propose to clarify abstract.
  [[ Changed in -07 ]]
  [[ RESOLVED - EDITORIAL ]]

==============================

* A026 Apr 30 Phillip Hallam-Baker <[email-masked]> (for secdir)
  > Section 6.
  > Clarification, 'a ticket that is returned is actually anonymous'.
  > A Kerberos server may not return a ticket at all and there are also
  > ticket granting tickets being used so use of the definite article
  > 'the ticket' is somewhat confusing.

  @ Context is that the client is required to examine the ticket in the
  @ reply.  There is only one reply ticket; I believe the text is clear.
  [[ Text seems clear to me in -07 ]]
  [[ RESOLVED - N/A ]]

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 29 Jul 2008 10:45:57 +0100

--On Tuesday, July 29, 2008 10:39:07 AM +0100 Jeffrey Hutzelman 
<[email-masked]> wrote:

> There are also three items which are
> resolved by a change (A016) which requires working group approval, which
> Sam brought up on the list.  I would like to discuss these items at this
> afternoon's meeting.

I should note that the three items in question are A004, A016, and A018.  I 
expect to discuss these together, with the emphasis on A018, which most 
directly addresses the proposed change.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jul 2008 15:22:02 +0200 (MEST)

(I know it's been through WGLC and IETF LC quite a while ago, so adding
 new issues is not really appropriate and you may decide to ignore this)

The "tracable anonymous certificates" have been on the PKIX meeting
agenda again, and I'm still having a serious problems with the naming
of that concept.  A certificate that can be clearly distinguished
from other certificates and therefore clearly recognized, and which
is going to be used _more_ than once will be unable to provide
anything remotely similar to anonymity.  It is pseudonymity and
should be called that way.

What about anonymous Kerberos tickets:

 - Could there be or are there going to be any identifiers in the ticket
   that will allow to "uncover" the principal who originally obtained
   the ticket?
  
 - Should anonymous-tickets be limited to single-use (i.e. not be cached),
   so that independent sessions are not automatically correlated
   by repeated use of a cached anonymous service ticket.

-Martin

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 30 Jul 2008 14:29:19 +0100

>  new issues is not really appropriate and you may decide to ignore this)

As you know, we went over a bunch of issues with this document during the 
meeting yesterday, and there will need to be another revision.  So, new 
comments are not entirely inappropriate at this point.

>    that will allow to "uncover" the principal who originally obtained

Well, there is the session key.

>    by repeated use of a cached anonymous service ticket.

I think this is a suitable subject to be covered in security 
considerations.  I would suggest that rather than requiring that anonymous 
tickets be used only once, we could include a note pointing out that if an 
anonymous ticket is used more than once, the service will be able to tell 
that the same ticket was used.

-- Jeff