From ipsec-request@ans.net Sat Oct 7 12:25:15 1995
Date: Sat, 7 Oct 95 15:04:16 GMT
From: William Allen Simpson ("William Allen Simpson" -bsimpson@morningstar.com-)
To: ipsec@ans.net ( ipsec@ans.net)
Subject: Re: Photuris Security
Xref subject next
> Date: Fri, 6 Oct 95 18:51:29 EDT
> From: hugo@watson.ibm.com
> To: karn@qualcomm.com, bsimpson@MorningStar.Com, ipsec@ans.net
>
I remind Hugo that Phil and I are both on the ipsec list, and really
don't need multiple copies of a message to bring it to our attention.
Also, I asked for comments on Chapter 1. You are outside the scope of
the discussion at this point. There will be a "last call" from the IESG
where you are certainly welcome to raise whatever issues that you wish
on the overall document.
> I have many other comments on the draft that I will send in next days.
Please don't, unless they are explicit language improvements, which is
the current discussion. Note the excellent recent comments by Hilary.
> However, Photuris is still an *insecure* protocol as defined.
> ...
> I am appending a message I sent to this WG list on June 12th on these issues.
> I'd like to know how the editors dealt with these comments;
> I cannot imagine they just ignored them, that's too much irresponsibility
> especially with those comments that touch the basic security of the scheme.
>
Actually, because there was so little substance, it would have been
irresponsible to pay _any_ credence what-so-ever to the plaints. I was
asked _not_ to respond (by more than one person).
Moreover, although I cannot speak for Phil, I was so turned off by your
incessant rants that I stopped working on Photuris for several months.
I have recently been encouraged by the results of widespread
implementation efforts. I am doing my best to address the issues raised
by these implementors, so that they also are encouraged and satisfied
and work together.
However, the IETF Standards Process requests that we certify that we
have addressed even insignificant objections. When your earlier
messages were sent, we were only asking for Experimental status, and
could safely ignore you. Unfortunately, the WG chairs seem to want to
progress this as a Proposed Standard instead.
Therefore, I will attempt to review these few items, under the
assumption that this will satisfy your curiousity as to _why_ we ignored
them. I have rearranged them more logically, in the order discussed in
the actual Photuris document.
Nota Bene, for the rest of the folks: this is a direct and personal
response, which may be offensive to some, although I have attempted
to keep the sarcasm to a minimum. You have been warned.
----
> > (See my note of April 12)
This was interspersed throughout the message.
Actually, I prefer to _again_ ignore your note of April 12, since it has
so many inaccuracies with respect to Photuris, including its derivation
and the use of its fields. Particularly, you seem to suffer from the
delusion that Photuris is based on STS, and interpret Photuris features
as STS features. This is not correct. We did not learn of STS until
Van Oorschot faxed a copy to Karn in March 95.
Another example is the reference to failure with respect to certain
unnamed stream cyphers, which are nowhere discussed in Photuris. It
would be helpful if, in the future, you did not make up attacks based on
material which is not in the document.
----
> > 4) The protocol should support a DH exchange that is authenticated by means
> > of a previously shared key between the parties. This provides for a secure
> > solution in many important scenarios, ...
It would be very helpful if you actually _read_ Photuris, and paid more
attention to the other messages on the IP Sec mailing list.
This is already required to be supported by Photuris.
This is the only currently implemented authentication technique.
Other techniques such as RSA (PKCS, PGP, X.509) are optional, because of
patent and export restrictions. But, they have been reserved and are
described elsewhere in great detail.
The ability to dynamically select which signature method is used has
long been a fundamental principle of Photuris.
> > For the purpose of this exchange the basic DH flows of Photuris remain
> > unchanged except that
> > a) signature is omitted
> > b) the MAC field is used to authenticate the information that is
> > otherwise signed, but the MAC is computed using the previously shared key
> > (e.g., the shared Kerberos key, etc).
This is some unusual use of the word "signature", which is not that same
as I am given to understand in either the English language or
cryptography.
The Signature_Message always has a Signature field. This field can
indeed contain any form of authentication. But the basic specification
requires that it contain a MD5 hash.
There is no separate "MAC field", as referenced above.
----
> > 1) The DH key (or "session key" SK) must not be signed. Signing SK is
> > unnecessary and, even worst, it is insecure. (See my note of April 12)
> >
Early drafts (include -01 which you were so vehemently against) did not
discuss which fields were signed. They did not mention signing the
shared-secret (computed by the D-H exchange). Indeed, the shared-secret
was not signed in Karn's early implementation. Only the public values
were signed.
However, Van Oorschot (as I remember) later noted that an
authentication-only version of the protocol was possible if we signed
the shared-secret. Since an authentication-only version of the protocol
is desirable in amateur radio networks, that is what we have selected.
Only the authentication-only signature form (using MD5) is described in
the base Photuris document. It is clearly indicated as "required to be
supported".
You have not explained to my satisfaction why signing the fields as
described in Photuris in any way "leaks" information about the computed
shared-secret or the trailing secret-key used for MD5 (see Appendix B).
> About (1): do you have a requiremnet that the signature transform hides the
> contents of the signed information? This is not written in the document,
> and is *not* the property of signatures in general.
Then, it should not be surprising that it is not written in the document.
> For example RSA signature without hashing reveals all of its contents which
> in this case include the shared-secret
Perhaps you make a nice publication record out of reiterating the
obvious, but it does not belong in Photuris.
> (as an example, hashing may not be applied if the total information length
> is less than the RSA modulus length, a perfectly possible case when the
> DH is based on 155-bit Elliptic Curve).
>
It would be helpful if, in the future, you did not make up attacks based
on material which is not in the document.
----
> > 2) Encryption of the signature messages is needed for privacy (anonymity).
> > However, it is *not* the right solution for proving possession of the DH key.
I can find no reference in Photuris (any draft) where _optional_
encryption of the exchange is used for the _requirement_ of proving
possession of the D-H shared-secret.
> > (The latter is needed to avoid some of the attacks described in the
> > Diffie-Van Oorschot-Wiener paper).
> > ...
> > (notice that this is a change relative to the original STS protocol).
> > (See my note of April 12).
> >
Again, you have mistaken Photuris for a derivation of STS. Photuris has
never had this putative STS failing.
It would be helpful if, in the future, you did not make up attacks based
on material which is not in the document.
> About (2): I am willing to explain more on this if you are receptive to the
> need of change in the protocol.
You have not yet given any reason for a change in the protocol.
----
> > 3) A fast re-key mechanism is to be provided for key refreshment based on
> > symmetric key techniques (as opposed to DH and/or PK techniques). This
> > is to be done by refreshing the key by means similar to those implied in the
> > draft (page 20).
This feature was not in the original Photuris drafts, but was added at
the repeated request of _many_ members of the WG.
I do not understand what you mean by "implied in the draft". Upon
reviewing page 20 of draft -01 (now page 22 of draft -03), the section
is clearly labeled "Session-Key Computation", and clearly and completely
describes the derivation of session keys.
> > However, the necessary nonces for freshness
> > guarantee should be provided explicitly (e.g., by replacing the DH-exponent
> > fields of the DH-exchange message with a fresh nonce).
Exchanging _new_ public-values is already an option. "Either party may
initiate an exchange at any time." [page 6].
However, the alternative Change_Message does not exchange the public
values. This results in fewer messages, and avoids overloading the
public-value fields with other "nonce" fields (which I find preposterous).
> > SAID's are not to be
> > used for this purpose.
You have not yet described any cryptographic weakness with the approach.
Until you can, please don't tell me or anyone else what may "be used"!
The SPI _is_ currently used. It is guaranteed to be unique to the party
generating it over the lifetime of the shared-secret, is recommended to
be generated randomly, and is "fresh" in every known cryptographic sense.
Oh yeah, and we avoid the IBM patents, too....
> > Cookies can be used (since cookies must be
> > unpredictable by definition),
You are incorrect. The cookies of subsequent exchanges are _not_
required to change in the Responder direction. Indeed, there is explicit
mention of rapid calculation when the public-values are the same.
> > however, I would still recommend using special
> > purpose nonces, to avoid the double functionality of cookies against denial
> > of service attacks and nonces (in particular, cookies may be unncessary if
> > the parties already share a previous key since then verifying a MAC is very
> > fast, actually as fast as generating a cookie).
Since the parties already share a previous D-H shared secret, this is
already used.
Using a previous session-key instead would be a _SERIOUS_ security flaw,
as it would not ensure Perfect Forward Secrecy.
The cookies are _not_ used as nonces, and therefore not subject to such
"double functionality".
----
> > 5) The non-interactive key refreshment in page 26 of the draft (re-key message)
> > needs to be eliminated. If there is a good reason to keep it, it needs
> > to be re-designed to avoid replay attacks (e.g., via a shared counter).
> > The way it is designed now it is vulnerable to replay and then insecure.
> >
This seems very much to be the same issue as (3), except you now want to
eliminate the message altogether.
You have not yet described any cryptographic weakness with the approach.
> About (5): If you believe that a previous (possibly broken) SPI cannot
> be replayed please explain that to me.
>
It is not a matter of belief. This is one of the reasons that
protection of Perfect Forward Secrecy (which you have tried to
"optionally" eliminate in your "variants") is so important.
The session-keys are dependent on the D-H shared secret, the signatures,
the cookies and the SPI. The shared-secret and cookies are in turn
dependent on the Photuris session. The signatures are dependent on the
Photuris session _and_ the long term certificates or secret keys.
Once any of the above have changed, the SPI cannot possibly be replayed.
----
> In addition: the way keys are derived for data-transforms (e.g., DES-CBC,
> MD5) from a session key as described in the draft (Appendix B) is unacceptable
> as already posted in this list
To date, there has been no posting to this list which describes a
cryptographic weakness in the derivation of the session key for either
DES-CBC or MD5.
Your "proof by assertion" is not acceptable to me.
> (i.e., re-use of same bits for
> DES-CBC and MD5).
>
This "potential weakness" has been discussed from time to time, but no
_actual_ interaction between DES-CBC and MD5 has been described in the
literature to my knowledge. Perhaps you could be more explicit?
While the same SPI and session-key _may_ be used for both ESP and AH, it
is not required. See [page 10]:
Typically, an encryption method is chosen for the primary
attribute of the SPI, and an authentication method is later added
for the same SPI, or as an additional separate SPI.
In any case, since this is a potential limitation of both manual and
automatic key generation, its discussion belongs in the Security
Architecture. Perhaps you should raise this theoretical issue again
when that document goes to Draft Standard.
Moreover, this is less likely with Photuris than with manual key
management. Photuris is quite capable of rapid SPI session-ley
generation, as noted earlier, and will not need to "re-use" keys.
----
Sat, 7 Oct 95 18:58:08 GMT
By the clock, I have now wasted over 3 hours of a nice Saturday morning
and part of an afternoon replying to this message.
I could have been doing many other things, such as actually editing
drafts or working on code, or just plain enjoying the day.
I refuse to expend more time on this particular individual. Certainly
not when he merely repeats previously posted messages, that were roundly
ignored by everyone the first time! Perhaps again in 3 months....
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
From ipsec-request@ans.net Tue Oct 10 02:11:13 1995
From: Germano Caronni (Germano Caronni -caronni@tik.ee.ethz.ch-)
Subject: Comments on draft-ietf-ipsec-skip-02
To: ipsec@ans.net ( ipsec@ans.net)
Date: Tue, 10 Oct 1995 09:37:35 +0100 (MET)
X-Mailer: ELM [version 2.4 PL24 PGP6]
Content-Type: text
Content-Length: 51499
Xref subject next
Hello Ashar, Everybody,
I have read the newest SKIP draft, and have some comments, suggestions,
critics and so on to make. Buried in all the comments are some small but
substantial proposed changes to the protocol. Please tell me if any comment
of mine is unclear, or if I need to justify it more. If you want me to, I
can incorporate some of the proposed changes into the document myself.
Understand me well: I like this draft, and think it is a good evolution of
the first draft. But there are some severe shortcomings (certificate
discovery protocol, sequencing, 'S' 'R' 'N' 'C' bits, assigned numbers,
ambiguities) which need to be fixed.
As all this is open and published information, discussing it should be no
threat to ITAR.
If you adapt some of the suggested changes, I suggest to turn out a new
revision of the draft until end of october, so we can use november to
implement this stuff.
Friendly greetings,
Germano Caronni
| Simple Key-Management For Internet Protocols (SKIP)
| <draft-ietf-ipsec-skip-02.txt>
|
I have added my comments, opinions and suggestions on lines without '|',
| CONTENTS
In the contents section, several line numbers are not aligned. Do you
happen to work with 'FrameMaker' ? ;-)
| - i -
At the end of the first and second page of the table of contents
a ^L is missing.
|1. Overview
|There are two ways authenticated RSA public keys can be used to provide
^^^
It is not easy to find the second way - one has to read carefully.
|authenticity and privacy for a datagram protocol, such as IP. The first
|is to use out-of-band establishment of an authenticated session key,
|using one of several session key establishment protocols prior to
|communication [2,3]
, the second one is the inband transmission of the authenticated session
key.
How about explicitly referencing inband establishment at this point, and
point to later discussion. Perhaps even separate subchapters would be
useful.
|This session key is then used to
|encrypt/authenticate IP data traffic.
Separate subchapters would also allow for better partitioning of the
arguments. The following 8 paragraphs mix some lines of reasoning which make
no smoth reading out of it. I would suggest to separate the issues of
- - context-free vs session-context (recovery, load balancing)
- - DH keyexchange vs RSA (amount of per-packet data)
more strongly.
Perhaps you can leave out some argumentation simply by pointing to section
1.6 ?
The draft contains a lot of reasoning and motivations. When re-reading
it I tentatively clipped out all subjects not needed to define a standard
for SKIP which let the document shrink somewhat. Is it really needed to give
this high amount of 'motivation' and explanative material in the definition
of a standard? I fully understand the need for it, to let people assess the
value of this standard, but I would rather prefer to see this stuff in an
informative annex, than in the document itself. I prefer short documents to
long ones ;-)
[[ Yes - it is really needed. Please disregard all future rantings about it
in the comments. ]]
|1.1 Simple Key-Management for Internet Protocols
|
|We stipulate that each IP based source and destination shall have an
|authenticated Diffie-Hellman public key. This public key may be
|distributed in numerous ways. One mechanism (described here) is by the
|use of X.509/PEM certificate format [6]. Other mechanisms, for example,
|PGP certificates, secure DNS resource records, and related issues such
|as various trust models are detailed in an adjunct Internet-Draft.
Hmm. Is there a reference to this draft?
|Examples of principals in the network are IP nodes, or users. In the
|discussion below we focus on IP nodes, although a straightforward
|extrapolation to user oriented keying is possible and is further
|described later.
I suggest referring to section 1.8. The 'extrapolation' itself is not given,
it is only shown that the mean exist to make it possible. I would write
...user oriented keying is possible. The protocol parts allowing this are
described in section 1.8.
I assume this would/could happen such that the SKIP daemon contacts an other
appropriate user-level process (or external hardware) to get Kij (or the
currently valid form of it). Another way would be that a user-process may
setsockopt() a Kij (or Kp??) which causes the kernel to allocate a node ID
for this socket, and cache node-id and Kij. I guess we do not want to
elaborate on such topics at this point in time?
|Thus each IP source or destination I has a secret value i, and a public
|value g^i mod p. Similarly, IP node J has a secret value j and a public
|value g^j mod p.
There is a very! sharp break between the two above chapters. The 'thus'
and the non-definition of i leads me to believe that a chapter is missing?
Who assigns 'i'?
|(SKCS) like DES, RC2, IDEA, and such. Since Kij is used for key-
|encryption, it is not practical to use a stream cipher for this purpose.
...encryption, one MUST NOT use a stream cipher...
|Kij is derived from g^ij mod p by taking the low order key-size bits of
|g^ij mod p. Since g^ij mod p should minimally be 512 bits and for
|greater security should be 1024 bits or more, we can always derive
|enough bits for use as Kij which is a key for a SKCS. SKCS key sizes are
|typically in the range of 40-256 bits.
I would change this to define what happens if there are not enough bits
for use as Kij. I can easily go and use RC5 with 2048 keying bits.
I suggest ALWAYS using the method described in 1.11 -- see there.
|
|The important point here is that Kij is an implicit pairwise shared key.
|It does not need to be sent in ANY packet or negotiated out-of-band. The
|destination IP node can compute this shared key (Kij) by simply knowing
|the source IP node's authenticated public key. Because this key is
|implicit, and is used as a MMMMaaaasssstttteeeerrrr kkkkeeeeyyyy,,,, its length can be made as long as
Oops. Junk. (backspaces)
|use. (In order to do this, if it did not already possess I's
|authenticated DH public key, it may have to obtain this from the local
|directory service.)
And check the authenticity!
|Since the authenticated public keys are Diffie-Hellman public keys, the
|nodes themselves have no public-key signature algorithm. This is not a
need
|problem, since signing on a per-packet basis using a public-key
|cryptosystem is too cumbersome. The integrity of the packets is
|determined using a symmetrically keyed Message Authentication Code
|(MAC).
We do not provide sender/receiver non-repudiation in authentication.
Perhaps this should be stated somewhere near 1.7.4
I really would like to see this but it can be done with an appropriate
(and expensive) AH.
Again - this is quite a long discussion, not all of it is relevant to the
realisation of SKIP. Only to the evaluation ;-)
|1.3 Zero-Message Master Key Update Algorithm
|
|counter value n is only incremented and never decremented. It is used to
|prevent re-use of compromised traffic authentication keys as well as to
[--------------] (delete)
|provide coarse-grain playback protection of data traffic. In the event
|
|Recommended time units/counter update frequency and the agreed upon
|start time is specified later in the document.
... in section 6.3.
I have mixed feelings about n. I certainly helps to prevent coarse grain
replay attacks. (And we need to use it for keying purposes - otherwise it
would be without effect in the encryption-only scenario) I do not like the
implicit master keys, but I see no alternative.
|Once the counter has moved forward, and after a short grace period to
|allow traffic in transit to be received, packets encrypted with the help
|of counter values earlier than n MUST be rejected.
Assume the following denial-of-service attack: Using the NTP protocol I
forward the time of a host to a high value. Then communication will be
impossible. (Latest when I stop influencing the clock)
Other issue. Should 'n' be stored on disk or other permanent storage? Or is
it sufficient to always recaluclate n from the actual time?
|1.3.1 Zero Message Master key Update with Diffie-Hellman
Clever ;-)
|1.3.2 Zero Message Master Key update with Manual Keying
|
|As before, n can be computed as the difference between an agreed upon
|start time (specified later in this document) and the current time.
|Then, the n'th master key is generated using the following function:
|
|Kijn = h(Kij, n, 1) | h(Kij, n, 0)
|
|where h() is a pseudo-random, one-way hash function, for example, MD5
|[13]. For this version of SKIP, the one-way function MUST be MD5. The
|"|" represents concatenation. The low order bits of this operation are
|used for Kijn.
Well, what exactly do you mean by Kij,n,1 ?
I would write
Kijn = h(Kij | n | 1) | h(Kij | n | 0)
where '|' means concatenation, and the high-order bits are on the right
side. Again you might need to define the amount of bits used?
|1.4 Independence from Cryptographic Algorithms
|
|a prime field, that can be used to provide the same public key agreement
|property are constructions that employ elliptic curves over finite
|fields and schemes that utilize exponentiation using composite moduli.
Literature References, perhaps?
|Essentially, all aspects of the key-management protocol described above
|can be generalized to public and private values of the public key
|agreement type. This includes the master key update algorithm described
|in the previous section.
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>
>We describe this using an abstract description of a public key agreement
>system as follows. We define Public_Key_Agree() as a cryptographic
>function that takes two inputs, one public and one private to generate a
>mutually shared secret. We let secret_i and public_i refer to the
>private and public values respectively of principal I, and secret_j and
>public_j refer to the private and public values respectively of
>principal J. The pairwise mutually shared secret between I and J is
>denoted shared_secret_ij. The master key Kij is derived from the
>shared_secret_ij by taking the low-order keysize bits of
>shared_secret_ij.
>
>A public key agreement function is then defined as:
>
>shared_secret_ij = Public_Key_Agree(secret_i, public_j)
> = Public_Key_Agree(secret_j, public_i)
>
>Having described a key agreement algorithm in the abstract form given
>above, the master key update algorithm described in the specific context
>of classic Diffie-Hellman above can be specified using the same form in
>a manner independent of the cryptographic construction as follows,
>
>shared_secret_ijn = Public_Key_Agree(n, shared_secret_ij)
>
>Kijn is derived from shared_secret_ijn. As before, from an
>implementation perspective, it may be faster to utilize the (n-1)th
>value of the shared secret in order to compute the n'th value of the
>shared secret.
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The bracketed section above is - IMHO - completely unneeded and of no
interest for this draft. There is no need defining a terminology which is
not used.
Place this in a draft dealing with alternative algorithms for gaining Kij!
SKIP should _not_ care how the shared secret could be derived, but define
one mandatory menthod (d-h).
|The public key agreement algorithm is specified by the algorithm
|identifier used to identify the public key in the public key certificate
|or equivalent mechanism (e.g. secure DNS).
|
|1.5 Storage of Cryptographic Keys
|
|One possible way to do this is to utilize a hardware device to compute,
|store and perform operations using these keys. This device can ensure
|that there are no interfaces to extract the keys from the device. Such
|devices can be in the form of tamper-proof smart cards, PCMCIA devices,
|and so on.
Where can I buy it? ;-))
|1.6 SKIP for High Availability and Load Balancing
|1.7 Attacks that the protocol guards against
Interesting. But for evaluation purposes only.
|1.7.1 Intruder in the Middle Attacks
'Man in the Middle' is the terminology I know. But never mind...
|1.7.2 Known Key Attacks
|If the in-band traffic keys Kp used for packet authentication are ever
|compromised, then the master key update algorithm described above
|precludes the re-use of compromised keys to send forged traffic.
In a coarse-grained fashion! Otherwise use sequencing. Which reminds me:
What happened to sequencing??!!
I rather liked it being in the SKIP header - as no other means for it was
available, and it is algorithm independant. Do I correctly assume that you
expect AH/ESP transforms to come up with sequencing? And then, will it be
an issue of authentication or of encryption. Or both? Sigh... Another dozen
transforms looming on the horizon.
|This is because even if a particular traffic key Kp is compromised, this
|does not tell an attacker anything about the current implicit key Kijn,
|and therefore the attacker would not be able to compute the encryption
|of Kp in Kijn. Without knowing the encryption of Kp under the Kijn, an
|attacker cannot re-use past compromised keys Kp to any advantage.
Wrong semantic. This particular Kp is already available. Should be
...the encryption of differing Kp's in Kijn or this compromised Kp in
future different Kijn's...
A replay attack is still possible in a limited window of opportunity, before
n changes.
|Also, knowing any number of past keys Kp does not help an attacker learn
|any other Kp, since knowing any number of Kp keys does not allow an
|attacker to learn Kijn. Knowing or even choosing Kp keys, and using that
|to learn Kijn is equivalent to a known or chosen plain-text attack on
|Kijn, and that should be infeasible even given a very large number of
|known/chosen Kp keys as long as the key-encryption algorithm is immune
|to a chosen text attack, which will always be the case. Thus SKIP is
^known/choosen ^^^^^^^^^^^^^^^^^
|immune to known or chosen key attacks of this variety.
DES has been shown to be vulnerable to such attack (2^41). 'which will
always be the case' is a dangerous wording...
|1.7.3 Anti-Clogging Defense
|
|An attacker may attempt to mount a denial-of-service attack on a node
|implementing SKIP, by trying to force it to perform an unacceptably high
|number of computationally expensive operations, e.g. the Diffie-Hellman
|computation.
... or seeking in a stream cipher!
|In order to prevent denial-of-service attacks on the SKIP scheme
|described above, a recommended solution is to pre-compute and cache
|master keys Kij, based either on usage patterns of the machine or
|through administrative action. In case a clogging attack occurs, the IP
|node will still be able to communicate with the set of machines for
|which it has pre-computed master keys, it will simply stop computing new
|master keys. This allows business as usual activities to carry on, even
|while a clogging attack occurs, since there are no computationally
|expensive (e.g. public key) operations required to key or re-key with an
|IP node once the master key Kij has been computed.
Interesting strategy.
|The keys belonging to administrator's SHOULD always be in the pre-
[-]
|compute cache used to prevent this form of denial-of-service attack.
|This allows the administrator to securely add more nodes to the pre-
|compute cache, even during a clogging attack.
A side issue: The usage of may/should/may-not vs SHOULD/MAY/MUST should
be carefully checked throughout the document. Different styles are visible.
|1.7.4 Non-Goal: Perfect Forward Secrecy
|
|Although perfect forward secrecy as described in [3], is a desirable and
|appealing goal for a key-distribution protocol, there are no known
|practical and scalable techniques for achieving perfect forward secrecy
Do you know a non-scalable but practical technique? I honestly do not know
any practical technique. if you do - please tell me.
|for a stateless message based protocol. Here a message based protocol is
|contrasted with a stateful session based protocol. Common examples of
Hmm. I get the feeling you really have mixed two papers in this draft. A
'statelessness-ratio' and a technical description of skip. sigh.
|message based protocols include secure e-mail protocols such as PEM and
|PGP. There are no known techniques for providing perfect forward secrecy
|of encrypted data for these message based protocols.
I tend to disagree. Might be possible when strict sequencing is implied, and
bilateral state is kept. I will check, and perhaps write about it later.
|above, vastly complicating (or making impossible) highly available and
|load-balanced protected IP configurations.
Perfect forward secrecy can be achieved when user-level keying is used, and
appropriate protocols are employed on that level...
Here, just before section 1.8, a newline is missing.
|Master Key-IDs effectively decouple the identification of a master key
|for purposes of key lookup and access control from issues of network
|topology, routing and IP addressing. As one example, this allows IP
adresses.
|The length of the Master Key ID is implicit in the choice of the NSID.
|There are two possible lengths, 32 bits and 128 bits. A 32 bit name
|space identifier may be used to identify, e.g., IPv4 addresses. A 128
|bit identifier may be used to refer to an IPv6 address.
|
|The 128-bit Master Key-ID format also allows many different name spaces
|(up to 256) to be used with SKIP, by letting the Master Key-ID be the
|message digest of the name in its native name space. Examples of name or
|identifier spaces that can be accommodated in this manner are DNS names,
|ISO Distinguished Names, U.S. Social Security numbers, Credit Card
|numbers, Bank Account numbers etc.
I would suggest keeping the length of IDs subject to the NSID value.
Additionally it is not clear whether all other NSID types than IPv4
require 128 bit. I see at least one application where 64 bits are
sufficient, but 32 are not. I would write '... There are two commonly used
lengths, 32 bits and 128 bits...'
And I would replace 'The 128-bit Master Key-ID format also...' with 'The
usage of NSIDs also allows many...' -- why should I be bound to 128 bit when
using a NSID?
|Although some of these name spaces have associated privacy concerns
|(e.g. social security numbers, credit card numbers etc.), these
|sensitive values would not actually be disclosed, since message-digests
|are one-way functions. Commonly used message digests have a 128-bit
|output, and this provides a compact and private way of carrying this
|identification information in a packet header.
I strongly disagree. Common credit card numbers contain 16 digits, where the
first four digits contain a country code. I can precompute all hashes, and
would thus be able to recover the credit card number. This need to be
mentioned. The name space has to be made such that precomputation is
infeasible, if the values are sensitive.
|It is also possible for this identifier to be the message digest of the
|public key of a principal, since some principals may wish to be known by
|their public keys alone. If the public key is used as an identification
|mechanism, it simplifies the distribution of authenticated public keys,
Good idea. Have you ever thought if it is possible to construct DH values
from RSA public/secret keys? if it is possible, users could use their PGP
keys to establish a 'security association' by using them as input to a DH
calculation. I will have to think about it...
|Principals in the network will need to be able to reverse lookup a
|certificate (or equivalent information) using the Master Key ID. There
Are we obsoleting Kerberos? Hmm....
|If the "N" bit is zero, i.e. there are no name space identifiers
|present, the Master Key-ID is a 32 bit identifier for SKIP encapsulated
|in IPv4 and a 128 bit identifier for SKIP in encapsulated in IPv6. In
|this case, the Master Key-IDs default to IPv4 and IPv6 addresses
|respectively.
Suggestion: Do NOT use a 'N' bit, but use the value of the two NSID fields
directly. (e.g. value == 0 -> no corresponding node-id field present!
I deem this important, because you are running out of toggle-bits.
I am sure that the value assigned to NSID in this draft can still be changed
to reflect the modified behaviour.
Thus we would also save the 'S' and the 'R' bit. It is of equal cost to
directly check the NSID fields.
|a semi-permanent identifier
^strange word. What do you actually mean?
|To illustrate one possible user, this decoupling allows, nodes to move
[-] [-]
|around on the network, and come in from dynamically assigned IP
|addresses (using, for example, the DHCP protocol) and still have access
^reference?
|control and Diffie-Hellman public key lookup occur based on the semi-
|permanent Master Key-IDs.
Again the semi-permanence.
|If the "S" bit is set, the sender Master Key-ID MUST be used for lookups
|and the source IP address MUST NOT be used. If the "R" bit is set, the
|receiver Master Key-ID MUST be used for authenticated public key lookups
|and the destination IP address MUST NOT be used.
If source NSID is non-zero, the sender Master Key-ID MUST be used for
lookups and the source IP address MUST NOT be used. If the destination NSID
is non-zero, the receiver...
|Some commonly used name spaces have been assigned NSIDs. These are
|described in the "Assigned Numbers" section below. More name spaces will
|be registered through IANA.
"assigned numbers" section 5.3
|1.8.1 The SKIP Header
|
|SKIP Header
|
| 0 1 2 3
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Clear IP Header protocol = SKIP... (typically 20-bytes)
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Ver |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER |
1 2 3 4 1 2 3 4 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
x x x x
I strongly suggest NOT having the four bits marked with 'x' but using
the corresponding byte-fields instead. (This would allow to re-introduce
sequencing, if wanted!)
|Following the NSID bytes in the SKIP header, the NEXT HEADER field is
|used to indicate which protocol follows the SKIP header. This field will
|usually indicate ESP or AH. But the NEXT HEADER may be any protocol
|which requires keying material. Examples of protocols other than AH/ESP
|that may use SKIP are given below.
Well, it even could be IP, for encapsulation purposes.
What happens if neither encryption nor authentication are present? Does Kp
get dropped?
|The input to the key encryption algorithm is padded with a random fill
|up to a multiple of the block size of the key-encryption algorithm. The
Where is the padding applied. Low-order bits or high-order bits? I suggest
high-order bits.
|length of Kp is derived from knowledge of the encryption/MAC algorithms.
|The low order key-length bits of the decrypted output are used as Kp.
Ah. I see.
|The Kp Alg and MAC Alg specify algorithms used by the interior protocol
I suggest changing the name of the field 'Kp Alg' to 'Crypt Alg', as both
fields depend on Kp.
|not an absolute, however. For instance, it is possible to have a Kp
|algorithm which provides encryption and MAC computation. This is further
|described in a later section.
...in section 1.11.2.
|The Comp Alg field specifies the algorithm that was used to compress
|packets prior to encryption/authentication. This field is only used when
|the "C" bit is set.
Drop the C bit. Just rely on the Comp Alg field. As you do with encryption
and MAC computation, and I suggest doing it with Node-IDs too.
|The values for the algorithm fields will be described later in this
|document.
...in section 5.4. sigh.
I suggest adding the algorithms '0' in 5.4, for defining 'no ecnryption/MAC
performed. Same for compression.
|The field "Kp encrypted in Kij" is the ...
Explain again that the length of Kp is variable, and depends on the
MAC/crypt algorithm?
|The sender Master Key-ID field contains the Master Key-ID of the sender.
|This field is only present if the "S" bit has been set.
...if the source NSID is set.
|The receiver Master Key-ID field contains the Key-ID of the intended
|receiver. This field is only present if the "R" bit has been set.
...if the destination NSID is set.
|1.8.2 The relative order of compression, encryption and authentication
|
|The protocol allows three potential transforms to be performed, namely
|compression, encryption and authentication. The order in which these
|transforms are performed is very important. It is desirable for
|encryption to follow compression, because encrypted data is not
|(generally) compressible. Authentication must follow encryption and/or
^usually not!
|compression because it is unknown whether transforming a MAC using
|either encryption or compression results in a valid MAC.
I do not understand. You think it possible that an encrypted MAC will match
an encrypted plaintext, over which it was originally computed? Hmm. Would
be interesting to work out the properties such a MAC computation AND/OR
encryption would need to have. It surely does not exist as of now ;-)
|Received packets will naturally be transformed using the reverse order.
[---------]
|specific transform. The packet key Kp is used as a key to compute a MAC
|using, for example, Keyed MD5. The MAC is inserted into the encapsulated
See further below.
in 1.9.1 perhaps add a reference to the new SHA RFC, which appeared some
weeks ago, as alternative to keyed-MD5.
|1.9.2 Scope of MAC computation
|
|The only fields that are non-zero for the purposes of the MAC
|computation in the 20-byte outer IP header are: 1) 4-bit IP version
|number, 2) 16-bit ID field, 3) the two 32-bit source and destination IP
|addresses, and 4) the 8-bit protocol field. All other fields of the 20-
|byte IP header are treated as zero.
Isn't this a disagreement to:
|All IP options other than IPSO are ignored for the purposes of the MAC
|computation. The intent is to ignore any fields that may potentially be
|changed in transit by routers.
Does this mean that IPSO MUST be 0 on the receiving side, or what? Please
elaborate...
|1.10 SKIP for Encryption
|
|When SKIP is used to supply keying material for encryption only, the Kp
|algorithm indicates packet encryption algorithm. Kp will be used as a
|key to the Kp algorithm. The Kp algorithm will be mapped to standard
|transforms such as RFC 1829. These transforms will also contain
|information such as Initialization Vectors or Message Indicators.
Where is this mapping to std. transfroms defined?
|1.10.1 SKIP with ESP
|
| 0 1 2 3
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Clear IP Header protocol = SKIP... (typically 20-bytes)
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Ver |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER=ESP|
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Counter n |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Kij Alg | Kp Alg | RESERVED | COMP Alg |
1 2 3 4 5 6 7 1 2 3 4 5 6 7
please check the width of these fields in the different graphics.
|value SKIP_SPI. The SKIP_SPI value is specified later in this document.
in section [guess] 5.2
|1.11 SKIP for Packet Encryption and Authentication
|
|Packets may be both encrypted and authenticated. An important issue when
|performing both authentication and encryption is key separation. Namely,
|the authentication and encryption keys MUST be different. This allows,
|for example, encryption keys to be short (possibly to satisfy export
|control laws) while keeping the authentication key as long as necessary.
|Furthermore, it MUST be infeasible to derive either one of the
|authentication key or the encryption key, should one of them be
|compromised.
Why?? Please explain. I see that there is a problem, if Kp can be recovered,
and that the recovery is made more difficult when the two alg's use differnt
representations of Kp. But why is it _important_ ?
|This is accomplished as follows. The Kp that is decrypted from the
|packet header is not used directly to encrypt/decrypt or authenticate
|the packet. Rather, it is used to derive two separate keys named E_kp
|and A_kp, where A_kp is used as the authentication key and E_kp is used
|as the encryption key. E_kp and A_kp are related to the Kp decrypted
|from the packet header as follows:
|
|E_kp = h(Kp, 1, Kp) | h(Kp, 0, Kp)
|A_kp = h(Kp, 3, Kp) | h(Kp, 2, Kp)
As above, the "," operator needs to be defined. Also the width of 0..3 needs
to be defined. See comments about 'Kijn and manual keying' above.
Incidentally, why are you using Kp|0|Kp, and not simply Kp|0 ?? I do not
think it makes things more secure.
I am not sure whether this makes sense, but I tend to propose that we always
use the output of the key separation process. So nobody would have to
decide when to use Kp directly, and when to use E_kp, A_kp instead.
This is not important. Comments?
|When using MD5, the function specified above provides a total of 256
|bits, which is a sufficient number of key bits for the expected
|encryption and authentication algorithms that will be used with SKIP.
What will you do if it is not sufficient? Redesign SKIP?
|A SKIP implementation will know when to perform the key separation
|procedure specified above by presence of non-zero values in both the Kp
|Alg identifier and the MAC Alg identifier. This indicates that both
|encryption and authentication are taking place, and therefore separate
|keys need to be computed.
Hmm. What happens if MAC Alg. is non-zero, but no AH header follos? What
happens if it is zero, and an AH header follows.
Have you somewhere explicitly defined the significance of MAC alg being 0,
or Kp alg being 0?
|The other important issue when performing both authentication and
|encryption is the order of the two operations. For sending, SKIP
|compliant implementations MUST first encrypt the packet using E_kp as
|the encryption key, and then compute the MAC over the encrypted packet
|and invariant clear header fields using A_kp as the authentication key.
Isn't this a reiteration of section 1.8.2 ?
|Any protocol which uses both authentication and encryption MUST use this
|key separation algorithm. When performing encryption without
|authentication, or authentication without encryption, then key bits are
MUST be
|directly derived from Kp, without using the key separation functions
|described above.
|1.11.1 SKIP with AH and ESP
|
|SKIP combines naturally with AH and ESP. The Next protocol field in the
^^^^^^^^^
;-))))
|The following is an example of SKIP with AH and ESP. In Addition, the
|use of Master Key-ID's is also demonstrated.
Key-IDs
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Kij Alg | Kp Alg | MAC ALG | COMP Alg |
again, check alignment of fields.
|All 32-bit quantities are transmitted in network order.
This I would state somewhere earlier, or make it a global definition, near
to the introduction!!
|1.11.2 SKIP with combined ESP transforms
|
|For ESP transforms which combine encryption and authentication (for
^both
|instance: Keyed MD5 with DES-CBC), only an ESP header is needed. The Kp
|algorithm in the SKIP header will indicate the transform and A_kp would
|be used for authentication and the E_kp (as discussed in a previous
|section) would be used for encryption.
|
|Since a SKIP implementation has to unambiguously distinguish between
|when authentication and encryption are both being taking place in order
|to perform key separation, the MAC field MUST contain the same algorithm
|identifier as the Kp algorithm identifier. Since this algorithm
|identifier will indicate a combined encryption/authentication transform
|for ESP, setting both fields to non-zero values unambiguously indicates
|that both encryption and authentication are taking place.
Well. Now this gets weird. The semantics of Kp alg (suggested: Crypt alg)
and MAC alg are somewhat convoluted. Don't you think that a combined
transform would itself provide the key-separation process?
I understand that otherwise this coupling of the two algorithm fields (and
the numbering spaces) is the only practical solution to handle such combined
transforms.
But usually, if a MAC alg is defined, I would demand to see an AH header...
|1.12 Generic use of SKIP header
|
|In particular it is possible to pass SKIP in the payload of of a TCP/UDP
[--]
|packet. This allows the key-management and encryption/authentication to
|be performed in the application protocol (above TCP/UDP), and there may
|be times where it is advantageous to do so.
We are linking network layer with application layer here. Is this wise?
(Note: I like it, as I like the user-initiated, or per-socket keying; but is
it a smart thing to do?)
AH always needs the IP header to check integrity. Does this combine with an
application layer authentication?
|2.1 Transient Multicast Groups
|
|Furthermore, in order to distribute multicast keying material, the
|notion of a group owner needs to exist. How the identity of the group
|owner is established and communicated to the participating nodes is left
|to the application layer. However, this also needs to be done in a
|secure fashion, otherwise the underlying key-management can be defeated.
Does this imply user-level keying of SKIP?
|encrypted packet, using the pairwise secure protocol described in
|Section 1 above.
... using SKIP as described in section 1.
|requests/response messages. The request is sent to TCP/UDP port # 2000.
2000 is a bad choice. This is the most commonly used port for experiments
etc. As it is the first x000 number accessible to everybody. How about using
something like 17530/17531 ?
|The first field specifies the version of this protocol, which is 1. It
|is followed by the actual IP multicast address for which the GIK is
|being requested. The request packet that is sent must have the minimal
|enhancement of source-origin authentication, which is accomplished using
|the AH protocol.
The user level would not need to care about this, would it? As we are using
SKIP below, this would have to be implied.
|The group owner's response is an encrypted packet
|containing the GIK Kg. The response is sent to TCP/UDP port # 2001 at
|the requester's unicast IP address. The packet format is as follows, and
|as before, it defines the data-portion of a TCP or UDP packet.
Nice. Small and complete. I like it.
|key-change policy. There are two ways of specifying key-change policy.
|One is in terms of elapsed time since last key-change. This is specified
Perhaps state that you are talking about key change of Kp, not Kijn ?
|Transmitting nodes to group address M will randomly generate packet
|encryption keys Kp, and encrypt these keys using Kg. The packet
|structure is similar to the structure used for encrypted unicast SKIP
|packets, except that the packet keys Kp are not encrypted in the
|pairwise keys Kijn, but instead are encrypted using the GIK Kg. An
...Kg, analogous to manual keying as described... .
| 0 1 2 3
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Clear IP Header protocol = SKIP... (typically 20-bytes)
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Ver |C|S|R|N| Source NSID | Dest NSID |NEXT HEADER |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Counter n=1 (unused) |
Why????!!! This might be used to convolute Kg. (I know, you can do the same
with expiration of Kg, and requiring it to be fetched again.) Perhaps this
issue should be discussed. And why is it set to 1, and not to 0 ? ;-)
There is a small little arrow at the left side of the image. Any
significance?
|An implementation of this protocol will use the destination IP multicast
|address to lookup the GIK Kg.
Hmm. You have not yet implemented it. (-:C
Take care your cache is large enough (and uses LRU) when handling a
multicast group. Otherwise you SKIP implementation will run into problems if
somebody does not follow the Kp change schedule. (see experiments in Atlanta
where a bilateral SKIP already flooded (and blocked) your chache.
|the group. This can be extremely frequent, e.g. once every few seconds
|even with very large multicast groups, because there is no extra
|communications overhead for updating packet encryption keys.
Again. Remember the cache size.
|Second, since all the packet encryption keys are randomly generated, and
|hence different, there is no problem in using stream-ciphers with
|multicast.
Perhaps we could note the synchronisation problems with stream ciphers, as
observed in Atlanta. I will discuss this in a later mail.
|2.2 SKIP for Broadcast/Permanent Multicast Groups
|
|GIKn = h(GIK, n, 1) | h(GIK, n, 0)
sigh. again the ',' operator.
|This use of SKIP to supply keys for non AH/ESP protocols is intended to
|be illustrative, and not exclusive. Other protocols can similarly be
exhaustive?
|The Algorithm discovery ICMP message:
|
| 0 1 2 3
| 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | TYPE=SKIP_ICMP| CODE | CHECKSUM |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | nKij | nKp | nmac | ncomp |
MAC
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Current Time |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | n update Frequency (in seconds) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Expected n |
Isn't this tightly coupled to 'current time'? Might be redundant?
| 7 6 5 4 3 2 1 0
| +-+-+-+-+-+-+-+-+
| |I|P|M|C|N| res |
| +-+-+-+-+-+-+-+-+
| bits 0-2 are reserved and should be set to 0.
MUST/SHOULD
|
|The ICMP type field SKIP_ICMP is specified later in this document.
|
|The time field, Current Time, is set to the system's concept of current
|time in seconds since 0h Jan 1, 1900. This is identical to the Integer
^ UTC
|portion of the NTP timestamp.
and will work until about 2036.
Have you ever thought about augmenting NTP by authentication using SKIP.
This would secure the usage of 'n' for hosts using NTP. See RFC1305,
appendix C.
|The nKij, nKp, nmac and ncomp fields should be filled in with the number
nMAC
|of Kij, Kp, MAC and Compression algorithms the system supports,
|respectively.
|
|A host may force an ICMP message by sending a SKIP packet to the remote
|host with either the Kij or Kp algorithms set to zero. The compression
|algorithm may be set to 0 as well, but only if the "C" bit has been set.
See my suggested changes above, and forget about the 'C' bit. Directly use
the comrepssion alg. field.
Kp algorithms = 0 actually makes sense. I suggest forcing ICMP messages
only with Kij alg = 0.
|The DHPublicKey gets encapsulated as the BIT STRING in
|SubjectPublicKeyInfo of an X.509 certificate in the obvious manner. The
^^^^^^^?
|certificate and CRL encoding is the same as in RFC 1422. CRLs will be
|used with SKIP in the usual manner, in line with each site's
^^^^^?
|certificate/CRL management policies.
|4.3 Certificate Discovery Protocol
|algorithm for choosing a particular certificate (essentially a Diffie-
|Hellman public value) when more than one exist is described later.
...is described in section 4.4 ?
|All certificate discovery protocol communication use the User Datagram
|Protocol (UDP). The initiator binds to port skip-cert-send (6456) and
|sends a certificate request to port skip-cert-recv (6455). The
|responder binds to port cert-recv-port and sends the response to port
|cert-send-port. Two separate ports are used to allow for multiple
2 ports but 4 names?!
|certificate requests to be made without waiting for the response to be
|received, (that means, one port is used to simply send requests out and
|the other port is used to receive responses). A simple cache of the
|Master Key-ID and the IP address to which the request was sent is all
|that is required to manage outstanding certificate requests.
If I receive a SKIP packet containg an IP-v4 Master-ID and a source IP
address, and I try to do certificate discovery, to whom do I send my
UDP packet?
Why using 2 ports? If one process allocated both ports, as is suggested byt
the menioning of the cache, then one port is sufficent. Same applies to
ports in multicast scenario above.
|Implementation detail: Considering that a node may be pre-configured to
|allow only encrypted communication with any other node, a certificate
|request would be rejected. It is suggested that the two ports (cert-
|send-port and cert-recv-port) be treated as a "by-pass" channel for
|encryption. As only certificates requests are satisfied on these ports
|the window for vulnerability is limited.
Again we have a break of the layering. This would suggest SKIP
implementations where you can choose which ports are to be protected, and
which not. Which I like ;-)
|The certificate discovery packet:
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | VERSION | ACTION | STATUS |NUMBER-OF-CERTS|
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACTION indicates the type of message. Possible values are:
|1 (Request) - request for remote parties certificate(s).
|2 (Reply) - response to a certificate request.
You need no second port, when you distinguish requests from replies!
|NUMBER-OF-CERTS - if 0 then no certificates are present in the message
| and the message is simply a request for all certificates
| for the specified Master Key-ID or a response where the
| STATUS octet indicates an error.
Suggestion: Use more than 8 bit for this value. There are no space
limitations demanding us to save 3 bytes. I know, more than 256
certificates are highly improbable in UDP packets <64k , but why limit
oneself...
|Note that this allows for the initiator to not only request for all
|certificates for a particular Key-ID but can also send in the same
|message all the certificates it has. As certificates have the subjects
for a certain master-ID. How about allowing for multiple master-IDs ?
We have a collsion of terminology here: Key-ID vs Master-ID ?
|identity (i.e. specifies the certificate owner), this information does
|not have to be sent to other party.
^the
|
|Master Key-ID - this is a 32 bit or a 128 bit identifier as described
| in the section on Master Key-IDs.
Hmm. How do I know if it is 32bit or 128 bit? Why only the two values?
Redesign. Include NSID!
...and it is section 1.8.
|CERT-TYPE specifies the certificate type of the certificate that is to
|follow.
see 5.4 for values.
|CERTIFICATE - the actual certificate.
|
|
|The Certificate Discovery Protocol allows certificate requests to be
|made to any arbitrary IP-node. This feature allows the initiator to send
|requests to, say, an IP-node which is acting as a DNS or NFS server (and
|hence would have many certificates stored in its local certificate
|database).
How about defining when the authenticity of a certificate is to be chacked,
and what happens if it is not authentic?
I just remeber that RFC1825 contains some MUSTs concerning logging of
authentication failures... Are we RFC1825 compliant in SKIP? Or should we
ask for a change of RFC1825? I deem it stupid to enforce logging. This is
up to the admin to decide.
|5.3 Name Space Identifier (NSID) Assignments
|
|Some of the name spaces that may be used with SKIP are assigned
|identifiers here. Other name space identifiers will be assigned by IANA.
| NSID Value Name Space Master Key ID length
| 0 IPv4 Address Space 32-bits
I suggest using 0 as implicitly meaning the actual IP adress of the packet
| 1 POSIX/XOPEN User Ids 32-bits
| 2 IPv6 Address Space 128-bits
| 3 MD5 of DNS Names 128-bits
| 4 MD5 of ISO DN ASN.1 encoding 128-bits
| 5 MD5 of U.S. Social Security # 128-bits
| 6 MD5 of Credit Card # 128-bits
| 7 MD5 of Principal's Public Key 128-bits
| 8 MD5 of RFC-822 Mailbox Address 128-bits
| 9 MD5 of Bank Account # 128-bits
| 10 MD5 of NIS Name 128-bits
|
|
|Only the IPv4 and IPv6 address spaces are used without transformation
|using MD5. All other names are hashed into 128-bits from their native
|name space encoding mechanism using the MD5 message digest algorithm.
See earlier discussion of weakness!
By the way: What happens if two different values hash to the same digest,
and the database sees this collision?
|5.4 Assigned Algorithm Numbers
|
|Key-Encryption Algorithms (Kij Alg)
0 Invalid
|1 DES-CBC (IV = 0, random fill upto multiple of 64-bits)
MANDATORY
|2 3 key Triple DES-EDE-CBC (IV = 0, random fill upto multiple of 64-bits)
|3 IDEA-CBC (IV = 0, random fill upto multiple of 64-bits)
10 Simple Crypt
What about using the same numbers as for Kp (or Crypt) Alg ?
What about RC2, RC5?
|Traffic Encryption Algorithms (Kp Alg)
|
0 Not encrypted, no Kp present if no MAC Alg defined.
|1 DES-CBC (64-bit IV, padding ESP transform RFC 1829)
1 DES-CBC (RFC 1829)
MANDATORY
|2 40-bit RC2-CBC (64-bit IV, PKCS # 5 padding algorithm)
why not the one in PKCS #7 ?
|3 40-bit RC4 (64-bit byte offset Message Indicator)
|4 128-bit RC4 (64-bit byte offset Message Indicator)
ESP formats need to be defined!
|5 2 key (k1, k2, k1) Triple DES (EDE-CBC) (64-bit IV, padding according to PKCS #7, FIPS 81)
|6 3 key (k1, k2, k3) Triple DES (EDE-CBC) (64-bit IV, padding according to PKCS #7, FIPS 81)
|7 IDEA-CBC (64-bit IV, padding according to PKCS #7, FIPS 81)
|8 DES-CBC (64-bit IV, padding according to PKCS #7, FIPS 81)
Do wee need these two?? Very redundant!
10 Simple Crypt
What about RC2, RC5 ?
What about RFC1851?
|MAC Algorithms (MAC Alg)
|
0 Not authenticated, no Kp present if no Crypt Alg defined.
|1 128-bit Keyed MD5 (RFC 1828)
MANDATORY
|2 DES-CBC MAC
where defined?
3 SHA (RFC1852) ??
|Compression Algorithms (Comp Alg)
|
0 No compression used
| Currently Unassigned
|
|Certificate Type (Cert Type)
^Format
|
|1 X.509
|2 PGP
|3 Secure DNS
How about defining an ASCII interchange format, which is human-readable
and needs no binary encoding. Printable, Mailable, etc. ? Just print out
numbers.... (No authentication needed, just transfer of g,p,public value)
|characters. It is best to utilize as many different sources of random
|information as possible.
Our suggestion for generation of in-kernel random data is to use vmstat
netstat etc. data, and use this to key RC4, which then delivers 'Random'
bytes. Comments?
|The traffic encryption/authentication key SHOULD be updated for every 10
|Mbytes of protected traffic, or once every 2 minutes, which ever one
|results in a more frequent update policy.
Perhaps discuss problem of resynchronizing stream ciphers, because of
out-of-seekrange offsets?
I do not remember having read anywhere that the IV of a streamcipher drops
back to zero when Kp changes. Where do we place this, in the RC4 or whatever
draft?
|The start time for computing "n" is 0h Jan 1, 1995. The time units of n
^UTC
Yet another starting point ;-)
|are hours since this start time. Therefore the "n" counter is
|incremented once every hour.
|
|Symbolically, n is computed locally as
|
|local n = (current time) - (start time) normalized to hours
^^^ without rounding, perhaps use
'truncated' or 'granularity of'
|
|check this against the value of n in the received SKIP header. If they
|do not differ by more than 1, the packet is accepted. If they differ by
Define the window to be +/- 1 hour.
|Note that this doesn't require the use of fine-grain synchronized clocks
|or a secure clock synchronization protocol. Nodes should by default have
|clocks synchronized within an hour of each other. If they are not
|synchronized even in this coarse-grain manner, then validating
|certificates and CRLs becomes problematic.
Is there a way to switch off Zero-Message Master Key Update? I would say
yes, simply by setting 'n' to 0. This should be stated in the draft. It
depends on policy if such packets may be accepted or not.
|Two sets of values are specified here. One uses a 1024 bit modulus (p).
|The other uses a 512 bit modulus. These values were computed using the
|BSAFE library from RSA Data Security, Inc. The 512 bit modulus is
|defined for interoperability with exportable implementations due to US
|export control regulations.
Exactly how did you generate them? As mentioned in IETF Stockholm by
Schiller, it would be wiese to do this in a public forum, using lots of
random noise, as available on any conference ;-)
===========
That's it.
Germano
--
<...cookie space for rent...>
Germano Caronni caronni@tik.ee.ethz.ch http://www.tik.ee.ethz.ch/~caronni
PGP-Key-ID:7B7AE5E1 gec@acm.org 997C6DC4AF930A5D2D5D6AEAA196C33B